09/10/18 17:54:43
コマンドラインプログラムならなんとかできるんだけど
GUIは私の知能じゃむり
2:デフォルトの名無しさん
09/10/18 18:00:37
糞スレ立てんな
3:デフォルトの名無しさん
09/10/18 18:03:39
gomen
4:デフォルトの名無しさん
09/10/18 18:07:14
でもでもCUI->GUIって急に難易度あがりすぎじゃありません？
5:,,・´∀｀・,,）っ-○○○
09/10/18 18:09:16
6:デフォルトの名無しさん
09/10/18 18:14:40
敢えてGUIプログラミングには手を出さずに突っ走るのもありだ。
7:デフォルトの名無しさん
09/10/18 18:18:30
SDL とか簡単だよ。
8:デフォルトの名無しさん
09/10/18 18:21:33
Xlibだけ使って一から書いてた頃はそーとー苦労したが、
今はいくらでも簡単に作れるジャマイカ
9:デフォルトの名無しさん
09/10/18 18:43:04
Win32APIを自分でラッピングするのがお勧め。
自前でサンクとかやれば色々と応用が利く。
10:デフォルトの名無しさん
09/10/18 18:49:46
wxとかgtkはうんこ、xlibは拷問、Qtでそこそこ
11:デフォルトの名無しさん
09/10/18 18:55:53
guiって、C#やVBだと簡単だね。
MFCも簡単だけど、フレームワークって言うのに抵抗があるかも・。
12:デフォルトの名無しさん
09/10/18 18:58:21
MFCと比べればQtが極楽に思えるぐらいMFCはうんこ
13:デフォルトの名無しさん
09/10/18 18:59:07
VCL MFC WTL WindowsForm WPFは？
14:デフォルトの名無しさん
09/10/18 19:01:21
CUIは作るのが簡単だからね。
出力は標準出力。
入力は標準入力。
オプションは引数。
これだけだもの。
GUIだと、それらができるのは当たり前。
使いやすいように、オプションの配置を考えて
グループ分けし、状況に合わせてツリー表示やテーブル表示にし、
ユーザーの希望にあわせてウインドウをリサイズし、
説明も表示し、環境に合わせて言語も変える。とか
”使いやすい”を目指して作らないといけない。
15:デフォルトの名無しさん
09/10/18 19:03:12
WPFはSヨやってる友人達がベタぼめしてた
ATL/WTLはC++ヲタの人達にはそこそこ評判いいみたいだけど、
結構癖が強いんで、それならQtでいいやーみたいな
今さらやるならC#でWPF使っとくのが一番手っ取り早いんじゃない？
Windows使えねーって人達はQt触るなりcppguiに期待するなり、
PerlやPythonのtkバインディング使うなりするのがよろし
16:デフォルトの名無しさん
09/10/18 19:04:50
つ
ここいっとけ
Lily C++ GUI Library
URLﾘﾝｸ(kengolab.net)
17:デフォルトの名無しさん
09/10/18 19:07:18
見た目をそれほど気にしなくていいので、本来の処理に集中出来るという
意味では楽だけど、network とか curses を使うならそれなりに面倒だよ。
18:デフォルトの名無しさん
09/10/18 21:21:01
大学のプログラミングの授業でもGUIは全然やらなかったなあ…
全部Unixのコマンドラインでやってたよ。
19:デフォルトの名無しさん
09/10/18 21:22:54
時間の限られているような「講義」という形でGUIなんて茨の道すぎる
20:デフォルトの名無しさん
09/10/18 22:29:42
GUIが難しい理由：
VB亡き後の後継の筈のActive BASICが.NET路線を
追いかけてしまい停滞しているからw
21:デフォルトの名無しさん
09/10/18 22:37:04
Active BASICいらねーよ
この開発者は無駄に人生使ってる
22:デフォルトの名無しさん
09/10/19 00:17:43
>>19
部品張ってイベント処理書くだけなのに茨の道もクソもあるか。
23:わかんないんです（＞＜） ◆WAkan9Ey1g
09/10/19 00:56:39
わかんないんです（＞＜）
24:デフォルトの名無しさん
09/10/19 00:59:01
GUIライブラリが色々あり杉て困る件。
標準入出力とか、コマンドラインの引数みたいに標準ライブラリの枠組みの中に
会ったらよかったのに。
25:デフォルトの名無しさん
09/10/19 00:59:47
Qtが一番マシかなって感じ……
26:デフォルトの名無しさん
09/10/19 01:03:41
>>24
GUIだけならいいんだが、それ以外のも一緒についてくるのは確かに嫌だな。
STL使えばいいのになぜか独自のコレクションクラス使ってたり。
27:デフォルトの名無しさん
09/10/19 01:23:46
難しくない
めんどくさいだけ
28:デフォルトの名無しさん
09/10/19 02:57:59
難しいかどうかは、MVCを理解できるか否かにかかると思われ。
VB系のGUIツール前提という開発の呪縛から逃れることを勧める。
29:デフォルトの名無しさん
09/10/19 03:28:12
最近のGUIツールはすべてVB系と大差ない気がするんだが。
30:デフォルトの名無しさん
09/10/19 03:34:35
android の GUI は部品間のつながりを XML で記述するので、ロジックと分離できて便利。
31:デフォルトの名無しさん
09/10/19 06:48:55
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
32:デフォルトの名無しさん
09/10/19 12:38:02
アイちゃん遅いよ……
33:デフォルトの名無しさん
09/10/19 12:40:13
アイちゃんが遅いんじゃないぞ
34:デフォルトの名無しさん
09/10/19 18:04:54
アイちゃんより比呂美のほうが好きだ
35:デフォルトの名無しさん
09/10/19 21:29:10
>>1 そうそう。GUIアプリの開発演習になると途端にハードルが高くなるよね？
36:デフォルトの名無しさん
09/10/19 21:30:32
Lily C++ GUI Library
URLﾘﾝｸ(kengolab.net)
37:デフォルトの名無しさん
09/10/19 21:32:32
最近 Qt の宣伝多いな…
38:デフォルトの名無しさん
09/10/19 21:34:37
Lily ≠ Qt
39:デフォルトの名無しさん
09/10/19 21:37:08
俺は Qt の宣伝が多いとしか言ってないが
40:デフォルトの名無しさん
09/10/19 21:44:10
DirectX！
そうゆう事を言ってるわけじゃないですね、はい。
41:デフォルトの名無しさん
09/10/19 23:24:57
DirextSEX!
42:デフォルトの名無しさん
09/10/19 23:26:38
マルチプラットフォームだとQtぐらいしかない
WindowsならWPFでも使ってればいい
MacはCocoaにしてもCarbonにしても塵
43:デフォルトの名無しさん
09/10/19 23:29:37
>>42
> MacはCocoaにしてもCarbonにしても塵
なんで塵なの？
44:デフォルトの名無しさん
09/10/19 23:41:05
そういう年頃なんだろ
45:デフォルトの名無しさん
09/10/20 00:38:41
GUIは仕様書が死ねる。
遷移図が超カオス
46:デフォルトの名無しさん
09/10/20 01:24:21
>>45
規模が大きくなりすぎないように分割して行くから、
仕様書は、たいてい、ユースケース記述＋クラス図＋シーケンス図でカバー出来てるな
47:デフォルトの名無しさん
09/10/20 09:00:57
>>46
そういった(コーディングから離れて)設計に立ち返る意識が持てる
境地に達していれば、無問題だろな。
遷移マシンがMVCのM(モデル)であることに気が付くこと(>>45)が、最初の一歩。
48:デフォルトの名無しさん
09/10/20 10:18:20
Viewの遷移とModelの遷移は別物。混同するとぐちゃぐちゃになる。
49:デフォルトの名無しさん
09/10/20 10:20:39
Viewに遷移などない
50:デフォルトの名無しさん
09/10/20 10:29:13
ViewはModelの状態を参照するけど、View自身は状態を持たないから、
遷移そのものが存在しないわな
51:デフォルトの名無しさん
09/10/20 11:05:17
要するにブラウザーの状態とサーバーの状態だろ
「ブラウザー自身は状態を持たない」は正しくないこともない
52:デフォルトの名無しさん
09/10/20 11:45:46
ちょっと違うかな。
一般にViewとModelは同一マシン(メモリ空間上)に存在するから、VはMの状態を参照できる。
一方、もし>>51がWebの事を言っているなら、Client(Webブラウザ)とServer(Webサーバ)は、
ネットワーク上で分散しているから、ClientはServerの状態を(直接的には)参照できない、
という違いがある。したがって、ClientもまたMVCパラダイムで設計され、ClientのMと
Server(Mのみ)との間で、規約(HTTP)に従った通信が必要になる。
53:デフォルトの名無しさん
09/10/20 15:26:00
>>41
そういやオカモトのスタンダードタイプは\500～\3000まであるが、
いったい何が違うんだろう。装着感？
54:デフォルトの名無しさん
09/10/20 16:10:05
うすうす
55:デフォルトの名無しさん
09/10/20 16:10:52
GUIの難しさの本質？
GUIから新しい言語が出来てしまって、それらの言語がデファクト
スタンダートを作っているから
そしてそれらの言語の特徴（矛盾しているわけではないが、
流儀としては排他的）が相互汚染防止の為に反目しあってること
56:デフォルトの名無しさん
09/10/20 17:35:40
Intermediate Rails: Understanding Models, Views and Controllers | BetterExplained
URLﾘﾝｸ(betterexplained.com)
これの図を見るとMVCは全部鯖側にあるようにみえるんだけど
一言にMVCと言っても色々あるんだなー
57:デフォルトの名無しさん
09/10/20 17:40:46
Win32++
URLﾘﾝｸ(sourceforge.net)
これよさげ
情報、日本語訳求む。
ヘッダオンリーでATLやWTLより簡単げ。
58:57
09/10/20 23:26:53
よさげとおもって紹介してみたけどレス無い・。・。
59:デフォルトの名無しさん
09/10/20 23:58:56
MVC ってよくわからん。
M がデータ処理で V がアウトプットで C がインプットで大体合ってるの?
60:デフォルトの名無しさん
09/10/21 00:08:12
>>57
思いつきで作ってみました的なモノでは無く、きちんと公開して多くの人に使ってもらえる事を
意識したプロジェクトに見える。ドキュメントやサンプルも整備されてるし(英語だけど)。
UNIX(C)&Mac(realBasic)プログラマなんだが、C++とWinには以前から挑戦したいと思ってた。
だから、なかなかシンプルで良さげに見えた。とは言ってもWin32 APIは初めて見たわけだが....。
で、一部の翻訳に着手したよ。ヘルブの中にある概要("Win32++ Overview")の章。
明日くらいには公開できると思う。興味あるかな？
61:デフォルトの名無しさん
09/10/21 00:28:18
thx!楽しみにしてます!
62:デフォルトの名無しさん
09/10/21 05:30:37
>>60
日本で唯一解説しているらしいところはここだけみたいです。量少ない。
URLﾘﾝｸ(naruishi.hp.infoseek.co.jp)
63:デフォルトの名無しさん
09/10/21 09:50:04
>>58
まともな日本語も掛けない奴のレスなんか、レス返す価値などないと思ったんでね。
# つーか、なんだよ、「簡単げ」ってよ。
64:デフォルトの名無しさん
09/10/21 09:58:13
無理ゲー
65:デフォルトの名無しさん
09/10/21 11:19:25
>>60
>興味あるかな？
私が翻訳権を持ってるわけじゃないのでどうでもいいっちゃいいんですが
許可を得ているのかどうかにはちょっとだけ興味があります。
66:60
09/10/21 14:38:51
Win32++の翻訳文書を公開した。
・Win32++概要
URLﾘﾝｸ(www.h6.dion.ne.jp)
Windowsプログラミングは未経験なので、不適切だったり誤っている箇所があると思う。
特に、リバーコントロール(Rebar Control)/メッセージの反射(Message Reflection)/
CWndオブジェクト/WndProc関数に関連した部分は、無理矢理に訳した感がある。
Win32 APIに詳しい住人さん達からのツッコミに期待。
67:デフォルトの名無しさん
09/10/21 15:01:25
二次的著作物とは、著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、
その他翻案することにより創作した著作物をいう（2条1項11号）。
二次的著作物に対する著作権法の保護は、原著作物の著作者の権利に影響を及ぼさない（11条）。
著作物 - Wikipedia
68:デフォルトの名無しさん
09/10/21 16:15:34
>>56
MVCは、元々は普通の(ネットワークとは無関係な)GUIアプリ開発の中から生まれた。
それがWebアプリにも取り入れられるようになった経緯がある。Railsは、その代表格だね。
最近では、Webクライアント上で動くJavaScriptアプリにも取り入れられつつある。
SproutCoreと呼ばれるAJAXフレームワークが、その一例。
・SproutCore Documentation / Basics-Introducing SproutCore MVC
URLﾘﾝｸ(wiki.sproutcore.com)
だから、SproutCoreを利用するWebシステムでは、以下の３つのMVCが、同時に存在することになる。
・Webサーバ上で動くアプリケーションのMVC -- 例: Rails
・Webブラウザ自身のMVC -- このスレでの話題の中心となる、GUI向けのMVC
・Webブラウザ上で動くアプリケーションのMVC -- 例: SproutCore
>>59
思いっきり単純化すると、そのイメージで合っているよ。
・Mは、ユーザインタフェースを持たない、データ管理だけのオブジェクト。
・Vは、Mのデータを表示(出力)するオブジェクト。ユーザから見える部分になる。
・Cは、ユーザの操作(入力, 例:ボタンを押す)を受け付け、MやVへメッセージを送って、
全体を制御するオブジェクト。
69:デフォルトの名無しさん
09/10/21 16:21:57
>>67
翻訳したものに関してはね。
翻訳できるかどうかが問題で
第二十七条 著作者は、その著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する。
だからこそ、翻訳権や翻案権は明記されない限り著作者から自動的に
移譲されたりはしないことになっている。
第六十一条 著作権は、その全部又は一部を譲渡することができる。
2 著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。
70:デフォルトの名無しさん
09/10/21 17:38:05
Win32++はMITライセンス =修正BSDライセンス
前述のGPLやLGPLに比べて、格段に制約の緩いライセンスとなっています。
制約となる条件がたった２点しかありません。
１つ目は「再配布時には著作権表示を残す」という事。
もうひとつは「無保証である」という事。
この２点を守りさえすれば、どのように利用しても構いません。
ライセンスをGPLに変えて再配布するもよし、
改変して独占販売するもよし、
ソフトウェアだけ頒布してソースを非公開にしてもよし。
URLﾘﾝｸ(smkn.xsrv.jp)
71:デフォルトの名無しさん
09/10/21 17:41:47
要するに、元著作者の名前を入れておけばいいってことだけ。 無保証って言うのは持続しなくてもいい。
利用条件は、
無保証
著作権表示の保持
MIT License (X11 License)
URLﾘﾝｸ(ja.wikipedia.org)
72:デフォルトの名無しさん
09/10/21 19:54:28
>>1に禿同
本質的に難しい（複雑）なのかもしれないけど、
どちらかというとライブラリが足引っ張ってると思う
73:デフォルトの名無しさん
09/10/21 20:12:23
>>68
どうもありがと！
これで MVC は理解して卒業した事にします。
74:デフォルトの名無しさん
09/10/21 20:24:15
駄目
POSAのvol1の130ページあたり読むまで許さない
75:デフォルトの名無しさん
09/10/21 20:25:03
実際に自分でプログラムしなきゃ
理解したことにはならんだろｗ
76:デフォルトの名無しさん
09/10/21 20:39:27
実際のコーディングはどうせライブラリのスタイルに合わせないといけないので、
モデルの話は常識程度に抑えておこうと思ってます。
77:デフォルトの名無しさん
09/10/21 20:39:33
Model View ControllerはArchitecural Patternsだから
詳細設計あたりまでもってくれれば十分
でもそこまで考えたらコードまで落し込んで動かす所まで持っていきたくなるから同じことか
78:デフォルトの名無しさん
09/10/21 21:04:59
もうさ、MVCが基本とかいう幻想は早く捨て去ろうよ
あんなもの、単にオブザーバーパターン使ってみましたってだけじゃん
GUIのGの字も語ってない
それよりも、FRP（Functional Reactive Programming）とか参考にした方がまだまし
79:デフォルトの名無しさん
09/10/21 21:15:00
それなりに効率よく、綺麗に扱うには
Future valueとかMonadとかApplicative Functorとか
普通の言語で使うには難しいfeaturesが必須ですけどね
80:デフォルトの名無しさん
09/10/21 21:20:27
そういう様式論って殆ど実りが無いんだよな…
マーケティングのバズワードとかハイプとかと同じ匂いがする
81:デフォルトの名無しさん
09/10/21 21:22:40
様式論のバズワードの筆頭がデザパタ
82:デフォルトの名無しさん
09/10/21 21:23:05
関数型言語風のMVCとしてはtangible valueというものもあるけどあれも続報を聞かない
83:デフォルトの名無しさん
09/10/21 21:25:01
>>79
「それなりに」の程度によるけど、「実用的」というレベルならHaskellじゃなくても全然いける
連続的な時間を扱いたかったら確かに遅延評価がないと厳しいけど、
離散的な時間でよく、なんちゃってFRPならどの言語でも（もとい、ML系なら）無問題でしょ
実際OCamlでもそんなライブラリがあるし
84:デフォルトの名無しさん
09/10/21 22:42:36
>>72
ライブラリが足引っ張ってる部分というのは、具体的にはどの部分なのかな？
自分が>>1の言う難しさが何であるかを考えるに、コマンドラインの対話型プログラミングは、
メニュー出力/コマンド入力/コマンド実行/実行結果出力をループさせる処理になる。
コードは、フローチャート(流れ図)という言葉があるように、連続した処理の塊(かたまり)として
読む事ができる。これに対して、GUIプログラミングでは、入力イベントごとの対応する手続きが、
断片としてコード全体に散らばってしまう。この為、プログラムを読む側からすれば、
流れるような処理ではなく、実行部分がコードのあちこちを無秩序に飛び回っているように見える。
この可読性の悪さが、GUIプログラミングを難しいものに見せているのだと思う。
85:デフォルトの名無しさん
09/10/21 22:52:46
GUIプログラミングの新時代は関数型言語が開くのか
86:デフォルトの名無しさん
09/10/21 22:53:08
コマンドラインでも curses とか使ったアプリはイベント駆動だね。
>>1 が言ってるのは入力待ちでブロックする様な単純なプログラムか
フィルタ系なのかな。
87:デフォルトの名無しさん
09/10/21 23:10:16
さすがに>>1がcursesを使っている人物だとは、ちょっと思えないがなぁw
88:デフォルトの名無しさん
09/10/21 23:27:55
>>84
足引っ張ってるのは、色々あるけど、一つはレイアウト
あれはクソ
>流れるような処理ではなく、実行部分がコードのあちこちを無秩序に飛び回っているように見える。
>この可読性の悪さが、GUIプログラミングを難しいものに見せているのだと思う。
禿同ですな
イベントからの条件分岐と「目的の処理」を分離して欲しい
89:デフォルトの名無しさん
09/10/21 23:40:25
>>85
いや、その前に関数型言語が一般のプログラマに受け入れられる事が先だ
いかに関数型言語を使うことで美しく簡潔なGUIアプリケーションが書けたとしても、
関数型言語が一般のプログラマに使ってもらえなければ、
(GUIプログラミング新時代への移行に関しては)何の意味も持たない
オブジェクト指向言語も、過去に同じような批判を受け、それに耐えて現在の地位を得ている
90:デフォルトの名無しさん
09/10/21 23:42:33
つ JavaScript
みんな function(){ ... } ってラムちゃんを書きまくってるからオケ。
91:デフォルトの名無しさん
09/10/21 23:47:58
ここで、Win32++を推奨していこう。あとwiki作って広めるか。
URLﾘﾝｸ(sourceforge.net)
92:デフォルトの名無しさん
09/10/22 00:19:48
>>91
それさ、何が嬉しいのかいまいち分からないんだが、説明してもらえる？
93:デフォルトの名無しさん
09/10/22 01:06:04
>>90
でも、そのラムちゃんって不純だからなぁ....
94:デフォルトの名無しさん
09/10/22 01:40:15
何か問題あるんだっけ?
95:デフォルトの名無しさん
09/10/22 03:56:29
WPFってかなり素性のいいフレームワークだと思うんだけど
MSと.netというだけで評価されない風潮がある感じがして悔しい
cssのdiv厨ならぬGrid/StackPanel厨になっちゃうのがアレだけど
96:デフォルトの名無しさん
09/10/22 07:00:36
そもそもWPFっていう単語が何なのかまったくわからん。
WindowsPrintFoundation?
97:デフォルトの名無しさん
09/10/22 07:53:15
>>90
あれは関数型言語の一部のガワだけを拝借しているに過ぎない。
プログラミング スタイルが本質的に異なるから、
ラムちゃんを書きまくってるからオケとはなかなかいかない。
98:デフォルトの名無しさん
09/10/22 07:56:57
つまり、純なラムちゃんじゃないと俺の嫁じゃない
そういうことだな？
99:デフォルトの名無しさん
09/10/22 09:30:19
そもそもGUIは本質的に難しさを抱えてるものだから、
どの言語、フレームワークを使っても一定以上には簡単にならないと
マが覚悟を決めないと話にならんよね。
100:デフォルトの名無しさん
09/10/22 09:30:37
そうよ、ダーリン
101:デフォルトの名無しさん
09/10/22 10:08:16
…………。 さぶっw
102:デフォルトの名無しさん
09/10/22 10:42:47
純であることに拘ったって、どうせおまいらが不純にするんだろ。
最初から不純だっていいじゃないか。
103:デフォルトの名無しさん
09/10/22 10:53:29
もちろん不純オーケーな言語もあるし(例:OCaml)、
はじめから不純前提な言語(例:JavaScript)もある
でも、純であることにトコトンこだわった言語、
つまり純なプログラミングしか許さない言語(例:Haskell)もある
そんな純な世界だけでも、GUIプログラムは書けるんだ
104:デフォルトの名無しさん
09/10/22 11:41:11
まあ、アセンブラだけでもGUIプログラムは書けるしな。
105:デフォルトの名無しさん
09/10/22 11:52:03
つまりは、そういうこと
書ける事と、それがやさしい/むずかしいとは別の話
特に、はじめてGUIプログラミングに挑戦しようとする人にとって、
少なくとも現状だと、関数型言語の壁は、あまりに高すぐる
106:デフォルトの名無しさん
09/10/22 15:15:52
>>92
60の訳より。
Win32++はアプリケーションを開発する為のWindows APIを直接使用するライブラリを提供しています。
Windows 95からWindows XPとVistaに到る32bit、64bitのすべてのMicrosoft OSおよびWindowsCEをサポートします。
このライブラリは、単純なウィンドウ、ダイアログ、フレーム、そしてMDIフレームをベースとしたアプリケーションを開発できます。
また直接Windows APIを扱うプログラミングにオブジェクト指向アプローチをもたらします。
Borland、Microsoft、GNUコンパイラなど 幅広いC++コンパイラをサポート。多言語サポート。
107:デフォルトの名無しさん
09/10/22 19:24:39
>>103
>純なプログラミングしか許さない言語
確か破壊的に書く方法もあったよね。アクションだっけ？
Haskell が良いのは、副作用を禁止するのではなく副作用を
分けて記述出来る事だった様な気がするけど、俺の勘違いかな。
108:デフォルトの名無しさん
09/10/22 20:26:43
>>105
関数型言語（文脈から考えると純粋関数型？）でのGUIプログラムは
手続き型言語でのそれより（現状）難しいと感じてるようですが、
そう感じる理由は何でしょうか。
それは単にスタンダードと呼べるGUIライブラリが整備されておらず、
それに対する入門書も無い状態だからでしょうか。
もしそうなら、それは関数型言語に対して感じる壁とは違うような気がします。
109:デフォルトの名無しさん
09/10/22 20:39:06
>>108
>>105 が難しいと思ってる訳じゃないんじゃないの。
『はじめてGUIプログラミングに挑戦しようとする人にとって』、
壁が高いというのは、俺も同意見だな。
110:デフォルトの名無しさん
09/10/22 20:43:31
>>109
その壁が何に対して感じる壁なのか、が訊きたいです。
また、何故その壁は高く感じられるのでしょうか。
111:デフォルトの名無しさん
09/10/22 21:05:53
君は壁なんか存在しないと思ってるの？
112:デフォルトの名無しさん
09/10/22 21:07:01
>>110
状態を持ちにくいからだろ。
だいたい、GUIなんて俺には副作用の塊に見える。
113:デフォルトの名無しさん
09/10/22 21:13:22
>>110
横槍
たぶん入門書に載ってないからだと思われ
例えばFRPの一部であるevent（の簡易版）は、
Visual Studio 2010のF#にfirst-class composable eventsとして登場する予定
そして、それが「3日でわかる!! VisualStudio 2010」とかで紹介される事になる
そうすると、急に壁が低くなる（と多くの人は錯覚する）
要するに、技術そのものの壁じゃなくて心理的なものだと思う
114:デフォルトの名無しさん
09/10/22 21:16:52
>>111
初めてGUIプログラムをする者にとっての壁はあると思いますが、
それは関数型言語に備わった、関数型言語だからこその壁では無いような気がします。
初めてGUIプログラムをする者は初めてGUIの概念や考え方、組み立て方を学ぶわけですから、
それを関数型言語をベースにして学ぼうが、手続き型言語をベースにして学ぼうが、
壁は同じくらい高く感じられると思います。
そして、それは言語ではなくGUIに対して感じる壁だと思います。
私はどちらのGUIも経験しましたが、確かに関数型言語での方が勉強に時間がかかります。
ただ、それは単に資料が少ないというだけのことで、関数型言語の言語としての壁は感じませんでした。
手続き型の方が資料が少なければ、手続き型の方の勉強に時間がかかったと思います。
115:デフォルトの名無しさん
09/10/22 21:17:17
>>108,110
なにか関数型言語に対する(いい意味での)思い入れがある人みたいだから、
壁が何かを質問するよりも、率直に、関数型言語の良さをカキコしたほうがいいんじゃないかな
たとえば「関数型言語は....という特徴があるから、GUIプログラミングに適している」みたいに
116:デフォルトの名無しさん
09/10/22 21:18:34
各プラットフォームのネイティブの GUI ライブラリが関数型言語で実装されてないから
ハードルは高くなるよな。格闘技の基礎が無いのに異種格闘戦に出るなんて…
117:デフォルトの名無しさん
09/10/22 21:23:17
>>114
資料が少ないのが関数型の特徴だから、手続き型の方が資料が少ないという仮定は
あんまり意味が無いと思う。
118:デフォルトの名無しさん
09/10/22 21:26:54
>>115
いえ、思い入れは全くないんですし、
>>105 に対して関数型はいいよとかアピールする気も全く無いんです。
ただ、>>105 以外でもよく見かけますが、
関数型言語をベースにして、その上で組み立てる物の難しさに対して、
「関数型言語の壁」と言うように言語特有の難しさに括ってしまうのは、
ちょっと違和感を感じただけです。
119:デフォルトの名無しさん
09/10/22 21:29:28
俺も>>112に禿同。
120:115&105
09/10/22 21:35:17
# リロードせずにカキコしちまったゼ
>>114
言いたい事は分かるし、その通りだと思うよ
でも、ここでは「プログラミング言語そのものを比較」をしてるんじゃなくて、
「GUIプログラミングのむずかしさ/やさしさを議論」しているスレなんだ
このスレでは、言語はGUIを実現するための道具、副次的なものであるという立場
>>105で書いた「関数型言語の壁」というのは、他の住人さん達が語っているように、
単純に初心者向けの情報が少ないってことを言いたかった。
121:デフォルトの名無しさん
09/10/22 21:35:29
実際>>112みたいな問題って関数型だとモナドやカリー化、継続みたいな難しそうな概念を使って解決してるんだろ？
詳しくないから想像だけど。
122:デフォルトの名無しさん
09/10/22 21:47:20
>>116
>格闘技の基礎が無いのに異種格闘戦に出るなんて…
面白い「たとえ」だね。ワロタよ。同感だ。
関数型言語に思い入れのある格闘家さん達は、今は己の技を磨くことに集中したほうがいいと思う
気持ちは分かるんだけど、なぜ自分達の流派が分かってもらえないんダァーと、いくら主張しても、
今の格闘センスでは、空回りに終わるか、かえって他の保守的な格闘家達からの反発をまねくだけ
123:デフォルトの名無しさん
09/10/22 21:50:45
>>121
実際 >>112 みたいな問題はライブラリがやってくれるから、
それを使うだけのユーザーは、
どうやって実現しているのか意識する必要すらないです。
たとえば .NET Framework で
WFC がどうやってイベントのチェーンを実現しているのか
ユーザーは考える必要がないのと似ています。
だから、実際ライブラリを使うだけなら、
その資料とチュートリアルがあれば、
GUI 入門者でもちゃんと（使い方の）勉強はできます。
だから、「純粋にGUIプログラムを組むまでに至る難しさ」という点では
手続き型でも関数型でも同じ程度だと思います。
好奇心があってその内部処理を勉強しようとした時に、
初めて（純粋）関数型言語特有の考え方が顕著に現れてきます。
124:デフォルトの名無しさん
09/10/22 21:57:08
>>123
すいません、WFC ではなく WPF です。
・・・なんか違和感あると思った
125:デフォルトの名無しさん
09/10/22 21:57:17
関数型言語がむずかしすぎる(´・ω・｀)
126:デフォルトの名無しさん
09/10/22 22:00:09
>>123
なるほどー。けどそうなると初学者は関数型でのGUIプログラミングは言語特性との矛盾を感じながらの実装になりそうだからストレスフルだと思う。
そこが壁なんじゃない？
127:デフォルトの名無しさん
09/10/22 22:02:02
関数型言語にも、.NET Framework みたいな網羅的なライブラリがあって、
日本語のドキュメントやサンプルコードが豊富に揃っていればそうでしょうね。
ライブラリは FFI なんかで呼び出すとしても、ドキュメント類が無いから
何か詰まったら初心者にはお手上げじゃないかな。
128:デフォルトの名無しさん
09/10/22 22:02:30
>>126
ん？ 言語特性との矛盾とは？
129:デフォルトの名無しさん
09/10/22 22:02:47
>>123
>好奇心があってその内部処理を勉強しようとした時に、
このスレの住人の好奇心はGUIプログラミングに向いているんだが....
関数型言語に好奇心があるのなら、該当するスレへ逝って、そこで大いに語れ
130:デフォルトの名無しさん
09/10/22 22:03:37
>>123
>「純粋にGUIプログラムを組むまでに至る難しさ」
むしろ不純な部分として議論から省こうとしてる部分が大事だったりするんだよね。
「現実的にGUIプログラムを組むまでに至る難しさ」は大いに違う訳だし。
131:デフォルトの名無しさん
09/10/22 22:04:14
なんだかんだでGUIはオブジェクト指向型言語の独壇場じゃね。
面倒なステート管理、プロパティ設定を程よく抽象化してくれる。
132:デフォルトの名無しさん
09/10/22 22:07:14
>>131
俺もそう思う。イベントドリブンなプログラムとオブジェクト指向の相性は抜群。
133:デフォルトの名無しさん
09/10/22 22:10:27
>>128
「基本副作用無しのはずなのになんでウインドウ出せるの？」
「ボタン押したら現在時刻をポップアップする機能って呼び出しから結果が定まらなくね？」
みたいな事だよ。
134:デフォルトの名無しさん
09/10/22 22:14:02
>>130
手続き型言語で CUI を学んだ者が GUI にステップアップするのと、
関数型言語で CUI を学んだ者が GUI にステップアップするのとで、
GUI をプログラムするに至るまでの難しさは、それほど違うものでしょうか。
>>1 がどちらのタイプかは知りませんが。
135:デフォルトの名無しさん
09/10/22 22:14:07
GUIの難しさって、要するに何やるにもライブラリに合わせないといけないことだとおもう。
全部自分で書くのは無謀過ぎるんでライブラリ使うことになるけど、そうするとライブラリに合わせた書き方をするしかない。
136:デフォルトの名無しさん
09/10/22 22:19:36
>>134
違うと思うよ。理由は散々出てると思うけど。
137:デフォルトの名無しさん
09/10/22 22:19:44
>>135
「何やるにもライブラリに合わせないといけない」ってのは、GUIに限らず、
あらゆるプログラミング(標準入出力ライブラリを含む)で共通じゃね
GUIのむずかしさとは違う希ガス
138:デフォルトの名無しさん
09/10/22 22:21:33
>>131
>面倒なステート管理、プロパティ設定を程よく抽象化してくれる。
じゃぁ「むずかしすぎる」訳ではないと？
139:デフォルトの名無しさん
09/10/22 22:21:38
>>137
ライブラリの規模が違うでしょ
GUI のライブラリの規模を無視して一般化しようとしてもダメなんじゃないかな
140:デフォルトの名無しさん
09/10/22 22:27:59
>>133
あぁ、なるほど、それなら納得です。
確かに初学者が感じる壁はその辺りにあります。
ただ、たいていの関数型言語を学ぶ者は、CUI プログラムを学んでいる途中で、
上記のような壁をできるだけ低くするように働く概念を学びますから、
GUIでその壁に当たっても、合点がいくには至りませんが、
ストレスフルとなるまでにはいかないような気がします。
そこでストレスフルとなるなら、CUIで勉強し直した方がいいですし。
まぁ感じ方は人それぞれですが。
はい、確かにその辺りに関数型言語でのGUIの壁がありますね。
納得しました。
141:デフォルトの名無しさん
09/10/22 22:29:53
>>131
細かいツッコミだけど「オブジェクト指向型言語」じゃなくて、
「オブジェクト指向手続き型言語」あるいは簡略に「オブジェクト指向言語」だろね
研究レベルだけど、オブジェクト指向分散関数型言語なんてのもあるから(例:ABCL)
142:デフォルトの名無しさん
09/10/22 22:36:32
>>138
どうだろ？
「なんとか一般の人間様に制御可能なレベルになった」ってレベルじゃね？
微分とか積分とかがわからん奴には「難しすぎる」ってレベルぐらいには難しいと思う。
アップルのGUIが優れてるのは何か優れた手法をとっているとかではなくて、
それこそジョブスの鬼のようなシゴキで調整されているからなんだと思う。
143:デフォルトの名無しさん
09/10/22 22:37:49
>>139
ならば、科学計算ライブラリは、ライブラリに合わせずにプログラミングできるの？
「何やるにもライブラリに合わせないといけない」というのは、
GUIプログラミングに固有のむずしさではないと思うよ
「GUIライブラリの規模(複雑度)が大きいから」むずかしい、という理由も同じだね
144:デフォルトの名無しさん
09/10/22 22:42:15
GUIの理論的なモデルってあるの？
知っている人がいたら教えてプリーズ
「なんか便利そう」で対応してたんじゃ拉致があかない
145:デフォルトの名無しさん
09/10/22 22:45:23
>>143
同じだと思う根拠は？
146:デフォルトの名無しさん
09/10/22 22:46:09
>>144
GUIの理論的なモデルって、どういうのを期待してるんだ？
147:デフォルトの名無しさん
09/10/22 22:47:16
コマンドラインやっとだったらズブの初心者だろう。
CUIもまともに出来ないんじゃないの?
148:デフォルトの名無しさん
09/10/22 22:52:16
科学計算ライブラリが具体的にどのライブラリをさしているのか分からんけど、
XMLのパースとかレイトレとかは殆どフルスクラッチで書けるからライブラリの
仕様に合わせる必要は無い。GUI をフルスクラッチで書くのは規模的に難しい。
コピペとかドラッグ＆ドロップとか日本語入力変換とかベクターフォントの描画とか
一から作るのはごめんだ。
149:デフォルトの名無しさん
09/10/22 22:55:21
GUIをモデル化したらCUI化するに違いない
150:デフォルトの名無しさん
09/10/22 22:58:06
もう飽きたし面倒くさいから
標準入出力でいいわ。
151:デフォルトの名無しさん
09/10/22 22:58:14
>>146
期待する性質としては、こんな感じ
1 その理論は描画とGUIコンポーネントとその組み合わせの世界を抽象化している
2 非同期に発生するイベントと内部状態の遷移と描画の結果と時間との関係を明らかにしている
3 抽象化された世界に必要十分な操作が導き出せる
4 必要十分な操作から便利な操作が合成でき、結果としてGUIライブラリの理想形が見えてくる
欲張りすぎか...
152:デフォルトの名無しさん
09/10/22 22:58:24
>>144
拉致しちゃダメよw
153:デフォルトの名無しさん
09/10/22 23:12:53
>>151
すまん、いまいち分からん。
その性質を一部でも満たした既存のモデルは何か無いか？
あるいは一部なら満たすモデル案を君が既に考えているとか。
それらと対比してくれると理解できると思うんだが。
154:デフォルトの名無しさん
09/10/22 23:24:14
>>148
たぶんHaskellみたいな近代的な関数型言語のことを言っているのだと思う
でも、たとえばXMLのパーズくらいはフルスクラッチで書けるとあるけど、
XMLスキーマに基づくXML文書の検証も可能なXMLパーザも
Haskellならばフルスクラッチで書けるのかな？無理じぇね？
Haskellがそれほどフルスクラッチで書ける素晴らしい言語なのだとしたら、
GUIくらいはフルスクラッチでサラッと書いて欲しいものだと思うよ
155:デフォルトの名無しさん
09/10/22 23:32:57
>>154
俺は関数型言語の御仁とは別人だよ。Haskell はどうでも良い。
>>137 に、
>「何やるにもライブラリに合わせないといけない」ってのは、GUIに限らず、
>あらゆるプログラミング(標準入出力ライブラリを含む)で共通じゃね
とあるから、それは違うよねと言ってるだけだよ。
例えばレイトレは違うから「あらゆる」というのは間違い。
言ってる事通じてるかな。
156:デフォルトの名無しさん
09/10/22 23:38:36
実際のところ GUI ほどライブラリのお仕着せが強い分野もそうそうないでしょ。
しかもそれが殆ど標準化されてない。
157:デフォルトの名無しさん
09/10/22 23:38:48
>>153
Fudgets
URLﾘﾝｸ(www.cs.chalmers.se)
これにはコンポーネント同士を演算する仕組みがあって期待するものにちょっと近い
でもまだ遠い
158:デフォルトの名無しさん
09/10/22 23:40:30
GUIはまだまだハッテン途上だね
159:デフォルトの名無しさん
09/10/22 23:40:53
>>>>137 ってさ、
各ライブラリの使い方にはクセや流儀があるから、
そのクセや流儀にプログラマの方が合わせなくちゃいけない、
それは GUI ライブラリに限ったことじゃないよ、といいたいんだと思うが。
レイトレを実行するライブラリというものがあるとして、
そのライブラリもやっぱり作法みたいなものがあると思うが、
プログラマはその作法に合わせなきゃいけないんじゃないの？
160:デフォルトの名無しさん
09/10/22 23:43:10
>>157
さんきゅ
今日はもう眠いから、明日読んでみる
161:デフォルトの名無しさん
09/10/22 23:45:35
>>159
小規模のライブラリなら自分で作り替えたり、一から作り直したり出来るでしょ。
ライブラリの癖や流儀に合わせなくても良い。
162:デフォルトの名無しさん
09/10/23 01:11:52
>>160
Fruitもちょっと近い
URLﾘﾝｸ(haskell.cs.yale.edu)
イベント繋がりにarrowが入っているので必要十分な感じがいい
でもレイアウトほぼ無視
イベント繋がりとレイアウト繋がりとの関係も無視
描画とコンポーネントの関係も無視
まだまだ遠い
163:デフォルトの名無しさん
09/10/23 06:20:20
>151
おもにC#つかってるんだが、諸事情でFormとかでWPFみたいに使えるフレームワーク作った。
それでごりごり作ってる途中で同じようなことちょとおもた。
論理からでなくてボトムからの必要性からだけど。
今落とし込もうとしてるのは並列性含むモデルと状態、その遷移。それらの投影と操作にたいするUIの疎結合。
それら出来るとだいぶ生産性あがりそうな予感。
164:60
09/10/23 12:13:35
Win32++文書翻訳を試したという話(>>66)のカキコ主だけど、
Win32++が....と比べて易しい/難しいという話題ならともかく、
それ以上はスレ違いかなと思った。板一覧を見直したところ、
「【C++】マイナーGUIツールキット」というスレがあるみたいだから、
翻訳話については、自分はそのスレへ移動するよ。
あと、著作権についてだけど、議論してくれた住人さん達に感謝する。
自分は自信が無いので、傍観していた。
とりあえず、>>71がマトメてくれた内容を反映させようと考えている。
165:デフォルトの名無しさん
09/10/23 17:57:46
【C++】マイナーGUIツールキット
ｽﾚﾘﾝｸ(tech板)
166:デフォルトの名無しさん
09/10/24 16:23:47
GUIって画面レイアウトと処理を完全に切り離すのは本当に正しい設計なのかな。
MVCで描こうとすると、いつもVがMのプロパティを多量に参照するから、Mの隠蔽が甘くなって嫌な感じになる。
167:デフォルトの名無しさん
09/10/24 17:32:19
VがMを参照するのをやめて、CがVとMの仲介をするようにできないのか？
MVCの3つとも綺麗に書く方法は無いような気がするから
Cが汚い仕事を一手に引き受ければいいと思う。
168:デフォルトの名無しさん
09/10/24 17:55:36
そうするとMのVでの表示のために必要なインタフェースをCで再定義することになる。
自分的には微妙。
C++のfriendみたいにMを更新するものについてはCからしか見えないような感じにしてVからは参照のみと操作の起点、Cはその操作に基づく具体的なMの更新とするのが自分的には一番しっくり。
169:デフォルトの名無しさん
09/10/24 20:27:37
>>157
論文にざっと目を通してみた。
期待する性質１でいう「GUIコンポーネント」というのは、
ボタンやテキストボックスなどが持つ機能や役割の事で、
「描画」というのはそれらの外見の事だよね。
それらのエッセンスに目を向けて抽象化しているからこそ「モデル」なのだから、
どのモデルも性質１は満たしているはず（でなければモデルではない）。
性質２はほぼ満たしていると思う。
Fudgets は入力されたデータやイベントをストリーム型のデータで扱っていて、
入力から出力へ向かう流れの中でそのデータを発生させたり加工したりしている。
[1] GUI からの入力イベント、[2] そのイベントから状態遷移＆データ出力、
[3] 出力データのGUIでの表示、という各パーツがひとつの関数に対応していて、
流れの中でリレーのバトンようにストリームデータを受け渡している。
[1]～[3] の各パーツが流れの中でどの役割を担うのか（加工なのか表示なのかなど）
がはっきりしているから、性質２は満たしている。
それらパーツの独特の繋ぎ方が Fudgets のウリだと思う。
ただ、論文執筆時（1998）にはまだストリームに時間の概念を表すデータはない。
性質３と４がよく分からんな。
（抽象化された世界に、ではなく、抽象化された世界から、じゃない？）
Fudgets で定義されているパーツを使えば、今トレンドとなっているGUIパーツは
理論的にはほぼ表現できると思うから、そういう意味では必要十分だと思うが。
ちょっとどころか半分は期待する性質を満たしていると思うが、
期待するものには未だ遠いと感じる理由は性質３と４に関係する？
それとも性質１や２もまだ十分満たしていないと考える？
170:144
09/10/24 20:38:46
>>169
おぉ、論文まで読んでくれた人がいる
ありがとう
で、返事書くからちょっとまってね
171:144
09/10/24 21:27:25
>>169
まず性質1について
Fudgetsもそうだけど、基本的にGUIコンポーネントという概念を使ってそれより下位は抽象化している
実は私の書いてた「描画」は、GUIコンポーネントより一段下位のベクトル描画の世界の事
GUIコンポーネントとベクトル描画の世界を繋ぐ架け橋が欲しい
もしくはGUIコンポーネントという概念そのものを考え直してほしい（なぜなら意外と脆弱な抽象化だから）
そういう事も期待しているので、性質1も十分ではないと思っている
ただ、そこまで要求するのも可哀想なので、とりあえずGUIコンポーネントという抽象化を前提にしても可かなとは思っている
性質2について
確かにFudgetsはコンポーネントのコンビネーターというアイディアを持っていて、
それを持ってイベントやレイアウトを取り扱っている。実際いい筋だと思う
でも、モデル化という意味では遠い
なぜなら、単に「こう記述するとfunctionalで便利ですよー」としか言ってなくて、
「モデル化された世界で特定の性質を語るにはこの方法しかない、もしくは他の方法はこの方法に帰着できる」という必要十分性がないから
それがないと試行錯誤して便利なGUIライブラリを作るのとなんら変わらない
モデルに期待するのは、シンプルな世界でもいいから明確な結論が得られるところ
性質3について
Fudgetsのコンポーネントの巧妙な合成はすばらしいし、性質3でいう「操作」にまさに該当すると思う
そういう意味では近い。
でも性質2の内容が弱いから、「確かに便利。でもそれで本当に問題ない？」という問いに答えられない
Fruitがやや進化したと思うのは、イベントの接続にarrowを使ったので、接続の仕方の能力はarrowによって規定されて、
そしてarrowの能力は順序・分岐・繰り返しが可能で構造化定理を満たしていることが明らかで、
だからイベントの接続については「何でも書ける」ことが保証されている点
こういう性質がないとだめ
性質4は理論があまりに抽象的過ぎて現実世界に結び付かない事を危惧したもの。Fudgetsについては始めから便利なのであまり意味はない
私の勝手な期待について議論してくれてありがとう
172:デフォルトの名無しさん
09/10/24 21:39:37
>>171
なるほど、そこまで言ってくれると「必要十分」の意味がよく分かる。
Fudgets は「この方法に帰着できる」という本質を追究するためのものじゃなくて、
imperative とは違い Functional ならこう書くのが筋が良いというのか主な主張だら、
確かに研究の目的が違うね（結果的に一部では近づいているが）。
> 私の勝手な期待について議論してくれてありがとう
いや、こちらこそかなり興味深く、勉強になった。
たぶん GUI プログラムをより分かりやすくする、より容易にすることに繋がると思う。
173:144
09/10/24 22:35:31
>たぶん GUI プログラムをより分かりやすくする、より容易にすることに繋がると思う。
そう連想してくれる人がいるんだ
私の期待が頓珍漢じゃない事は証明されたので、絶対誰か似たような研究をしている人がいるはずだ
けど、ググっても見つからない
教えてエロい人
174:デフォルトの名無しさん
09/10/24 22:51:13
理論が完成すると、それまでの試行錯誤が無かったことにされる。
それで、「新しい」理論が、試行錯誤という「古い」ものを打破する、
と考える人がいるけど
試行錯誤という過程と、理論という結果を対立させるのは変じゃないか。
コードで試行錯誤しないなら、舌先三寸で試行錯誤するしかなくなるんだよ。
175:144
09/10/24 23:38:38
試行錯誤という過程を否定したように聞こえたのなら、ごめんなさい、気を付けます
でも、もうそろそろ結果（理論）が欲しい。強く
理由もあります
一つはマルチタッチのような複雑な入力インターフェイスが一般化してきたら、
このままではGUIの開発が破綻する危惧を強く持っているから
少し遅れてWebの世界でも同じ事が起こるでしょう
もう一つは現在でもGUIの開発が非効率的過ぎるために全世界的に無駄なコストが垂れ流れていると認識しているから
最後の一つは私が会社でGUIを作る仕事をやっていて苦痛だから
176:デフォルトの名無しさん
09/10/24 23:55:23
GUIにかぎらず状態の取り扱いから並列性なども含めて銀の弾丸になるような理論・結果は出来てないでしょ。
のでお舞が自分に都合のいいものを作れ。
177:144
09/10/25 00:33:59
精進します
>GUIにかぎらず
でも、ここだけ。
例えば並列性で言えば、アクターモデル、Software Transactional Memory、Concurrent MLのようなある程度「モデル」に近いものがあります
その下位にはπ計算のような基礎もあります
状態の取扱いというと一般的になりすぎて難しいですが、
オートマトンという強力なモデルがあります
その上に正規表現やPEGが構築されています
これらのモデルは銀の弾丸ではありませんが、不可欠で、ソフトウェアの飛躍に大いに貢献しています
こういうものがGUIの分野にも欲しいのです
諦めた方がいいですか？
178:デフォルトの名無しさん
09/10/25 06:40:53
>>177
開発現場からの悲痛な叫びに聞こえるが、
美しい理論と泥臭い現実とのギャップに苦しんでいるのは、
君だけじゃないよ！！
横レス失礼
179:デフォルトの名無しさん
09/10/25 09:43:20
開発現場からの悲痛な叫びを汲み取って、
とりあえず答えをいち早く提示してくれるのは、
いつも大抵MSですね。
180:デフォルトの名無しさん
09/10/25 09:56:04
>>179
え！？
kwsk
181:デフォルトの名無しさん
09/10/25 10:07:21
その答えが更なる叫びを生み出すわけですが…
182:デフォルトの名無しさん
09/10/25 10:27:38
X-window時代はMotifでシコシコやっていたけど、今じゃあ簡単にできるようになったよね。
むしろ、今の方がどういう経緯というか仕組みで動作しているのか分からなくなった感じだな。
クラスライブラリ便利すぎ（ ・ω・）ｙ─┛～～
183:デフォルトの名無しさん
09/10/25 10:35:54
XLibはうんこすぎるのでその詳細なんて知るだけ無駄だから気にする必要ないと思うよ
184:デフォルトの名無しさん
09/10/25 10:54:52
>>180
MSは抽象的な理論からというよりは、
現場の問題を解決する方向で技術を開発してるように
私には見える。
たとえば、IEの拡張とか、WPFやLINQとか。
それが叩き台となるんだけど。
185:デフォルトの名無しさん
09/10/25 11:27:52
>>180
>>181再び
一般に「叩き台」という言葉は良い意味で使われるけど、MSの場合は、それが当てはまらないｗ
初級GUIプログラマにとっては、かえって阿鼻叫喚をもたらす災厄だったりする
186:デフォルトの名無しさん
09/10/25 11:58:39
そうだねえ
.netやらWPFやらsilverlightやら最近のMS技術に付き合ってきた印象では、どれもおおむね
バージョン1→技術コンセプト扱い。使い物にならない。将来的にサポートを切られるので危険
バージョン2→格段にバージョンアップする。そこそこ使い物になる。1とは互換性がない
バージョン3→意欲的でユニークな新機能も搭載し始めるようになる。使い物になる
という道筋を歩いてるのが面白いなあと。
「MS＝バージョン3の法則」は意図的だな絶対
187:デフォルトの名無しさん
09/10/25 13:54:25
C++なんか捨ててVBにしなよ VBなら超簡単
188:デフォルトの名無しさん
09/10/25 14:58:44
ＶＢならC++ Builderに来いよ(´･ω･`)
189:デフォルトの名無しさん
09/10/25 15:32:23
>>188
URLﾘﾝｸ(www.componentsource.co.jp)
\ 98,700 (税込) 1 開発ライセンス
買えませんｗ
190:デフォルトの名無しさん
09/10/25 15:36:06
無料配布してるぞ
191:デフォルトの名無しさん
09/10/25 15:42:23
トライアル版しかなかった
192:デフォルトの名無しさん
09/10/25 16:56:20
TurboExplorerシリーズは公開停止だぜ
193:デフォルトの名無しさん
09/10/25 17:24:38
>>177
筋はいいと思うけど、モデル構築自体が大変な作業になるんだけどっていうような無茶な要求が出てくるのがGUI。
「こうやった方が(モデル的に)スマートです」と言っちゃうのは技術屋の都合でしかないしね。
194:144
09/10/25 21:17:34
>>193
もしかして、「GUIのモデル」が出来たとしても、
それを逸脱する要求に対応しなくてはならなくなって、結局使えず、
使おうとすると、スマートだけども使えないモデルを客に押しつける事になる、
と考えています？
だからモデルなんて考えるのは諦めろという訳ですね
うーん、考えられなくもないですが、その「無茶な要求」の例が欲しいですね
そもそも「GUIのモデル」が出来ていないのでその弱点を議論できないのですが、
もし始めからムチャそうな話が分かっていれば、そこをカバーできるように抽象化していけます
ぜひご協力を
195:デフォルトの名無しさん
09/10/25 22:09:21
javaのawtを解析してみればどうかな、自分に必要な関数だけそろえて後は移植すると・・・
ちなみに自分はLSI-C86に移植してみた
URLﾘﾝｸ(www.forest.impress.co.jp)
196:144
09/10/25 22:27:43
>>193
あっ、もしかして私が期待しているGUIモデルを機能ミニマムなものだと勘違いておられる？
私が期待しているGUIモデルは対象機能を絞ってミニマムを考えようという方向ではなく、
シンプルだけれども強力な抽象化をしようという方向です
「そんなもの無理www」と言われればそれまでですが
197:デフォルトの名無しさん
09/10/25 22:50:13
Aの入力結果でBの候補が決定されるようなUIを作る時に
「冷静に考えたらAとBはここで同時に設定する必要性ないよね？なんで一画面なの？
Aの入力分析してBの候補を出すけど、そのあとAの入力変えたらBに矛盾が出るよ？」
って言っても
「例外ケースで矛盾が出るのはそれとして、利用者はこの画面で同時に入れたいんだよ！」
と押し切られるケースは多い。
じつはまさにそんな設計のせいで、新規機能の開発が遅れてる製品があるんだけど、
その責任は開発持ちっていうのはなんだかなぁ～って思ったりもする。
198:デフォルトの名無しさん
09/10/25 22:51:19
>>196
>勘違いておられる？
勘違いておられました。
199:デフォルトの名無しさん
09/10/25 22:53:52
>>195
それは >>144 が求めているものとはちょっと違うと思う。
GUIモデルをクラスと考えれば、javaのawtというのはそのインスタンスだ。
>>144 が考えるのは、この比喩で言えばクラスの方。
awtを設計するにおいて基にした考え方、実現方法を知って、
それを >>144 が期待する条件という観点で分析する。
その為にはawtのソースコードやクラス階層図などより、
どちらかと言うと論文の方が欲しいところ。
論文なら、awt以前の何の問題をどう解決したのかが簡潔に書かれているはず。
そういう分析を「解析」と言っているのなら、単に私の勘違いだが。
200:デフォルトの名無しさん
09/10/25 23:01:28
>>199
なるほど、自分には無理っす。
201:デフォルトの名無しさん
09/10/25 23:04:49
FRP関係の研究を追い掛けていくぐらいしか無いかな
一人の人間の脳でやるにはややこしすぎる問題だ
202:デフォルトの名無しさん
09/10/25 23:13:18
おっと、sage忘れてた。
>>201
仕事ではやりたくないが、
趣味でやる分には知的活動として面白いな。
203:144
09/10/25 23:36:59
>>197
具体例ありがとうございます
GUIは思っている以上に複雑になり得るものだと認識しておきます
>>201
やはり有望なのはFRP関連になりますか
私もそれ以外見付けられていないのが現状です
204:144
09/10/26 00:11:29
GUIのモデル化へ向けて、（今のところ）鍵だと思われる考え方まとめ
1 time varying value
2 composable event
3 software transactional memory(or join calculus)
4 linear programming
205:デフォルトの名無しさん
09/10/26 23:22:30
↓に制約プログラミングがどうたら、それを使ってGUIがどうたらとかあるけどどうよ？
自分はまだそこまで読み切ってない。
URLﾘﾝｸ(www.amazon.co.jp)コンピュータプログラミングの概念・技法・モデル-Architect-Archiveクラシックモダン・コンピューティング6-Architects’Archive-CLASSIC/dp/4798113468/ref=sr_1_1?ie=UTF8&s=books&qid=1256566886&sr=8-1
206:デフォルトの名無しさん
09/10/27 00:17:39
Amazon へのリンクは URLﾘﾝｸ(amazon.jp) でオケ
GUI は理論が実装に勝てない分野の一つじゃないかな。
207:デフォルトの名無しさん
09/10/27 17:28:10
スレ違いだが、なんでamazonはようつべみたいに、
コピペ用の短いURL載ってないんだろうな？
208:デフォルトの名無しさん
09/10/27 18:10:13
（俺の嫌いな）SEOってやつだよ。
長いリンク・・・本の題名が含まれたリンクが張られるだろ？
たくさんリンクされているページはよいページ、
そしてそのページの内容は、リンクの文字と関連がある。
リンクの文字は検索される。
この板ならこれぐらい言えば、理解してもらえるだろう。
209:デフォルトの名無しさん
09/10/28 12:40:31
>>205
あぁ、なんだっけ、ガウディ本って言うんだっけ
GUIの話が載ってるなら読んでみようかな
制約系の手法も部分的に期待しているし
210:デフォルトの名無しさん
09/10/29 20:48:32
causal commutative arrows
URLﾘﾝｸ(lambda-the-ultimate.org)
Yampaが例に出てるし一読してもいいかな
211:デフォルトの名無しさん
09/12/08 16:56:52
会社で無理やりPGにさせられたけどGUIはCUIにくらべて格段にむずすぎますぅ
212:デフォルトの名無しさん
09/12/08 17:15:26
Tcl/Tkでもやりなさい
213:デフォルトの名無しさん
09/12/08 19:59:45
javafxのbind構文はどうだろ
劇的にGUIプログラミング楽になったりする？
214:デフォルトの名無しさん
09/12/13 00:22:56
ＧＵＩは、サンプル読んでイベントハンドラのとこ重点にソース読んでれば理解が早いと思うよ。
サンプルに処理を追加して、既存のイベントから呼ばせてみると仕組みが分かるかと。
javaのswingとかシンプルだから触ってみては？
SWTも良いかも。
215:デフォルトの名無しさん
09/12/14 15:39:44
Javaってどこにマヌアルあるの？
216:デフォルトの名無しさん
09/12/14 15:41:28
「java api」でググるとよろし
217:デフォルトの名無しさん
09/12/14 16:00:18
>>216
おお、こんな所があったのか。
Net豆のヘルプから辿れるようにしとけばいいのに。
218:デフォルトの名無しさん
09/12/16 17:33:55
JavaScriptとかVBAとかTcl/Tkとか、そこからやってみれば？>>1
219:デフォルトの名無しさん
09/12/16 18:38:50
逆にむずいだろ
VB6でやるのが一番
220:デフォルトの名無しさん
09/12/16 18:53:40
VBはVC++なみに難しかった記憶がある。最近はそうでもないの？
VBなら最初からC#のほうがよくないかな？
221:デフォルトの名無しさん
09/12/18 00:00:24
VBはな、イベント処理の仕組みが理解し辛いのよ。
誰でも作れるように、難しい箇所はラップして理解させないようにしてる。
VBIやっても、多言語でGUIは使いこなせないのがほとんど。
VBでも凄い人は居るけど、そんな人は多言語も使える人だったりする。
VB、C++、ゲームで組み込みとか色々やったけど、javaがシンプルで無難だと思うよ。
222:デフォルトの名無しさん
09/12/18 00:08:34
Tcl/Tk は簡単で良いね
223:デフォルトの名無しさん
09/12/21 12:50:37
簡単だよね
224:デフォルトの名無しさん
09/12/25 14:05:58
ウインドウズアプリを作るならウインドウズの仕組みを知ってて当然
225:デフォルトの名無しさん
09/12/30 00:28:55
そしてその仕組みが広大なんだよな
やりたいことへの到達点が遠すぎる
一見意味不明なtypedefが更にやる気を削いでいく
226:デフォルトの名無しさん
09/12/30 15:07:55
このOSじゃないと！ってのがなけりゃJavaとかでいいんだよ
227:デフォルトの名無しさん
09/12/31 08:49:00
それでwxやGTK+、Qtを使うようになるんだよな
しかもLLバインディングで
そして「見た目がなんかWindowsと違ってキモい」と言われるんだよ
228:デフォルトの名無しさん
10/01/01 11:08:49
.NETはフォームエディタも含めて十分に簡単だと思うけどそれじゃダメな理由はなんなのかな。
WPFじゃなくてWinFormsのほうね。WPFはリッチなデザインのGUIが欲しい人以外には不要だと思う。
229:デフォルトの名無しさん
10/01/01 21:02:47
HSPやっときゃいいじゃん。やりつづければWindowsのしくみなんていやでもわかる
230:デフォルトの名無しさん
10/01/02 21:27:22
>>228
>.NETはフォームエディタも含めて十分に簡単だと思うけどそれじゃダメな理由はなんなのかな。
.NETでGUIを作っていて難しいと感じたことは無いですか？
イベントがいつ発生するのかとか、その順番とか、自分が欲しいイベントはどれなのかとか。
もしくはテキストコントロールやグリッドコントロールに思い通りの動きをさせるにはどうすればいいかとか。
231:デフォルトの名無しさん
10/01/03 23:48:13
.NET FW で難しいとか思うんなら
もういっそ諦めればいいと思うんだ。
232:デフォルトの名無しさん
10/01/04 12:16:41
>>231
諦めちゃうの？もう十分に簡単？
難しいとか思うから改善したくなるわけで、諦めたらそこでおしまいですよ。
（他の優先事項があるってのはそうかもしれないけど、ここはGUIのスレなので）
.NETにもRxとかいうFRPっぽいやつが実装されてくるらしいけど、
URLﾘﾝｸ(msdn.microsoft.com)
現状で十分に簡単なら必要ないね？
233:デフォルトの名無しさん
10/02/20 16:17:18
＞＞１
がんばれ～
234:デフォルトの名無しさん
10/02/21 01:28:46
とりあえずC++の文法やったんだがGUIがどうすればいいかわからん
Qt wxWidgets MFC win32api どれやればいいんだ？
MFCとかwin32apiは過去のものなの？
235:デフォルトの名無しさん
10/02/21 02:28:18
過去のもの
もちろん今でも使えるけど
わざわざそんな面倒な方法をとらない
Cに対するアセンブラみたいなもの
236:デフォルトの名無しさん
10/02/21 02:57:52
友達ならMFC薦めるなってばっちゃが言ってた
237:デフォルトの名無しさん
10/02/21 03:15:10
友達なら当たり前
238:デフォルトの名無しさん
10/02/21 13:45:59
もっさりでも手軽さを重視すればC#
面倒くさくてもぬるぬるが好きならMFC
自他共に認める変態ならAPIのみ
239:デフォルトの名無しさん
10/02/21 23:55:27
>>234
Qtやりましょうよ。
240:デフォルトの名無しさん
10/02/22 01:31:36
もうHTMLでいいじゃん。
241:デフォルトの名無しさん
10/02/22 02:22:56
オレにとっては一時期の飯の種であったMFCが
コケにされるのは寂しいが、さすがにお勧めはできないな
Win32APIはWindowsを知るという意味では無駄にならないと思うがね
242:デフォルトの名無しさん
10/02/22 02:28:28
MFCは無駄すぎ
243:デフォルトの名無しさん
10/03/02 23:12:51
xlibに挫折
Qtは拡張構文が追加されてそうで嫌
で、gtkmmを学び出す
244:デフォルトの名無しさん
10/03/03 03:28:33
gtk/gtk++/gtkmm は糞
Qt は良いよ
245:デフォルトの名無しさん
10/03/03 09:29:35
拡張構文ってgccとvc使っているんだけど
246:デフォルトの名無しさん
10/03/03 13:31:33
Q_OBJECTやslotsはなぁ
247:デフォルトの名無しさん
10/03/03 16:33:11
マクロだろ
248:デフォルトの名無しさん
10/03/03 18:13:46
マクロに拒絶反応を示すのは抽象的思考が出来ないほど知能が低いということ
249:デフォルトの名無しさん
10/03/03 18:47:24
Qtっていまだにmoc必須なん？
250:デフォルトの名無しさん
10/03/03 18:48:29
moc 無かったら Qt じゃないだろ
251:デフォルトの名無しさん
10/03/03 18:59:02
気持ち悪いね
252:デフォルトの名無しさん
10/03/03 19:00:12
気持ち悪いね
253:デフォルトの名無しさん
10/03/04 04:06:04
Qtって、foreachとかも追加されてなかった？
fltkはC++の地味な機能しか使わんとかなんとか
254:デフォルトの名無しさん
10/03/04 04:45:04
URLﾘﾝｸ(qt.nokia.com)
FLTKは知らん。
255:デフォルトの名無しさん
10/03/04 08:21:48
emit なんてのもある
256:デフォルトの名無しさん
10/03/11 22:01:11
>>244
gtk/gtk+/gtkmm のどこがだめ?
257:デフォルトの名無しさん
10/03/23 17:51:26
CUIの達人ですがGUIはさっぱりです
258:デフォルトの名無しさん
10/03/23 18:05:28
Qtって前少し使ったときあまり良い本とか文書が無かったけど今はどうなんだろう
designer でGUIデザインするのはGUIですれば良いしできるのに，
demoを含めて打ち込む方法を説明していたりするのが以前は意外と多かった
Molentkin とか参考になった覚えある
259:デフォルトの名無しさん
10/03/24 00:10:20
説明を書く側からすると、GUIで画像貼付けて手順書くより
打ち込んだソースを解説する方が楽なんだよね・・
260:デフォルトの名無しさん
10/03/24 00:59:17
GUIが難しいのは、どういうタイミングと順番で実行されるか分からない
コード片（イベントハンドラ）がたくさんあって、
それらがどう呼び出されようとも正しく動作するように条件分岐やらフラグ
やらを管理しなきゃいけないからじゃないかな
261:デフォルトの名無しさん
10/03/24 10:34:35
せっかくのGUIなのに画面遷移=プログラムフローになっちゃってるソフトは使いにくい
262:デフォルトの名無しさん
10/03/25 22:57:32
コンソールこそ我らが故郷
そのまま突き進め
263:デフォルトの名無しさん
10/03/26 02:20:48
コソンール
264:デフォルトの名無しさん
10/03/26 07:09:34
GUIでまじで躓いたわ
あの情報量の多さは異常だろ
何が必要で必要でないかの判断がつかなかったからマジでつらかった
265:デフォルトの名無しさん
10/03/26 11:46:22
Win32APIでGUIを作るなら、センスがない限りある程度パターンとして覚えるぐらいでないとつらいと思う。
266:デフォルトの名無しさん
10/03/26 12:10:49
GUIの目的の大部分は「普通のUI」を作ることだよな
普通じゃなくて良いならGUIなくても構わないことが多い
何が普通で何が普通でないかを判断するところが、GUIの難しさだ
267:デフォルトの名無しさん
10/03/26 14:25:31
結局C++Builderから離れられん(´･ω･`)
268:デフォルトの名無しさん
10/03/26 14:33:53
ＶＳ２００８のMFCアプリだど、ウィザードで超ｶｯｺｲｲGUIを作ってくれるぞ
むずかしすぎって・・・
269:デフォルトの名無しさん
10/03/27 01:36:51
VS2008でリボンとかついたから
試してみたけど超うんこだったわ
270:デフォルトの名無しさん
10/03/27 01:47:57
VSとQt両方使ってる人が比較するとどういうところが良し悪しなんだろう？
単純に全体として良し悪しではないと思うんで宗教戦争にする気は無いんだけど
VSの方がドキュメントは多い，Qtはマルチプラットフォームというのは俺でもわかるが
271:デフォルトの名無しさん
10/03/27 08:54:38
Qt は Multiligualization でも力を発揮する
272:デフォルトの名無しさん
10/03/27 18:45:13
内はいまだにMFCから離れられん
273:デフォルトの名無しさん
10/03/27 22:12:45
(´・ω・)ｶﾜｲｿｽ
274:デフォルトの名無しさん
10/03/28 12:31:28
色々あり杉て難しいです(´；ω；｀)
275:デフォルトの名無しさん
10/03/30 16:28:52
いっそのこと、HTMLとJavaScriptだけでUI作ったら？
Dijitとか、jQuery UIなんか使えばそこそこ高度なものが作れる。
276:デフォルトの名無しさん
10/03/30 20:37:06
つ URLﾘﾝｸ(ExtJS.com)<)
277:デフォルトの名無しさん
10/04/01 21:22:32
すいません、初歩的なことなんですが、GUIってグイですか？ジーユーアイですか？
わたしわグイって言って単ですけど、先輩がジーユーアイって言い出して
顔から火がでるほどはずかしかったので教えてください÷
278:デフォルトの名無しさん
10/04/01 21:25:44
さて、グイ派とジーユーアイ派の一悶着が済むまで見守るとするか
279:デフォルトの名無しさん
10/04/01 21:33:12
通じればOK
通じなければ通じるように言いましょう。
280:デフォルトの名無しさん
10/04/01 21:36:36
Dr. GUY
281:デフォルトの名無しさん
10/04/01 22:08:16
まあ、普通はジーユーアイだろうけど、グイと呼ぶ人もいるからいいんじゃね。
URLﾘﾝｸ(ja.wikipedia.org)
と思ったが、
URLﾘﾝｸ(eow.alc.co.jp)
こっちではグイと発音する、ってなってるな。
もしかすると英語圏ではグイのほうが普通なのかも。
似たような言葉で、
URLﾘﾝｸ(ja.wikipedia.org)
ってのがあるが、これをジーエヌユーと言うとちょっと恥かしいかもしれない。
282:デフォルトの名無しさん
10/04/01 22:08:56
おれはグーイだな
283:デフォルトの名無しさん
10/04/01 22:11:32
じゃあオレはギュイ
284:デフォルトの名無しさん
10/04/01 22:34:44
じゃあギニュー(特戦隊)で
285:デフォルトの名無しさん
10/04/02 05:11:04
G.U.I!
286:デフォルトの名無しさん
10/04/02 21:44:36
ギュイ
287:デフォルトの名無しさん
10/04/03 00:56:57
牛慰
288:デフォルトの名無しさん
10/04/04 13:20:11
GUI ←グイ
CUI ←クイ
YUI ←どれもおんなじ歌ばっか しかもヘタクソ
289:デフォルトの名無しさん
10/04/04 17:20:51
>>288
どUI
290:デフォルトの名無しさん
10/04/10 23:41:25
基礎が終ってやっとグイに進んだけどむずかしすぎる。。。
291:デフォルトの名無しさん
10/04/11 01:17:44
>>34
はげどう
292:デフォルトの名無しさん
10/04/11 17:37:06
GUIの難しさって、CUIと違ってデフォルトがないってだけじゃないの?
293:デフォルトの名無しさん
10/04/11 18:36:09
なにがむずかしいの？
まさかとは思うけど、C+WIN32APIのみ作ってるの？
妥協して、MFCなりATLなりWTLでも使え
これなら、むずかしすぎるってことはない
さらに妥協できるなら、.NETでも使え
これなら、サルでもつかえるよ
294:デフォルトの名無しさん
10/04/11 18:49:07
デフォルトでどの程度妥協すべきか、判断できないな
295:デフォルトの名無しさん
10/04/12 00:30:04
GUI作るのが簡単とか思っているのはまだ初心者
296:デフォルトの名無しさん
10/04/12 01:40:19
ＧＵＩは簡単だろ？
ソフトウェア設計の大半はデータ構造とアルゴリズムだぞ
GUIなんてドカタに任せておけばオｋ
297:デフォルトの名無しさん
10/04/12 01:50:02
データ構造とアルゴリズムは多少大規模でも気にならないが、GUI は目が回る。
298:デフォルトの名無しさん
10/04/12 03:06:59
確かにGUIだとテストやデバッグが大変
299:デフォルトの名無しさん
10/04/12 03:19:28
難しい簡単という尺度よりも
面倒くさいとか楽だとかしんどいという尺度の方がしっくりくる感じ
300:デフォルトの名無しさん
10/04/12 03:21:40
だれかが言ってたけど
CUIに比べて処理の流れが
組み合わせになるから
無限に拡散してしまう
301:デフォルトの名無しさん
10/04/12 11:50:34
普段Javaで業務用アプリ書いてるから、GUIが面倒とか思うことはないけど、
最初CでWindowsアプリ書いた時は（3.1～95）確かにメンデーと思った。
あ、MFCは初対面のときからソリの合わないものを感じてC++Builderに避難しました。
302:デフォルトの名無しさん
10/04/12 13:45:38
OWLってまだ使ってる人いるの？
303:デフォルトの名無しさん
10/04/12 20:18:21
GUIの難しさは、他の人間相手に使いやすさを考えることだろ。
304:デフォルトの名無しさん
10/04/12 22:53:16
GUIって言ってもどこまで完成度求めるかじゃないの？
取りあえず機能的には Ok というのならマウスの位置掴んだり
ボタンとかボックスたくさんつくったりとかそんな大変じゃない
拘りだしたり動かしだすと自由度も大きいしキリが無い
事前にしっかりレイアウト決まってるならそんなに大変じゃないと思う
305:デフォルトの名無しさん
10/04/13 01:16:00
問題を二つに分けて考える必要があるね
一つはインターフェイスデザインという意味での難しさ
Webの画面もGUIの一種と考えれば、インターフェイスデザインがアプリケーションにおいて
どれほど重要でありながらも難しいものかが分かるでしょう
二つ目は開発者の視点から見た作成の難しさ
GUIコンポーネントをベタペタ張ればお終いと思っているのは役たたずのマネージャー
非同期通信(例えばDB問い合わせとかCGIアクセスとか)との連携、
可変なウィンドウサイズと動的なレイアウトとの戦い、
複雑なイベントチェーンの管理等々
306:(u＿・y) ◆e6.oHu1j.o
10/04/13 08:40:37
GUIはCUIの10倍位は難しいだろ
今後も、さらに難しさレベルは増えていく可能性がある
いまはまだ、2Dの無機質なソフトが多いけど
そのうちフェードとか、自作メニューバーとか、３Ｄ化してるアプリが当たり前になってきたら
敷居あがりまくりなんだけど
307:デフォルトの名無しさん
10/04/13 18:24:12
マルチタッチとか考えなきゃいけなくなると、もうやだ
308:デフォルトの名無しさん
10/04/13 22:31:39
マルチタッチは低レベルなポイントなどにアクセスしなくても、
たいていはもっと高レベルなジェスチャーにアクセスする程度で十分だから、
それほど難儀しないと思う。
309:デフォルトの名無しさん
10/04/22 08:58:33
スラッシュドットより。まあ大学の情報工学科でこうだからなあ…
URLﾘﾝｸ(slashdot.jp)
>某大学の情報工学科でプログラミングを教えていますが、今でも演習はCLIベースです。
>演習室には最新のMacが並んでいますが、演習自体はターミナルとEmacsで行います。:-)
>GUIよりもまずは基本的な原理をわかってほしいということもありますが、私を含めた
>多くの教員がGUIを使った開発経験に乏しいのも確かですね。最近の学生にとっては
>CLIベースのソフトウェアは半完成品のような印象を与えるみたいで、いまひとつ演習に
>身が入らない人がそれなりにいるのは確かなので、今後のカリキュラムは何とかせねば
>とは思っています。
310:デフォルトの名無しさん
10/04/22 09:28:55
そんな馬鹿に迎合した授業しても仕方ないのになぁ
311:デフォルトの名無しさん
10/04/22 11:32:20
すごい残念な大学だな
高い授業料払っているのに
312:デフォルトの名無しさん
10/04/22 11:58:23
「半完成品のような印象」とか "Worse is Better" とか
パラドクスが日常茶飯事だという事をまず最初に教えるべきだ
313:デフォルトの名無しさん
10/04/22 14:26:31
GUIといっても色々あるけどな
「GUIを使った」開発（大抵IDEの事）→初めからIDEばかりで教えるべき
かには疑問が残る
「GUI付きのソフト」を開発→プログラミングならばまずCLIで開発できて
それからGUI付きの開発に行くべき
（GUIきれいでも中身書けないじゃ話にならん）
情報工学科でGUI含めた開発まで行き着けないというのならそれは寂しいが
314:デフォルトの名無しさん
10/04/22 20:36:49
>演習室には最新のMacが並んでいますが、演習自体はターミナルとEmacsで行います。:-)
うちと似てるな。うちはターミナルだけじゃなくてEclipseを使った演習もやるけど。
プログラミングの講義はそれなりに揃ってるけど、GUIプログラミングをシステマティックに
教えている科目はないんじゃないかな。そもそもGUIプログラミング自体一過性の技術なので
（プログラミング関連で一過性じゃないものって何？って言われそうだけど、相対的にみた
場合）、どうしても教える内容としての優先度は低くなるんだよね。
315:デフォルトの名無しさん
10/04/22 22:08:07
おまえが生きているうちは無くならないから
316:デフォルトの名無しさん
10/04/22 23:37:59
やらない理由が教える側が出来ないからというのが情けない
317:デフォルトの名無しさん
10/04/23 00:27:00
しかもコメントの書き方ではIDEとGUI付きのアプリの違いを意識しているか危ないし…
IDEでCLIのアプリを作ることも，EmacsみたいなCUIでGUIアプリ作ることも十分可能なんだが
318:デフォルトの名無しさん
10/04/23 00:57:40
この藪蛇な流れを見るとやはりGUIには手を出さないのが賢いと思える
319:デフォルトの名無しさん
10/04/23 03:14:38
４年間もあるのにGUIやらんのか
320:デフォルトの名無しさん
10/04/23 07:48:18
俺が出た学科は半分以上が数学や理論の講義だった。λ計算とか。
プログラミングも実践より理論という感じの講義が多かったな。
まあでもアルゴリズムやその解析をみっちり勉強できたのはよかったかも。
321:デフォルトの名無しさん
10/04/24 01:33:06
GUIの作り方なんて上っ面を大学で教える必要はないわな
情報の学生さんはλ計算や計算可能性の話や圏論なんかを勉強してきてください
322:デフォルトの名無しさん
10/04/24 13:52:38
まぁ大学出たらそんなもの勉強する時間まず無いからね
323:デフォルトの名無しさん
10/04/24 16:36:23
基礎できてる人はGUIのAPI程度、本一冊斜め読みして
ちょっとしたGUIアプリぐらい数日でつくるよ
研究室でもできるやつはできるでしょ
そういう人が居ない場所だと
レベルの低さを認識できないかもね
基礎ができてればGUIの習得ごときで長時間費やすものじゃないのに
324:デフォルトの名無しさん
10/04/24 18:03:01
ここってそういうスレだったっけか
325:デフォルトの名無しさん
10/04/25 01:09:09
確かに。
GUIの何が難しいのか、俺にはさっぱりわからん。
326:デフォルトの名無しさん
10/04/25 04:26:53
ちょっとしたやつじゃなくて
本格的なのやれよ
327:デフォルトの名無しさん
10/04/25 08:12:22
カーナビとか
328:デフォルトの名無しさん
10/04/25 18:50:37
>>326
どういったものが本格的かどうかわからんが、面倒なだけだろ
すくなくとも難しくはない
329:デフォルトの名無しさん
10/04/26 01:22:36
>>328
横レスですが、難しいです
通常、イベントハンドラが長時間の処理に陥ってしまうと画面諸共応答がなくなるために、
そのような処理は完了イベントを挙げるような非同期な仕組みに変更しておく必要があります
（例えば、初期化やDB検索やネットワーク通信など)
ところが、このような複数のイベントループを持つ一連の処理を正しく行うためには
別の全てのイベントとの整合性を担保しなければならなり、これが大変複雑になります
パズルと一緒で、依存関係が多くなると"面倒"が"難しい"に変わります
330:デフォルトの名無しさん
10/04/26 05:43:28
ちょっとしたGUIくらいすぐ作れるとか言う奴は
ちょっとしたGUIしか作れない
331:デフォルトの名無しさん
10/04/26 09:35:50
>328
株式チャートとか、ビジオみたいの作ってみなはれ。
332:デフォルトの名無しさん
10/04/26 09:38:34
GUIなんて私の仕事じゃないと言い続けている私は、
実はGUIはちょっとしたものしか作れない。
つーか、UI何それ、そんな律速要因要らないよ。ってのが私の領分。
333:デフォルトの名無しさん
10/04/26 12:33:09
よくそんなしょうもないこと書きに来たな
334:デフォルトの名無しさん
10/04/26 12:43:31
>>329
パズルはパズルでも論理パズルだから、
やはり難しというよりは面倒の方が近いと思うが。
そりゃ、根気がなかったり、仕事のスケジュール配分にミスがあれば、
時間がないんでぱっと解決するアイデアに頼ろうとして難しいだろうけど。
335:デフォルトの名無しさん
10/04/26 20:42:09
システムのインフラを作ってるような人から見れば、くだらなくてただ面倒な
だけのものに見えるかもしれないけど、難しいし、凝ればいくらでも凝ること
ができる、奥の深い分野だと思うよ。
336:デフォルトの名無しさん
10/04/26 20:57:29
>>335
> 凝ればいくらでも凝ることができる、奥の深い分野
それには激しく同感。
ユーザーインターフェースのデザイン関係の本を読んでみるとよく分かる。
ただ、「難しいし」これが分からん。
それは単に、それを実現するための知識が不足しているからではないのか。
もっと身にあった対象から順にじっくりと少しずつ知識と経験を積んでいけば、
特に難しいしと感じる所はほとんど無いと思うが。
気が競って本当は踏むべきステップを飛び越そうとしたとか、
飛び越さざるを得なかったとか、そんなんじゃないのか？
337:デフォルトの名無しさん
10/04/26 22:31:40
>もっと身にあった対象から順にじっくりと少しずつ知識と経験を積んでいけば、
>特に難しいしと感じる所はほとんど無いと思うが。
逆にどういう時に難しいのか聞きたい
338:デフォルトの名無しさん
10/04/26 23:03:36
限られた時間内に知識を得るのが難しいんだな
もし時間が無限にあれば、難しいものなんて殆ど無くなるだろう
339:デフォルトの名無しさん
10/04/26 23:16:38
SEXの欲求を抑えるのは時間があればあるほど難しくなる
340:デフォルトの名無しさん
10/04/26 23:58:23
簡単に諦められたら、それは「難しかった」とは言えない
GUIには、諦めたくないと思わせる何かがある
341:デフォルトの名無しさん
10/04/27 01:32:30
>限られた時間内に知識を得るのが難しいんだな
>もし時間が無限にあれば、難しいものなんて殆ど無くなるだろう
つまり、無限に時間があればGUIは難しくないだろう、と
じゃぁ、有限の時間を生きている私達にとってGUIは難しい？それとも難しくない？
342:デフォルトの名無しさん
10/04/27 07:25:35
>>337
おそらくこういう知識がまだ足りないと分かっても、
その知識をステップバイステップで学べる環境にない時に
（参考図書などが見つからなかったり）、
資料探しを諦めて自分で解決しようとすると難しく感じる。
それ以外は、特に難しくない。
時間だって、無限の時間とかなんでそんな大げさに考えるのか不思議だ。
納期が迫っているとか以外なら、じっくり学ぶ時間なんて
ちゃんとやりくりして捻出できるだろ。
343:デフォルトの名無しさん
10/04/27 08:17:46
>資料探しを諦めて自分で解決しようとすると難しく感じる。
自分で解決しようとして、例えばどんな問題が難しく感じました？
GUIを如何に簡潔にプログラミングするかは難しい問題ではないですか？
ちなみに世界中どこを探しても答えが載っている参考図書はないと思います
（あるならぜひ教えてほしい）
344:デフォルトの名無しさん
10/04/27 12:53:02
>>343
>自分で解決しようとして、例えばどんな問題が難しく感じました？
Yampa を活用した GUI ライブラリの仕組みを早く理解したくて、
ライブラリ内を色々巡った時はなかなか理解できず、相当難解だった。
ACM に FRP の論文が大量にある事が分かって一からじっくり勉強してみると、
次第に理解できてきた。
> GUIを如何に簡潔にプログラミングするかは難しい問題ではないですか？
難しいと感じるのは、きっと「簡潔とは何か」をしっかり定義しないまま、
闇雲に簡潔にしようとしているからだろう。
そのソースコードが以前に比べてどのような状態になったら簡潔になったと満足するのか、
ちゃんと自分の頭に中に思い描けるのなら、
そのために不足している知識を得て実験を繰り返すだけだろ。
>ちなみに世界中どこを探しても答えが載っている参考図書はないと思います
何を当たり前のことを言っているのだ？
「答え」そのものはさすがに無いだろ、問題なんて千差万別なんだから。
でも問題を抽象化したり、別の問題との関連を考えれば、
ヒントとなるものは世の中にかなり大量に存在していると思うぞ。
345:デフォルトの名無しさん
10/04/27 20:03:38
なんかズレてるな
いろいろと…
346:デフォルトの名無しさん
10/04/27 20:57:42
>>344
とても頭脳明晰な人みたいなのでもういいです
GUIは難しくない、面倒なだけ
それでいいです、すみませんでした
347:デフォルトの名無しさん
10/04/28 21:04:36
その態度が面倒臭がり
348:デフォルトの名無しさん
10/04/28 23:03:38
なんだよ、FRPとか論文もしっかり読んでる人だからつまんない話は終わりにしようと思ったのに、なんだよ
だいだいあなたはGUIが難しいかどうかについて具体的に何も触れなかった
同じ時間で同じようにステップバイステップで問題に挑戦したとして、
他の問題に比べてGUIが特徴的にどのように難しいのか（もしくは難しくないのか）を議論したかったのに、
一足飛びにやろうとしてるだの目標を決めてないだのなんだのメタな話ばかり
できればGUIを記述する際に問題となる具体的な話をしてくれ
349:デフォルトの名無しさん
10/04/28 23:11:06
>>329が具体的に書いてるじゃん
要するに非同期プログラミングの難しさであると
350:348
10/04/28 23:26:49
>>329は私が指摘した難しさ
329をもってしても"面倒なだけ"という主張だったので
非同期な複雑さを整理する方法や対案が議論されるかもしれないと期待して
質問してたりしてたのっ
FRPとかでもいいので、もしGUIに思う所があれば参考になるので言ってください
351:デフォルトの名無しさん
10/04/28 23:48:20
そりゃすまんかったｗ
俺は今初めてこのスレちょっと見ただけだから
352:348
10/04/29 00:34:05
>>351
人違いスマソ
353:デフォルトの名無しさん
10/04/29 00:56:26
>>329
まず、「イベントループ」という言葉は具体的に何を指しているのか、
何故「それが複数必要なのか」を説明できるか？
そして、「面倒が難しいに変わる」という場合の「難しい」というのは、
理解するのが困難であるという意味の難しいなのか、
それとも現実的な時間で解決に導くことが不可能に近くなるという意味の難しいなのか。
>>344 で先に挙げられた質問に答えているように、
私は理解するのが困難であるという意味の難しいと解釈して発言している。
354:348
10/04/29 01:45:48
>まず、「イベントループ」という言葉は具体的に何を指しているのか、
>何故「それが複数必要なのか」を説明できるか？
うん？その説明によって何が知りたいのか分からない
とりあえず応えるけど、
イベントループはユーザーの操作やウィンドウからのイベント処理を一手に扱っているループのこと
複数必要って言うのは、
一連の処理が長時間に渡る場合に一回のループでその処理をしてしまうと
画面が固まったり他のイベント処理が進まなくなるので、
一連の処理を複数回のループに分ける必要があるという意味
>そして、「面倒が難しいに変わる」という場合の「難しい」というのは、
>理解するのが困難であるという意味の難しいなのか、
>それとも現実的な時間で解決に導くことが不可能に近くなるという意味の難しいなのか。
少なくとも後者ではないわな
「面倒が難しいに変わる」を補足すると、
規模が小さければ頭を使わなくてただ単に手を動かせば済むことだったのに、
複雑さが増えてくると、
あーだこーだと考え込まなきゃいけない状況になって間違いが増えるので、これを"難しい"と言っている
そういう意味ではFRPライブラリを理解するのが難しいという時の難しいとは違う
"複雑(ふくざつ)しい"とでも言えばよかったかな(そんな日本語ないけど)
あと、もう難しい云々の言葉の定義と議論はやめにしないか
つまらないと思う
それよりも何が簡潔かとか、どうすれば簡潔かを議論したい
355:デフォルトの名無しさん
10/04/29 01:55:44
>>354
イベントループ複数って、いわゆるDoEventsの類？
GUIイベントループが意味もなく複数あるなら、それはあまりいい設計じゃないな……
スレッド、コルーチン、継続のようなものを利用したほうがいい
時間がかかる仕事は裏スレッドでやればいいだけだろう
勿論、非同期I/Oなどの目的で、非GUIのイベントループが別途必要になることは
普通に有り得るけどな
356:348
10/04/29 02:32:35
いい感じに具体的になってきた
>>355
誤解させているようだけど、
基本的にGUIイベントループは一"本"
GUIイベントループが複数"本"走っているんじゃなくて、
例えばDB検索して表示するという一連の処理に複数"回"のループが必要という意味ね
その一連の処理の間に別のイベントが処理されるから、IDLE状態とは異なるハンドリングが
必要になる
DB処理中もフォーカスカーソルは動かしたいけどリターンキーは効かないようにとか言う仕様とか泣きたくなる
357:デフォルトの名無しさん
10/04/29 02:37:38
>>356
意味は分かったが、言っちゃ悪いが説明が悪かったな
要は気持ちとしては一連である処理の流れが、実装の上で断続的になる
といいたいんだろ？
それ自体は非同期プログラミングでのごく基本的な問題だな
さっきも言ったがコルーチンとか使えると一連の流れのコードとして書けるので
楽になる場合がある
あんたの言うように、複数の状態管理／制御が絡む場合は面倒くさいことになるな
358:348
10/04/29 08:02:33
"複数持って"がいかんかったね
ありがという
>>357
コルーチンいいね
359:デフォルトの名無しさん
10/04/29 09:56:08
女と合法的にセックスする難しさに比べたら
>>353 の言うGUIの分かりにくさは難しさの内に入らない
360:デフォルトの名無しさん
10/04/29 12:35:26
>>356
DB検索して表示するという「一連の処理」に複数回のループが必要になるのは何故？
もしかして、「DB検索する」という処理と「表示」という処理を
一括りに処理しようとしていないか？
処理の単位を２つ分けて、スレッドなりでそれぞれ処理すれば良くないか？
この場合、DB検索する処理は普通は一回のループで可能だろ。
（繰り返し回ることがないからループという言い方がそもそも当てはまらないが）
DB内を検索し、目的のデータを集め、それらを表示更新すべきデータリストに登録する。
この処理の単位なら、SQL を投げて結果を処理するだけだから、
繰り返す必要が無く一回のループで可能なはずだ。
最後に、表示更新すべきデータリストの内容が変更されたことをイベントで通知する。
最後でなくても、複数データを適当な塊に分けて入力するたびに通知しても良い。
また、表示更新すべきデータリストでなくても、要は表示処理を担当している処理単位が、
何が更新されたのかが分かればいい。
表示処理の方は、表示更新すべきデータリストの内容が変更されたイベントを拾い、
今画面に見せている部分に変更があれば、画面を更新すればいい。
DB検索の開始と終了のそれぞれに、また別のイベントを投げるようにすれば、
ユーザー入力処理を担っている処理単位の方は、
「DB処理中もフォーカスカーソルは動かしたいけどリターンキーは効かないように」
という仕様も容易に実装できる。
（念のために言っておくが、スレッドなどを使って分けておく必要がある）
361:デフォルトの名無しさん
10/04/29 14:03:31
一回のループって結局何回回るんだ
362:デフォルトの名無しさん
10/04/29 14:06:41
do{一回のループ}while(0);
363:デフォルトの名無しさん
10/04/29 14:22:18
>>361
言葉尻捕まえるくらいしか、突っ込めないのかｗ
364:デフォルトの名無しさん
10/04/29 20:55:07
>>360
>この場合、DB検索する処理は普通は一回のループで可能だろ。
>（繰り返し回ることがないからループという言い方がそもそも当てはまらないが）
"ループ"ってイベントループの事なんだけど...伝わらなかったようです
>DB検索の開始と終了のそれぞれに、また別のイベントを投げるようにすれば、
ちなみに、"一連の処理"をGUIと共に実装する方法としては、この方針で
おおよそ問題ないと思います
ただ、DB検索をバックグラウンド処理に移して完了通知をイベントにした瞬間、
"DB検索中"という状態が増えた事に注意してね
全てのイベントハンドラについて、その状態を加味して書くようにしないと、
DB検索完了時として想定していなかった変な状態に遷移してしまっている場合が出てきてしまう
ちなみに、DB検索が失敗したら検索中フラグを適切に落とさないと、
今度はDB検索中状態が延々と続くことになってしまう
DBだけならまだしも、ネットワーク通信、ドラッグアンドドロップなど、
複数イベントループが必要な処理は沢山ある
全てのイベントハンドラについて、
それらの組合せを全て考慮して記述することが容易とはとても思えない
少なくともすぐ間違えるはず
365:デフォルトの名無しさん
10/04/29 23:16:21
>>364
> それらの組合せを全て考慮して記述することが容易とはとても思えない
それらは本当に「組み合う」のか？
全てのイベントハンドラの中で依存関係のある、
つまり組み合わせを考慮しなければならない組はどれくらいある？
どのようなイベントハンドラとどのようなイベントハンドラの
どのような組合せをどのように考慮しなければならないのか、
具体例を出して説明できるか？
そして、それらの組み合わされる処理の何を記述するのが大変なのだ？
それはプログラマが全てを事細かく記述するのではなく、
大まかな関係を引数で与えたら自動的にイベントを裁いてくれるような
仕組み（関数やクラスやモジュールなど）を作る方が比較的楽なのではないか？
それができれば、すぐ間違える事は少なくなると思うが。
366:デフォルトの名無しさん
10/04/30 07:20:38
>それらは本当に「組み合う」のか？
本質的には全て組み合う
なんらかの前提条件が満たされている場合、かつその前提条件がバグによって壊されない場合のみ、
組合せを省略して書いてもよい
367:デフォルトの名無しさん
10/04/30 11:38:56
こんだけ長文が続くんだから
間違いなくGUIがむずかしすぎるのだ
368:デフォルトの名無しさん
10/04/30 12:33:05
>>366
例えばどんな前提条件が満たされてる時に組合せを省略して書けるの？
369:デフォルトの名無しさん
10/04/30 20:37:37
>大まかな関係を引数で与えたら自動的にイベントを裁いてくれるような
>仕組み（関数やクラスやモジュールなど）を作る方が比較的楽なのではないか？
>それができれば、すぐ間違える事は少なくなると思うが。
イベントの条件判定部分だけ切り出してプログラミングできるのが、
まさに"FRPのevent"でしょ？
そういう意味では、FRP使えでFAなんじゃなかろうか
370:デフォルトの名無しさん
10/04/30 20:41:48
>>368
例えば、
ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更しておけば、
そのGUIコントロールが通信中にイベントを受け取ることはあり得ないので、
disableにしたコントロールのイベントハンドラについては、
ネットワーク通信中かどうかを判定するロジックは省略できる
ただしdisableにし忘れるとアウト
371:デフォルトの名無しさん
10/04/30 21:02:08
>>370
>ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更しておけば、
そうしたら通信先が死んでたりするとタイムアウトするまでGUIは無反応にならない？
372:デフォルトの名無しさん
10/04/30 21:09:20
>>370
ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更するのと、
ネットワーク通信に入る直前にGUIコントロールを全部
「ネットワーク通信中にされると都合が悪いユーザー操作を無視する」状態に変更するのと、
なにか根本的に違うのか？
まさか、無視する処理が難しいとか言わんだろうな
373:デフォルトの名無しさん
10/04/30 22:28:33
（GUIコントロールをdisableにするなどして）ユーザー操作を無視して良いのなら
組み合わせを省略できる（=難しくない）ってことじゃないの？
374:370
10/04/30 23:40:15
>>373
そうです
あくまで組み合せを省略できる一例を示しただけで、
別にdisableにする事を推奨している訳ではないです
逆にdisableにするとGUIが無反応になったり色々嬉しくないので、
むしろそういう安易な対策は好ましくなく、
イベントハンドラできちんと状態を考慮する必要があると皆認識していると分かりました
375:デフォルトの名無しさん
10/05/01 01:54:21
つか、GUIなんてどうでもよくね？
376:デフォルトの名無しさん
10/05/01 04:25:53
でも最近のgnomeでもgconf-editorとかないと
設定死ぬほど面倒だよ
というか不可能だよ
377:デフォルトの名無しさん
10/05/01 09:01:55
コメントを書かないと保守が不可能だよっていう議論に似てる
本体のコードが変更されると、周辺のコメントとかGUIはすぐ古くなって問題を起こす
378:デフォルトの名無しさん
10/05/01 13:54:27
>>374
だかさら、
> 「ネットワーク通信中にされると都合が悪いユーザー操作を無視する」状態に変更するのと、
> なにか根本的に違うのか
という質問に答えてないだろ？
もし同じであれば、
あなたの言う「GUIが無反応になったり色々嬉しくない」状態は回避しつつ、
あなたの言う「安易な対策」で解決できそうではないかと言いたい。
根本的に違うのであれば、どのように違うのかを示して欲しい。
わたしは本質的に同じと思っているから。
（どちらもトリガによって状態を変更し、状態に合わせて処理を分岐する）
> イベントハンドラできちんと状態を考慮する必要がある
なにやら、きちんと状態を考慮するのが難しいと言っているように聞こえる。
設計時にちゃんと必要な状態やトリガを洗いざらいリストアップしているか？
リストアップしたものの中で関連性が高いもの、依存しているもの、
一連の処理として分割できないもの、できるもの、ちゃんと仕分けしているか？
それぞれの状態遷移図や状態遷移表などを「大きな紙」に描いたりしているか？
379:デフォルトの名無しさん
10/05/01 14:47:57
学者が研究するような難しさと、現場で感じる難しさが、根本的に食い違ってる
380:デフォルトの名無しさん
10/05/01 16:00:33
>設計時にちゃんと必要な状態やトリガを洗いざらいリストアップしているか？
>リストアップしたものの中で関連性が高いもの、依存しているもの、
>一連の処理として分割できないもの、できるもの、ちゃんと仕分けしているか？
>それぞれの状態遷移図や状態遷移表などを「大きな紙」に描いたりしているか？
全てのボタンやメニューについて全部？
そんな事したことない
たぶんすぐ古くなってそれだけの労力が報われないと思う
そのコストを受け入れるより、
プログラムの作り方でなんとかならないのかなー？
381:デフォルトの名無しさん
10/05/01 17:26:10
ボタンが10個ぐらいあって
それぞれ状態によって有効/無効を切り替えるとする。
ボタンは将来追加される可能性もある。
君ならどうする？
状態A - ボタン1 3 5 7 9 を有効にし、それ以外を無効にする。
状態B - ボタン0 2 4 6 8 を有効にし、それ以外を無効にする。
状態C - ボタン0 1 2 3 4 を有効にし、それ以外を無効にする。
：
：
382:デフォルトの名無しさん
10/05/01 17:37:20
ボタンには当然、それが押された時のアクションを定義するだろう。
アクションには、他のボタンの有効/無効や状態も切り替える事も含まれる。
君ならどうする？
383:デフォルトの名無しさん
10/05/01 17:57:37
>>380
>全てのボタンやメニューについて全部？
なんでボタンやメニューから考え始めようとするんだよ。
まず実現させたい機能が先だろ。
それを洗い出して、その機能を実現させるための処理の組み合わせを考え、
それらの組み合わせる処理が他の処理と排他的な関係にあるのか、
同時に起こってもいいものなのか、などの関係を洗い出して、
最後の最後にその機能を発動させるスイッチとして、
ボタンやメニューなどを考えるんだよ。
機能よりもスイッチの方が多くなるのだから、
先に昨日動詞の関係をまとめておけば、イベントのごちゃごちゃも、
先にボタンとかを考え始めてた時よりは設計が楽になる。