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