【GUI】Fletスレ【Python/Flutter】

**デフォルトの名無しさん** · 2025/01/25(土) 11:24:10.96

Pythonだけで比較的省労力でGUIが作れて趣味プログラマレベルでもとっつきやすいFletについて語りませんか。

公式 https://flet.dev/

**デフォルトの名無しさん** · 2025/09/07(日) 12:43:28.89

あれ、現時点でインストールするとControlBuilderが見つからないってなるな。>>39-41と同じ状態？

**デフォルトの名無しさん** · 2025/09/07(日) 14:09:29.85

StateViewという名前になったのか。こういう変更ってどこかに書いてあったのかな？　アルファ版だから、どこにも書いてなかったとしても文句は言えないが。

**デフォルトの名無しさん** · 2025/09/07(日) 23:17:20.34

>>48
4点目だけど、描画更新・再描画が行われるのは、第1引数stateの内容変更があったときではなく、第1引数stateの子孫属性に対する代入があったときというのが正確みたいね（元と同じ値を代入したときも描画更新・再描画は行われるみたい）。noteで解説記事を書いている人によると、__set_attr__をフックしているらしい。

**デフォルトの名無しさん** · 2025/09/07(日) 23:55:55.13

せっかくupdateいらなくなるのに
asyncio.sleepがいるってどうなん……

**デフォルトの名無しさん** · 2025/09/08(月) 00:22:50.28

まぁ、ダイアログ等限定の話なら我慢できるかな。

**デフォルトの名無しさん** · 2025/09/08(月) 17:54:12.61

page.run_taskでstate変更しても反映しないな

**デフォルトの名無しさん** · 2025/09/09(火) 22:58:43.69

タブ周りも結構変わっているのね。Tabsのcontentに（Columnでまとめた）TabBarとTabBarViewを入れるってことでいいの……か？

**デフォルトの名無しさん** · 2025/09/10(水) 21:27:09.31

>>48
最後の点だけど、もうRefを使っても問題ないみたい。修正された？

生成後に部分的な状態変更を必要とするようなカスタムコントロールは、StateViewでは使えないことになるのね。基本的にカスタムコントロールで凝ったことをするのは想定してないってことなのか。

**デフォルトの名無しさん** · 2025/09/11(木) 10:40:51.92

アルファ版のうちにということだろうけど、ここぞとばかりに色々弄っているな。たしかにこの先破壊的変更は入れづらくなっていくんだろうから、ここでいろいろやっておくのは良いことなんだろうね。

**デフォルトの名無しさん** · 2025/09/18(木) 08:09:43.17

明示的にupdateを書くことが（基本的には）なくなるということは、is_updateでTrueを返すようにするということは（基本的には）もうないってことでいいのかな。

ft.context.pageでどこからでもPageにアクセスできるのは地味にありがたい。カスタムコントロールの__init__の中でself.page.hogeとやって「Noneにhogeという属性はありません」と怒られるミスはよくやってしまっていたので。

**デフォルトの名無しさん** · 2025/09/18(木) 13:05:21.93

ごめん、is_updateじゃない、is_isolated だ。

**デフォルトの名無しさん** · 2025/09/18(木) 19:18:38.40

1.0当分かかりそうか

**デフォルトの名無しさん** · 2025/09/20(土) 09:50:21.54

いまアルファ版（0.7）で、これからベータ版（0.8）→RC版（0.9）を経て1.0 だもんね。noteの解説記事を書いている人によれば、年内くらいじゃないかという見立てのようだけど、どうなんだろうね。

**デフォルトの名無しさん** · 2025/10/06(月) 15:14:18.20

focus_stopみたいな名前のプロパティでも作って、コントロールへの入力完了後に次の（フォーカスを受け取る）コントロールに自動的にフォーカスが移るようにしてくれないかなぁ……。デスクトップアリでこれがないのは流石にちょっと使いにくいので自分で書いてみたけど結構面倒くさいし、これくらいはライブラリ側に期待しても罰は当たらないと思うんだよね。
autofocusがそういうプロパティかと思っていたんだけど、アレ全然役に立たないのな。何のためにあるんだレベル。

**デフォルトの名無しさん** · 2025/10/07(火) 18:17:13.86

コンテキストメニュー（右クリックメニュー）の機能も欲しいかな。ウェブの解説記事を参考にしてGestureDetector と Stack でそれっぽいものを作るところまではできたんだけど、メニュー以外のところをクリックしたときにメニューの表示を消すというのを簡単にする方法がわからなくて断念した。
何かしら方法はあるんだろうけど、コンテキストメニューくらいは簡単にかけるようになっていると嬉しいかな。

**デフォルトの名無しさん** · 2025/10/08(水) 11:38:45.62

>>63
大きさ0のTextField をStackの奥側に置いておいて、そのon_blurイベントでStack を削除するようにすればそれっぽい感じにできるっぽい。
でもやっぱりもう少しちゃんとした方法が欲しいところだなー。

**デフォルトの名無しさん** · 2025/10/09(木) 19:27:41.53

StateViewも何か別のコンセプトに置き換わるみたい。アルファ版ということもあってか、思った以上に流動的なんだね。いじったり、勉強したりするのは1.0が出てからにした方がいいのかも。

**デフォルトの名無しさん** · 2025/10/16(木) 12:22:09.70

触るのやめたよ

**デフォルトの名無しさん** · 2025/10/16(木) 13:59:41.30

まー、本格的に触るのはもう少し仕様が安定してからでもいいかな感はあるかなぁ。正直、StateView（ControlBuilder）はメインコンセプトっぽいからさすがに変更されることはないだろうと甘く見ていたわ。たしかに新しいcomponentベースの宣言型UIの方が柔軟性は高そうではあるけれども。

ちょっとだけ触ってみたところ、状態変更が連鎖するコードだと「Set changed size during iteration」という実行時エラーで怒られるんだけど（__pending_updatesというset内の各コントロールをupdateしている最中に__pending_updates自体に追加等があったということっぽい）、何か対処法あるのかな。

**デフォルトの名無しさん** · 2025/10/17(金) 10:48:52.13

状態①の変更に伴い呼び出されるコンポーネント①のコードの中に、別の状態②の変更（それにより別のコンポーネント②のコードが呼び出される）があると67後半のエラーになるっぽい。これを許すとコントロールツリーの一貫性に問題が生じる事態が生じうるということなのかもしれない。
状態①の変更に伴い呼び出されるコンポーネント①のコードの中から別の状態②の変更を発生させるコードを一旦取り除いて、コンポーネント①の完了後にその処理を行うようにしたらエラーが出なくなった（常にこのような対応が可能かは別問題だけど）。

componentベースの宣言型UIという方向性は、個人的にはそんなに悪くない感触かな。仕様が安定するまでは触るのは程々にとどめておくけど。

**デフォルトの名無しさん** · 2025/11/12(水) 19:13:41.90

しばらく更新みてなかったけど
Reactみたいになるんか

**デフォルトの名無しさん** · 2025/12/04(木) 13:14:05.78

クリスマス前にバージョン1のベータ版（0.8）が来るっぽい。