【GUI】Fletスレ【Python/Flutter】 (68ﾚｽ)
上下前次1-新
1: 01/25(土)11:24 ID:im0hq6D4(1/2) AAS
Pythonだけで比較的省労力でGUIが作れて趣味プログラマレベルでもとっつきやすいFletについて語りませんか。
公式 https://flet.dev/
49: 09/07(日)12:43 ID:TqDkjIbM(1/2) AAS
あれ、現時点でインストールするとControlBuilderが見つからないってなるな。>>39-41と同じ状態？
50: 09/07(日)14:09 ID:TqDkjIbM(2/2) AAS
StateViewという名前になったのか。こういう変更ってどこかに書いてあったのかな？ アルファ版だから、どこにも書いてなかったとしても文句は言えないが。
51: 09/07(日)23:17 ID:TC5o/1J8(1) AAS
>>48
4点目だけど、描画更新・再描画が行われるのは、第1引数stateの内容変更があったときではなく、第1引数stateの子孫属性に対する代入があったときというのが正確みたいね（元と同じ値を代入したときも描画更新・再描画は行われるみたい）。noteで解説記事を書いている人によると、__set_attr__をフックしているらしい。
52: 09/07(日)23:55 ID:wN29kMQ7(1) AAS
せっかくupdateいらなくなるのに
asyncio.sleepがいるってどうなん……
53: 09/08(月)00:22 ID:i1Wv6LLA(1) AAS
まぁ、ダイアログ等限定の話なら我慢できるかな。
54: 09/08(月)17:54 ID:PGku9TnQ(1) AAS
page.run_taskでstate変更しても反映しないな
55: 09/09(火)22:58 ID:zANAfy0I(1) AAS
タブ周りも結構変わっているのね。Tabsのcontentに（Columnでまとめた）TabBarとTabBarViewを入れるってことでいいの……か？
56: 09/10(水)21:27 ID:Rtl+OmsU(1) AAS
>>48
最後の点だけど、もうRefを使っても問題ないみたい。修正された？
生成後に部分的な状態変更を必要とするようなカスタムコントロールは、StateViewでは使えないことになるのね。基本的にカスタムコントロールで凝ったことをするのは想定してないってことなのか。
57: 09/11(木)10:40 ID:ZLHIwsaj(1) AAS
アルファ版のうちにということだろうけど、ここぞとばかりに色々弄っているな。たしかにこの先破壊的変更は入れづらくなっていくんだろうから、ここでいろいろやっておくのは良いことなんだろうね。
58: 09/18(木)08:09 ID:6zvJPGqA(1) AAS
明示的にupdateを書くことが（基本的には）なくなるということは、is_updateでTrueを返すようにするということは（基本的には）もうないってことでいいのかな。
ft.context.pageでどこからでもPageにアクセスできるのは地味にありがたい。カスタムコントロールの__init__の中でself.page.hogeとやって「Noneにhogeという属性はありません」と怒られるミスはよくやってしまっていたので。
59: 09/18(木)13:05 ID:DPWCUt9/(1) AAS
ごめん、is_updateじゃない、is_isolated だ。
60: 09/18(木)19:18 ID:t2Gbg0/Z(1) AAS
1.0当分かかりそうか
61: 09/20(土)09:50 ID:kxS+pQnh(1) AAS
いまアルファ版（0.7）で、これからベータ版（0.8）→RC版（0.9）を経て1.0 だもんね。noteの解説記事を書いている人によれば、年内くらいじゃないかという見立てのようだけど、どうなんだろうね。
62: 10/06(月)15:14 ID:QPH3iO32(1) AAS
focus_stopみたいな名前のプロパティでも作って、コントロールへの入力完了後に次の（フォーカスを受け取る）コントロールに自動的にフォーカスが移るようにしてくれないかなぁ……。デスクトップアリでこれがないのは流石にちょっと使いにくいので自分で書いてみたけど結構面倒くさいし、これくらいはライブラリ側に期待しても罰は当たらないと思うんだよね。
autofocusがそういうプロパティかと思っていたんだけど、アレ全然役に立たないのな。何のためにあるんだレベル。
63(1): 10/07(火)18:17 ID:nb9VcTS1(1) AAS
コンテキストメニュー（右クリックメニュー）の機能も欲しいかな。ウェブの解説記事を参考にしてGestureDetector と Stack でそれっぽいものを作るところまではできたんだけど、メニュー以外のところをクリックしたときにメニューの表示を消すというのを簡単にする方法がわからなくて断念した。
何かしら方法はあるんだろうけど、コンテキストメニューくらいは簡単にかけるようになっていると嬉しいかな。
64: 10/08(水)11:38 ID:5PMf8mIp(1) AAS
>>63
大きさ0のTextField をStackの奥側に置いておいて、そのon_blurイベントでStack を削除するようにすればそれっぽい感じにできるっぽい。
でもやっぱりもう少しちゃんとした方法が欲しいところだなー。
65: 10/09(木)19:27 ID:V7lTVJBy(1) AAS
StateViewも何か別のコンセプトに置き換わるみたい。アルファ版ということもあってか、思った以上に流動的なんだね。いじったり、勉強したりするのは1.0が出てからにした方がいいのかも。
66: 10/16(木)12:22 ID:S5H+CbkM(1) AAS
触るのやめたよ
67: 10/16(木)13:59 ID:A2DLovH4(1) AAS
まー、本格的に触るのはもう少し仕様が安定してからでもいいかな感はあるかなぁ。正直、StateView（ControlBuilder）はメインコンセプトっぽいからさすがに変更されることはないだろうと甘く見ていたわ。たしかに新しいcomponentベースの宣言型UIの方が柔軟性は高そうではあるけれども。
ちょっとだけ触ってみたところ、状態変更が連鎖するコードだと「Set changed size during iteration」という実行時エラーで怒られるんだけど（__pending_updatesというset内の各コントロールをupdateしている最中に__pending_updates自体に追加等があったということっぽい）、何か対処法あるのかな。
68: 10/17(金)10:48 ID:NJK8gXIe(1) AAS
状態①の変更に伴い呼び出されるコンポーネント①のコードの中に、別の状態②の変更（それにより別のコンポーネント②のコードが呼び出される）があると67後半のエラーになるっぽい。これを許すとコントロールツリーの一貫性に問題が生じる事態が生じうるということなのかもしれない。
状態①の変更に伴い呼び出されるコンポーネント①のコードの中から別の状態②の変更を発生させるコードを一旦取り除いて、コンポーネント①の完了後にその処理を行うようにしたらエラーが出なくなった（常にこのような対応が可能かは別問題だけど）。
componentベースの宣言型UIという方向性は、個人的にはそんなに悪くない感触かな。仕様が安定するまでは触るのは程々にとどめておくけど。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.432s*