GUIがむずかしすぎる
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2009/10/18(日) 17:54:43GUIは私の知能じゃむり
0369デフォルトの名無しさん
2010/04/30(金) 20:37:37>仕組み（関数やクラスやモジュールなど）を作る方が比較的楽なのではないか？
>それができれば、すぐ間違える事は少なくなると思うが。
イベントの条件判定部分だけ切り出してプログラミングできるのが、
まさに"FRPのevent"でしょ？
そういう意味では、FRP使えでFAなんじゃなかろうか
0370デフォルトの名無しさん
2010/04/30(金) 20:41:48例えば、
ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更しておけば、
そのGUIコントロールが通信中にイベントを受け取ることはあり得ないので、
disableにしたコントロールのイベントハンドラについては、
ネットワーク通信中かどうかを判定するロジックは省略できる
ただしdisableにし忘れるとアウト
0371デフォルトの名無しさん
2010/04/30(金) 21:02:08>ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更しておけば、
そうしたら通信先が死んでたりするとタイムアウトするまでGUIは無反応にならない？
0372デフォルトの名無しさん
2010/04/30(金) 21:09:20ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更するのと、
ネットワーク通信に入る直前にGUIコントロールを全部
「ネットワーク通信中にされると都合が悪いユーザー操作を無視する」状態に変更するのと、
なにか根本的に違うのか？
まさか、無視する処理が難しいとか言わんだろうな
0373デフォルトの名無しさん
2010/04/30(金) 22:28:33組み合わせを省略できる（=難しくない）ってことじゃないの？
0374370
2010/04/30(金) 23:40:15そうです
あくまで組み合せを省略できる一例を示しただけで、
別にdisableにする事を推奨している訳ではないです
逆にdisableにするとGUIが無反応になったり色々嬉しくないので、
むしろそういう安易な対策は好ましくなく、
イベントハンドラできちんと状態を考慮する必要があると皆認識していると分かりました
0375デフォルトの名無しさん
2010/05/01(土) 01:54:210376デフォルトの名無しさん
2010/05/01(土) 04:25:53設定死ぬほど面倒だよ
というか不可能だよ
0377デフォルトの名無しさん
2010/05/01(土) 09:01:55本体のコードが変更されると、周辺のコメントとかGUIはすぐ古くなって問題を起こす
0378デフォルトの名無しさん
2010/05/01(土) 13:54:27だかさら、
> 「ネットワーク通信中にされると都合が悪いユーザー操作を無視する」状態に変更するのと、
> なにか根本的に違うのか
という質問に答えてないだろ？
もし同じであれば、
あなたの言う「GUIが無反応になったり色々嬉しくない」状態は回避しつつ、
あなたの言う「安易な対策」で解決できそうではないかと言いたい。
根本的に違うのであれば、どのように違うのかを示して欲しい。
わたしは本質的に同じと思っているから。
（どちらもトリガによって状態を変更し、状態に合わせて処理を分岐する）
> イベントハンドラできちんと状態を考慮する必要がある
なにやら、きちんと状態を考慮するのが難しいと言っているように聞こえる。
設計時にちゃんと必要な状態やトリガを洗いざらいリストアップしているか？
リストアップしたものの中で関連性が高いもの、依存しているもの、
一連の処理として分割できないもの、できるもの、ちゃんと仕分けしているか？
それぞれの状態遷移図や状態遷移表などを「大きな紙」に描いたりしているか？
0379デフォルトの名無しさん
2010/05/01(土) 14:47:570380デフォルトの名無しさん
2010/05/01(土) 16:00:33>リストアップしたものの中で関連性が高いもの、依存しているもの、
>一連の処理として分割できないもの、できるもの、ちゃんと仕分けしているか？
>それぞれの状態遷移図や状態遷移表などを「大きな紙」に描いたりしているか？
全てのボタンやメニューについて全部？
そんな事したことない
たぶんすぐ古くなってそれだけの労力が報われないと思う
そのコストを受け入れるより、
プログラムの作り方でなんとかならないのかなー？
0381デフォルトの名無しさん
2010/05/01(土) 17:26:10それぞれ状態によって有効/無効を切り替えるとする。
ボタンは将来追加される可能性もある。
君ならどうする？
状態A - ボタン1 3 5 7 9 を有効にし、それ以外を無効にする。
状態B - ボタン0 2 4 6 8 を有効にし、それ以外を無効にする。
状態C - ボタン0 1 2 3 4 を有効にし、それ以外を無効にする。
：
：
0382デフォルトの名無しさん
2010/05/01(土) 17:37:20アクションには、他のボタンの有効/無効や状態も切り替える事も含まれる。
君ならどうする？
0383デフォルトの名無しさん
2010/05/01(土) 17:57:37>全てのボタンやメニューについて全部？
なんでボタンやメニューから考え始めようとするんだよ。
まず実現させたい機能が先だろ。
それを洗い出して、その機能を実現させるための処理の組み合わせを考え、
それらの組み合わせる処理が他の処理と排他的な関係にあるのか、
同時に起こってもいいものなのか、などの関係を洗い出して、
最後の最後にその機能を発動させるスイッチとして、
ボタンやメニューなどを考えるんだよ。
機能よりもスイッチの方が多くなるのだから、
先に昨日動詞の関係をまとめておけば、イベントのごちゃごちゃも、
先にボタンとかを考え始めてた時よりは設計が楽になる。
0384デフォルトの名無しさん
2010/05/01(土) 18:47:11既存のコンポーネントで完結するなら
それほど手間じゃないんだけどな
オレも昔MFCで苦労した事あったから
GUIは誰にでも出来て簡単だとは言わないよ
0385デフォルトの名無しさん
2010/05/01(土) 18:49:06例えばディレクトリ以下のファイルをコピーするという単純な処理を
例に挙げると、
何も考えずにその手続き「だけ」を書くのは簡単だが、
GUIなら実際には進捗ダイアログを出したいだろう
というわけで、進捗ダイアログを出すことを前提にベタでコードを書くと、
それ「無し」のコードとは似ても似つかないものが出来上がる
スレッドを使える場合はまだシークエンシャルに手続きを書けるだろうから、
adviseやhookっぽい仕組みを使えば、両者で同じ部分を抽象化しやすい
かもしれない
が、GUI化することで本質的にイベントドリブンなコードになってしまう場合は
そうすることも難しくなる
気を抜くと、汎用性もへった暮れも無い、抽象度の低い、ベタなコードが
量産されてしまうことになる
0386デフォルトの名無しさん
2010/05/01(土) 19:31:56「現場」は「紙芝居」をまず作るんだよ
察してやれよ
0387デフォルトの名無しさん
2010/05/01(土) 19:37:32そして、「現場」では仕様作成者とプログラマが別の人間だな
「仕様」とは「紙芝居」のことで
その段階で内部状態やその整合性、実装上の都合が考慮されていることは
まずないな
そしてプログラマは「どうあるべき」ではなく、「紙芝居に合わせる事」を
求められるわけだ
0388デフォルトの名無しさん
2010/05/01(土) 19:47:120389デフォルトの名無しさん
2010/05/01(土) 20:00:01俺は>>385の理由で俺にとっては難しいけど
書き捨てコードは書きたくないが、書き捨てでないコードを書くのが難しい
だからGUIを書きたくない気持ちにさせられるんだと思う
0390デフォルトの名無しさん
2010/05/01(土) 20:50:00> 進捗ダイアログ
これをちゃんとやるのは難しいよねえ。
0391デフォルトの名無しさん
2010/05/01(土) 20:51:39それはお前に知識が不足してるだけ、
別に難しくはない
0392デフォルトの名無しさん
2010/05/01(土) 21:26:13それは GUI だからなのか・・・
0393デフォルトの名無しさん
2010/05/01(土) 21:31:55「難しい」って、誰も計算機科学における難問であるとかいう意味で言ってねえから
その単語が気に食わないなら、「凡人には難しい」とか「面倒」と
言い換えてもいいと思うよ
進捗ダイアログは、時間の見積もり、進捗表示、キャンセル、
（場合によってはロールバック）、といった、処理の本質とは関係ない
仕事を発生させる
べた書きすれば可能だが、結構泥臭い話なので、
進捗ダイアログと、それとやりとりする本質的な処理を
美しく抽象化するのは俺には難しいな
0394デフォルトの名無しさん
2010/05/01(土) 22:01:23本当にただの凡人だけどね。
当然、文献を当たって調べたり、自分で考えたり、
実験を繰り返したり、質問したりして、抽象化の方法を勉強してるんでしょ。
なら、そのうちものに出来るよ
0395デフォルトの名無しさん
2010/05/01(土) 22:03:31関わりたくない
0396デフォルトの名無しさん
2010/05/01(土) 22:05:29いや俺は本当にただの凡人だよｗ
以前職業的なSEだったこともあるが、もう辞めた
今でも自分のためのコードを書くことはあるが、非本質的なコードや
書き捨てのコードを書きたくは無いから、そういう要素が多くなりがちな
GUIを書こうという気になることがそもそも滅多に無い
ゲームつくりが趣味なら良かったんだが
0397デフォルトの名無しさん
2010/05/01(土) 22:14:55みたいな話はもういいよ・・・
0398デフォルトの名無しさん
2010/05/01(土) 22:52:59勉強のコツが分かると、面白くなるんだけどな
俺は問題を分解して関連を図示するを理解したら、面白くなった
そりゃ、興味が薄れたり他のものに移ればやる気が無くなるのはしょーがないが
0399デフォルトの名無しさん
2010/05/01(土) 22:58:220400デフォルトの名無しさん
2010/05/01(土) 23:20:23どちらか選ぶためには、一方は簡単でもう一方は難しいと言えないと駄目だと思う。
どちらも簡単だと言ってしまうと、そこで止まってしまう。
0401デフォルトの名無しさん
2010/05/01(土) 23:28:38CUI〜GUIの間で悩んでる人っていなくね？
難しさ＝情報量というただの困難というつまらないものや
和算証明の類のひねりものだったり
それはGUI固有の問題ではないよね？という
あなたはUI以前の排他でも躓くというレベルの人であったり
話し込めば最終的には哲学・宗教になりそうな人
GUIが難しいというなら
GUI固有の問題を引き合いに出さねば説得力がまるでない
0402デフォルトの名無しさん
2010/05/01(土) 23:31:16上で出てたんじゃないの？
イベントドリブン／非同期プログラミング特有の問題だとか
まあ非同期プログラミング全般がそうだから、GUI固有でもないけど
0403デフォルトの名無しさん
2010/05/01(土) 23:48:37すぐ終了するようなのに比べたら、そりゃ「相対的に」難しいってか面倒だと思うし
そんなの自明だと思うんだけど
・イベントドリブンなので、単純にトップダウン／シークエンシャルに書けない
・入力も多いし、出力も多い、単にprintf()じゃ済まない。要はやることが多い
・自分の都合で終われない。いつまで実行されてるか分からないので、リークが致命的
0404デフォルトの名無しさん
2010/05/01(土) 23:55:22すぐ終了するようなのをあらかじめいっぱい作っておいて
それをまとめる部分だけGUIにすれば良いと思うよ
0405デフォルトの名無しさん
2010/05/01(土) 23:58:55難しいと面倒臭いはイコールとは思わないので2番目はスルー
1,3はGUI固有とは言えないサジ加減だよね
0406デフォルトの名無しさん
2010/05/02(日) 00:00:230407デフォルトの名無しさん
2010/05/02(日) 00:06:41上向き構文解析でやってることと同じだから GUI 固有ではない
0408デフォルトの名無しさん
2010/05/02(日) 00:08:200409デフォルトの名無しさん
2010/05/02(日) 00:19:26なにも話せないｗ
0410デフォルトの名無しさん
2010/05/02(日) 00:23:58難しさがあるように思う
0411デフォルトの名無しさん
2010/05/02(日) 00:29:56おかしなローカルルールだな
>>408
スレタイがそれですから
>>407
>>409
それなのにここまで伸びるって不思議だよね
だから401で疑問を問いかけたんだ
0412デフォルトの名無しさん
2010/05/02(日) 00:46:54「イベントによる状態遷移」の作法をGUIの話題として話すのはNG
なぜなら上向き構文解析でやってることと同じだから
おかしいだろこれ
GUIに引き寄せて語っても構わないんだよ
0413デフォルトの名無しさん
2010/05/02(日) 00:48:55それって客の目に触れし、感じ方が人それぞれだから難しいと？
そうでないんなら、GUIなんて決まりきったことばっかじゃん
0414デフォルトの名無しさん
2010/05/02(日) 00:48:57いやスレタイは単に「GUIがむずかしすぎる」と言っているだけだろ
Aに似た性質の難しさをBが持っているからといって
Aが難しいと言ってはいけないことにはならない
それこそ意味不明な主張だな
0415411
2010/05/02(日) 01:26:25それは「何処」から引き寄せてくるのでしょ？
「CUI」と前提しますとCUIを舐めすぎじゃ？
1プロセス1スレッドばかりがCUIではありませんよ。
ちなみに
401=405=411≠407
察して欲しかったな。
>>413
俺もそう思う。
見栄えだったり操作性だったり描画性能だったりそんなとこだよね。
難しいとうか、際限のない鬱陶しさ。
もちろん、GUI特有の知識も必要だし
理解しなくては出来ない事も多々あるけど
排他で悩むってなんだよとｗ
それ以前の会話でしょとね。
>>414
包括関係にあるからその論理は成り立たん。
0416デフォルトの名無しさん
2010/05/02(日) 08:57:57排他で悩む機会がGUI以外に無かったんだろ
GUI特有ではないというのは綺麗事であって
現実にはGUI以外で排他で悩むような身近な例が無いんだよ
0417デフォルトの名無しさん
2010/05/02(日) 10:31:45そうでもないんじゃないの
CGIでおもちゃみたいなアクセスカウンター作るにしても排他は必要だし
まあGUIで多用されるオブザーバーパターン／コールバックみたいなのは
マルチスレッド初心者がデッドロックで嵌りやすい典型例ではあると思うけど
0418デフォルトの名無しさん
2010/05/02(日) 11:15:53イベントハンドラに依存関係があったりする場合は
そもそもセパレートしたらダメじゃん
0419デフォルトの名無しさん
2010/05/02(日) 11:44:56定石を知らないのが「初心者」なんでしょ
0420デフォルトの名無しさん
2010/05/02(日) 12:41:42要するに、GUI の実装で悩んでるんなら、
GUI 以外の色々な分野に "も" 目を向けろってことだよな。
そうすればヒントになりそうなものは色々あるんだし。
視野の狭さが招いた「行き詰まり≒難しさ」なんでは
0421デフォルトの名無しさん
2010/05/02(日) 22:30:01>Observerパターンは separation of concerns 要はswitch文をバラバラにする仕組み
>イベントハンドラに依存関係があったりする場合は
>そもそもセパレートしたらダメじゃん
でも、GUIコンポーネントが既にObserverパターンのlistener側を要求してくるので、
ライブラリを使う側としてはどうしようもないです
もしObserverパターンがだめなら、自前でGUIライブラリを作ると仮定して、
どういう設計がいいでしょうか？
なにかアイディアがあったら教えてほしいです
0422デフォルトの名無しさん
2010/05/02(日) 22:51:16"現状のGUIのむずかしさ"は致し方ないのか？
それとも、もっと優れた作り方があって、多くのGUIライブラリがそれに気づけていないだけなのか？
という事
FRPみたいな新しいGUIの作り方が出てきてるけど、
実際に使ってみた人いますか？
0423デフォルトの名無しさん
2010/05/02(日) 23:23:11「問題が完全に把握できないときは、解決策も提供しないのが最善の方法である。」
Observerもオブジェクト指向も提供しない、余計なことはなにもしない
「小さな政府」がいいと思う
0424デフォルトの名無しさん
2010/05/02(日) 23:39:55> もっと優れた作り方があって ...
> FRPみたいな新しいGUIの作り方が出てきてるけど、...
たぶん、ちょっと勘違いしてると思う。
[Reactive Programming]
簡単に言えば、a = 1 + b という式を定義しておけば、
変数 b を変化させた時に a も「自動的に」変化する、という仕組み。
たとえば、a を画面の背景色として、b をボタンとすると、
b の変化（ボタンが押された）に伴って a が変化（画面が赤くなる）する。
確かに宣言的に定義できるというメリットは大きいけど、
何と何を紐付けるか、紐付けた事による周りへの影響は、
ある事柄が紐付いた時に別の紐付けを解く必要があるか、
別の日も付けた事柄との間に時間軸上での依存性はあるか、
などはやはり人間が考慮しなくちゃならない。
イベント処理が難しいと感じてる人たちにとっては、
似たような悩みがつきまとうと思う。
0425デフォルトの名無しさん
2010/05/03(月) 00:30:420426デフォルトの名無しさん
2010/05/03(月) 09:47:33ようやくポインタとか仮想関数とかなんとなく理解でけた。
いよいよWindowsアプリを勉強しようと思うんだけど、GTK++たかQtとか
いろいろあるけど、どれやったらえんだろ？ おしえてちょ。ちなみに
あまり金もってない。 Qtって無料の開発環境あるんだろか？
0427デフォルトの名無しさん
2010/05/03(月) 10:41:28とりあえず高級GUIライブラリを使わず Win32API でゴリゴリやっとけ。
メッセージループの回し方も知らないんではスタート地点にも立ってない。
猫でもわかるプログラミング（http://homepage2.nifty.com/c_lang/）
ここの [Windows SDK編 第１部] と [Windows SDK編 第２部] を
自分でプログラムしながらざっと追えばいい。
１ヶ月くらいでこなせるだろ。
そうすると、高級GUIライブラリや Java のライブラリが
内部で何をやっているのか、だいたい想像できるようになって、
勉強がはかどる。
0428デフォルトの名無しさん
2010/05/03(月) 10:47:18激しく同意
同じこと書こうとしたら先を越されたｗ
0429デフォルトの名無しさん
2010/05/03(月) 11:18:42うっしゃ！ おおきに。意味はよくわからんが、やるきになた。
0430デフォルトの名無しさん
2010/05/03(月) 12:54:02何年もJAVAやってる奴が、C++で仮想関数をようやく理解できたっておかしくね？
JAVAで何をやってたんだｗ
0431デフォルトの名無しさん
2010/05/03(月) 14:12:010432デフォルトの名無しさん
2010/05/03(月) 14:43:270433デフォルトの名無しさん
2010/05/03(月) 15:30:20数えきれんぐらい作ったけど、
仮想関数なんて見た事も聞いた事もなかったよ。ポインタはうわさぐらいは
聞いたけど。
0434デフォルトの名無しさん
2010/05/03(月) 15:33:09仕方ないね
0435デフォルトの名無しさん
2010/05/03(月) 16:03:25C++の仮想関数をようやく理解できたってのは変だろ
CやBASICをやってた人なら話は別だが、JAVAをやってたら、
「仮想関数って言うんだ、フーン」程度で終わるだろ
0436デフォルトの名無しさん
2010/05/03(月) 16:10:390437デフォルトの名無しさん
2010/05/03(月) 16:11:320438デフォルトの名無しさん
2010/05/03(月) 16:27:58フレーズをよく見るが、AbstractClassというものに興味を持った事も
疑問を持った事も一切ない。
0439デフォルトの名無しさん
2010/05/03(月) 16:30:38お前は１０年間何をやってたんだ？
そんなんじゃ、ろくなものつれないだろ？
0440デフォルトの名無しさん
2010/05/03(月) 16:33:040441デフォルトの名無しさん
2010/05/03(月) 16:46:310442デフォルトの名無しさん
2010/05/03(月) 16:54:52GUIだけなら、誰でもそうだろ？
0443デフォルトの名無しさん
2010/05/03(月) 17:00:57ちゃちゃっと作ってエラーでたら、ネット検索にその部分を貼り付けて出た
例文見て適当にそれをペーストしたら動く。
0444デフォルトの名無しさん
2010/05/03(月) 17:24:030445デフォルトの名無しさん
2010/05/03(月) 17:38:230446デフォルトの名無しさん
2010/05/03(月) 20:10:33猫に分かるように書くとああなるんだよ
0447デフォルトの名無しさん
2010/05/03(月) 20:30:19仮想関数とはJAVAのimplementsされるクラスみたいなもんか。
なーんだ、そんな事なら早く言ってくれよ。まったくっ
0448デフォルトの名無しさん
2010/05/03(月) 20:37:21C/C++言語以前に、猫言語を習得していないと、あのページは読めないぞ
0449デフォルトの名無しさん
2010/05/03(月) 20:39:26アプリつくる時にゃ１つや２つは作ってるけど。。。
これで仮想関数なるものがやっとわかったぜおおきに。
0450デフォルトの名無しさん
2010/05/03(月) 20:46:07全然違う
このコードを走らせてみて理解汁
Javaだと、全てのメソッドはC++でいう仮想関数と同じ動作になる
仮想関数は、実行時型に応じてポリモーフィックに動作するが
非仮想関数は、ポリモーフィックに動作しない
#include <stdio.h>
struct base {
const char *static_hello() { return "hello, base"; }
virtual const char *virtual_hello() { return "hello, base"; }
};
struct derived : public base {
const char *static_hello() { return "hello, derived"; }
const char *virtual_hello() { return "hello, derived"; }
};
main()
{
base *p = new derived;
printf("static: %s\n", p->static_hello());
printf("virtual: %s\n", p->virtual_hello());
delete p;
}
0451デフォルトの名無しさん
2010/05/03(月) 21:10:19invokevirtual
invokeinterface
invokestatic
invokespecial
の４種類あって、invokespecial（コンストラクタ）とinvokestatic（staticメソッド）はポリモーフィックには動作しないよ。
0452デフォルトの名無しさん
2010/05/03(月) 21:11:37ああ全てと言っちゃうと語弊があったね
指摘サンクス
0453デフォルトの名無しさん
2010/05/03(月) 21:14:18ややこしいもんだな。Javaも俺の知らん内部でややこしくやってるわけか。
0454デフォルトの名無しさん
2010/05/03(月) 21:14:540455デフォルトの名無しさん
2010/05/03(月) 21:24:47ExcelやWordと同じ
0456デフォルトの名無しさん
2010/05/03(月) 23:09:5610年は無駄じゃなかった・・・と思うよ
0457デフォルトの名無しさん
2010/05/03(月) 23:19:550458デフォルトの名無しさん
2010/05/03(月) 23:26:41っあ、なんだ趣味でやってるような、ｦﾀでしたかｗ
だったら、何の問題もないんじゃねｗ
0459デフォルトの名無しさん
2010/05/03(月) 23:44:250460デフォルトの名無しさん
2010/05/04(火) 08:52:51目くそ鼻くそを笑うの典型だな。
0461デフォルトの名無しさん
2010/05/04(火) 09:06:33独特のポインタ概念とイベント概念が存在していて
どれも異なったやり方をしてるけど
決して無くなることのない部分で
分からない人はこの辺が分からないんだろうな
C++のクラスとポインタ概念が分かればどれも同じことをやってるだけなんだけど
結局内部で何をやってるか調べられるようになるだけど
Frameworkで用意されたものを見せられるだけじゃ
C++やJavaを熟知した人間にも分からないよ
なんかこう統一して欲しい部分ではあるな
0462デフォルトの名無しさん
2010/05/04(火) 17:17:490463デフォルトの名無しさん
2010/05/04(火) 17:43:04そんなあなたにＵＭＬ
0464デフォルトの名無しさん
2010/05/04(火) 17:52:02ＧＵＩが難しすぎる という以前に自分の読解力、知識のなさを棚に上げるのはどうかと思う
0465デフォルトの名無しさん
2010/05/04(火) 18:09:09では訊くが、>>461 は結局のところ「何を統一して欲しい」と言ってるんだ？
それは >>461 が言う「決して無くなることのない部分」なのか？
（そもそも、その部分が何を指してるかもやや曖昧だが）
0466デフォルトの名無しさん
2010/05/04(火) 18:20:05>「何を統一して欲しい」
コンピュータ手続き処理
ISO9000 シリーズを参照
0467デフォルトの名無しさん
2010/05/04(火) 18:37:53かわいそうに
かわいそうに
0468デフォルトの名無しさん
2010/05/04(火) 18:52:56>>466 はコンピュータ手続き処理というものが統一して欲しい対象だと解釈している。
どっちなんだ？ どっちも違うのか？
それともコンピュータ手続き処理とやらは UML で統一できるのか？
■ このスレッドは過去ログ倉庫に格納されています