@nebula121 あと、Pythonでの標準的な流儀（？）らしいけど（だから言うのはアレだけど＞＜；）、if __name__ == '__main__'って書き方が、悪い意味でUNIXのfork() exec()方式なコードっぽくてアレ＞＜；（エレガントじゃない感＞＜）
@nebula121 あと、Pythonでの標準的な流儀（？）らしいけど（だから言うのはアレだけど＞＜；）、if __name__ == '__main__'って書き方が、悪い意味でUNIXのfork() exec()方式なコードっぽくてアレ＞＜；（エレガントじゃない感＞＜）
@nebula121 最後の部分やっと意味がわかったかも＞＜； self.dialogUi（静的型付けじゃないからクラス名わかんないけど＞＜）とかが実際には表示してるから、それの土台のQDialogを表示した所で何の部品も表示できないということかも？＞＜
あれだ＞＜ 動的型付けとか型推論が駄目な例の一つだ＞＜（型推論な言語なら明示的に型を書けばドキュメントになるけど、動的型付けじゃどうにもならないアレだ＞＜（コメントで書くのはアホらしいし＞＜））
@nebula121 QWidget経由になる作りって事だろうから、出来なくても別にそんなに駄目でもなく感じる＞＜（個人的な好み・・・＞＜）
@nebula121 ウィンドウ(正確に言うとQWidget)の上にウィンドウ(QWidget)が貼り付いてるような構造になるっぽいけど、それは気にしなくていいような気もする・・・＞＜（わりと一般的な構造というか普通というか・・・＞＜）
@nebula121 ドキュメントと微妙に違うから混乱だけど（ doc.qt.io/qt-4.8/quiload… ）、そのQDialog（QWidgetを継承）は上に貼り付いてるウィンドウだから別に問題ないかも＞＜ パネル一個置いてその上に置いたみたいなのとかわらない＞＜
@nebula121 そうなってるようにしか読めないかも＞＜ コードとドキュメントを見比べた限りでは・・・＞＜
@nebula121 あと謎が解けてきたけど、"if __name__ == '__main__':のメインループ内"が示すメインループが謎だけど、そこはスコープ違くて最後のコードで言う所のmainWinじゃ無いとかじゃないのかな感＞＜（大部分が推定なので自信ない＞＜；）
@nebula121 ものすごくわけがわからないけど、動的型付け言語ならではの混乱にしか見えないかも・・・＞＜ PySideの例が特に意味不明だしハンドルというかインスタンスはどこへ・・・？＞＜；
@nebula121 混乱を収めるためにマイクロソフトがWindowsの構造を説明した時に使った言葉を使うと「ウィンドウもその上のボタンも何もかも、全てが『ウィンドウ』です」かも＞＜（Qtも多分そうなってるはず・・・＞＜）
@nebula121 多分だけどQt直接も少なくともPySideと同じように扱ってると思われるかも＞＜ なぜならばQUiLoader::loadはQWidgetを返すって書いてあるから＞＜ qt5もかも＞＜ doc.qt.io/qt-5/quiloader…
@nebula121 で、奇妙な点の可能性は二つあって、一つ目は子QWidgetを自動でShowしないの？って点＞＜（他のツールキットなら表示されるかも＞＜） もうひとつの可能性は動的型付けのせいでスコープで混乱してる説＞＜（どこかで勝手に別イスタンスを作って行方不明になってる）
@nebula121 それ、Show()すると（Qtの仕様とは違って（？））新しいインスタンス作るって事・・・？＞＜；
@nebula121 例えばボタンを貼り付けたとしていちいちそのボタンをShow()したりする環境ってあんまり聞かないかも・・・＞＜
@nebula121 MDIの子ウィンドウならそういう挙動あるだろうけど、そうじゃないのであれば奇妙な挙動に感じるかも・・・＞＜ 言い換えるとダイアログじゃない物にQDialogが使われてる（らしい）ところがおかしいかも＞＜（QtのドキュメントでもQWidgetになってるし＞＜）
@nebula121 self.dialogUiは貼り付けた先のダイアログじゃなく、上に乗っかってる側だからおかしいかも＞＜ 土台はあくまでコンストラクタ内で言う所のselfなんだし＞＜
@nebula121 謎全部解けた！＞＜； なんで親ウィンドウを指定（addWidget？）しないでそのまま使ってるの？＞＜； そういう表示されないメッセージ受信専用ウィンドウを親にする使い方もある（有名な例はDelphi 7）からそれはそれでありだけどQtの作法はどうなのか＞＜
@nebula121 気持ち悪い かつ Windows以外ではわりと当たり前に『ウィンドウの一番上にはLayoutを貼り付けるルール』にしてあるのが標準っぽい のでそれが多分正しいのかも＞＜；
@nebula121 もうひとつの解き方としては、そもそもアプリケーションを（QApplicationの事ではなくプログラム全体みたいな意味）QDialogを継承したクラスにしないという方法が＞＜（ QUiLoader::loadが返してきた物をメインウィンドウにする＞＜）
@nebula121 わかんないけど実際そういうのが普通っぽいから普通なのかも＞＜；（オレンジも納得行かないけど＞＜；）
@nebula121 そもそも論として、QDialogを継承する書き方が必ずそうすべきなほどに一般的なのか謎かも＞＜ 例えばこれはそうなってない＞＜ wiki.qt.io/Hello-World-in…
@nebula121 一方で画面に表示されないウィンドウをQDialogを継承して作って親にしてってやり方のメリットはとてもとてもよくわかるかも＞＜ なぜならその方式であるDelphiで育ったから＞＜ でもその場合は画面に表示されないウィンドウがあって当然かも＞＜（トートロジー）
@nebula121 それって『どこか』で（というかMainとかWinMainとか、そこから呼ばれるQtのどこか）でMainWindowクラスのインスタンスをひとつ作ってるからそう書けるだけかも＞＜ PySideでは『どこか』の部分から全部書くんだからそうならないのは当然かも＞＜
@nebula121 一番上から実行される＞＜（誤解を恐れずに言うなら、Pythonは生では（？＞＜；）全体がMain()みたいなものだと思えばいい・・・はず＞＜）
@nebula121 惜しい＞＜； それはどこかでDialogクラスのインスタンスを作った事により呼ばれてるだけ＞＜（UNIX的な感じで嫌な感じと言いたかった部分もそこ＞＜（全部説明するには文字数足りない＞＜；））
@nebula121 ごめんなさい；； 多分オレンジものすごく間違えた；； あのコードでも単に頭から実行してるはず＞＜；
@nebula121 うん＞＜ それはclass Dialog(QDialog)の中『では無く』、単に頭から実行されてそこに来た時に、「importされたのか」「そうじゃなくいきなり実行された(__main__)のか」って判別してるコードかも＞＜
@nebula121 別の言い方をするならclass Dialogからif __name__の手前までの、つまりDialogクラスの宣言は別ファイルでもいい＞＜（importしないといけなくなるけど） その部分を取っ払うとクラス云々じゃなく直に書いてあるコード＞＜
@nebula121 Qt C++のコードの場合には隠蔽された『どこか』でメインウィンドウを生成して呼んでる＞＜ 例えばWindowsの場合WinMain()って所がいきなり実行されるけどそれ以外はいきなりは実行されない＞＜ WinMainの中でQtが内緒でお仕事してくれてる＞＜
@nebula121 一方、PySideというかPythonの場合には内緒でおまじないな部分が無いので（※）、C++のコードでは書かなくていい（見えない）所も書く必要がある＞＜ （※もちろんWindowsから見るとPythonのWinMain()を呼んでるって点では「在る」＞＜）
@nebula121 それは多分つまり『どこか』の部分が現時点でのPySideには無いって事かも・・・＞＜（だからそこから好きに書いちゃっていいと思うし、仮に将来そういう仕様変更が来ても書き直す手間ほぼ同じくらい必要だと思う・・・＞＜）
そもそも論で言うとQtが本質的にRADでは無いからこその混乱だし、RADが正しいんじゃよ＞＜（頑固な老人）
@nebula121 うん＞＜； でもオレンジがお薦めした方の書き方に限りなく近いように見えるんだけどな・・・＞＜ doc.qt.io/qt-5/designer-… むしろloadから二度手間になってるだけだし＞＜
@nebula121 長くなっちゃって悪いから一応議論じゃなく参考として＞＜； doc.qt.io/qt-5/designer-… の The Direct Approachの部分＞＜（実行して無いので動くかはわからないけど＞＜；）
@nebula121 でもそう書いてるんだもん＞＜； シグナルスロットつないで実際に処理するのどこに書くのか？という点でどこに書いても気持ち悪いけど、どこかに書くしかないし元々のQiitaのでもDialogクラスって本質的に無関係なウィンドウのクラスに処理書いてるかも？＞＜；
@nebula121 んで、Delphiは（フォーム事に書く所あるから厳密には違うけど）、どこに書いていいんだかわからない処理を書く為に表示しない隠しウィンドウをひとつ持って、さらにそこがQtで言う所のQApplicationのような振る舞いもするみたいな方式だった＞＜
特許 US6185728 - Development system with methods for type-safe delegation of object events to ... - Google 特許検索 google.com/patents/US6185…
Delphi並みの物がC# on VSくらいしか出てこないのって、特許引っかかるからなのかも？＞＜；（でももうすぐ切れる？＞＜）
コードとGUIビルダが相互に連動する仕組み、'visual "two-way" tools'とかそんな感じの名前らしい・・・？＞＜
特許の文章、おもしろそうな事書いてあるし、Delphiで何がしたかったのか？という事も書いてあるような気がするけど、機械翻訳で読むのすごく時間かかるかも＞＜；
斜め読みで閉じちゃったけど、コンポーネントがデザイン時用の属性（GUIデザイナ用のコード）を持つのもそういう特許あるのかな？＞＜
Qtが本質的にRADでは無い（と少なくともオレンジは考えるけどwikipediaではRAD扱い）なのって、VCLよりも歴史長いんだから、Delphiの（無理やり訳すと）ヴィジュアル双方向ツール特許が反映されてないのはある意味当たり前なのかも＞＜（と考えるとやっぱRADじゃない）
Qtは双方向性を持ったGUIデザイナ（という言い方も誤解を招くけど）を持ってないし、QtDesignerは双方向ではないし、文字通りのGUIデザイナでしか無いかも＞＜ コードとの双方向性を持って（非ビジュアルなものを含む）コンポーネントをグラフィカルに扱うとか出来ない＞＜
その「RADであるか？」という点で重要な総方向性に関する特許が、Delphiで取得されたという事は、逆にいうと「双方向性を持っていることがRADの条件」と考えると、それ以前のままの物はDelphiの発明以前なんだから、RADは存在しないのかも＞＜；
その定義だと、色々な意味で始祖であるけど単方向で残念なNeXTSTEP版の初期のInterfaceBuilderがRADじゃない事になって＞＜； （でも総方向性こそRADだみたいな文書Delphiがらみ以外でも見かけるし＞＜；（ほとんど英語だから誤読してるかもだけど＞＜））
PythonにしてもQtにしてもそんなに使い続けたくなるほど使いやすい？＞＜； 横から見てて苦行にしか見えないんだけど＞＜； （Pythonは使い道によっては楽なんだろうけど、ある程度複雑なGUIを持つものには向いてないようにしか思えない＞＜；）
直接いうと終わらない議論になっちゃうからエアリプだけど＞＜；（さっき長くなってマジで申し訳ない＞＜；）
なんか今日（？）は、考えるばっかりの日だった気がする・・・＞＜（テラリアもしてない＞＜）
今日は涼しいっぽい？＞＜ -- 気象庁 | 週間天気予報： 埼玉県 jma.go.jp/jp/week/317.ht…