GUIがむずかしすぎる

1 ：09/10/18 〜 最終レス ：12/01/02

コマンドラインプログラムならなんとかできるんだけど
GUIは私の知能じゃむり

2 ：

糞スレ立てんな

3 ：

gomen

4 ：

でもでもCUI->GUIって急に難易度あがりすぎじゃありません？

5 ：

　

6 ：

敢えてGUIプログラミングには手を出さずに突っ走るのもありだ。

7 ：

SDL とか簡単だよ。

8 ：

Xlibだけ使って一から書いてた頃はそーとー苦労したが、
今はいくらでも簡単に作れるジャマイカ

9 ：

Win32APIを自分でラッピングするのがお勧め。
自前でサンクとかやれば色々と応用が利く。

10 ：

wxとかgtkは、xlibは拷問、Qtでそこそこ

11 ：

guiって、C#やVBだと簡単だね。
MFCも簡単だけど、フレームワークって言うのに抵抗があるかも・。

12 ：

MFCと比べればQtが極楽に思えるぐらいMFCは

13 ：

VCL MFC WTL WindowsForm WPFは？

14 ：

CUIは作るのが簡単だからね。
出力は標準出力。
入力は標準入力。
オプションは引数。
これだけだもの。
GUIだと、それらができるのは当たり前。
使いやすいように、オプションの配置を考えて
グループ分けし、状況に合わせてツリー表示やテーブル表示にし、
ユーザーの希望にあわせてウインドウをリサイズし、
説明も表示し、環境に合わせて言語も変える。とか
”使いやすい”を目指して作らないといけない。

15 ：

WPFはSヨやってる友人達がベタぼめしてた
ATL/WTLはC++ヲタの人達にはそこそこ評判いいみたいだけど、
結構癖が強いんで、それならQtでいいやーみたいな
今さらやるならC#でWPF使っとくのが一番手っ取り早いんじゃない？
Windows使えねーって人達はQt触るなりcppguiに期待するなり、
PerlやPythonのtkバインディング使うなりするのがよろし

16 ：

つ
ここいっとけ
Lily C++ GUI Library
http://kengolab.net/lily/lily_tips/

17 ：

見た目をそれほど気にしなくていいので、本来の処理に集中出来るという
意味では楽だけど、network とか curses を使うならそれなりに面倒だよ。

18 ：

大学のプログラミングの授業でもGUIは全然やらなかったなあ…
全部Unixのコマンドラインでやってたよ。

19 ：

時間の限られているような「講義」という形でGUIなんて茨の道すぎる

20 ：

GUIが難しい理由：
VB亡き後の後継の筈のActive BASICが.NET路線を
追いかけてしまい停滞しているからw

21 ：

Active BASICいらねーよ
この開発者は無駄に人生使ってる

22 ：

>>19
部品張ってイベント処理書くだけなのに茨の道もクソもあるか。

23 ：

わかんないんです（＞＜）

24 ：

GUIライブラリが色々あり杉て困る件。
標準入出力とか、コマンドラインの引数みたいに標準ライブラリの枠組みの中に
会ったらよかったのに。

25 ：

Qtが一番マシかなって感じ……

26 ：

>>24
GUIだけならいいんだが、それ以外のも一緒についてくるのは確かに嫌だな。
STL使えばいいのになぜか独自のコレクションクラス使ってたり。

27 ：

難しくない
めんどくさいだけ

28 ：

難しいかどうかは、MVCを理解できるか否かにかかると思われ。
VB系のGUIツール前提という開発の呪縛から逃れることを勧める。

29 ：

最近のGUIツールはすべてVB系と大差ない気がするんだが。

30 ：

android の GUI は部品間のつながりを XML で記述するので、ロジックと分離できて便利。

31 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

32 ：

アイちゃん遅いよ……

33 ：

アイちゃんが遅いんじゃないぞ

34 ：

アイちゃんより比呂美のほうが好きだ

35 ：

>>1 そうそう。GUIアプリの開発演習になると途端にハードルが高くなるよね？

36 ：

Lily C++ GUI Library
http://kengolab.net/lily/lily_tips/

37 ：

最近 Qt の宣伝多いな…

38 ：

Lily ≠ Qt

39 ：

俺は Qt の宣伝が多いとしか言ってないが

40 ：

DirectX！
そうゆう事を言ってるわけじゃないですね、はい。

41 ：

DirextSEX!

42 ：

マルチプラットフォームだとQtぐらいしかない
WindowsならWPFでも使ってればいい
MacはCocoaにしてもCarbonにしても塵

43 ：

>>42
> MacはCocoaにしてもCarbonにしても塵
なんで塵なの？

44 ：

そういう年頃なんだろ

45 ：

GUIは仕様書がる。
遷移図が超カオス

46 ：

>>45
規模が大きくなりすぎないように分割して行くから、
仕様書は、たいてい、ユースケース記述＋クラス図＋シーケンス図でカバー出来てるな

47 ：

>>46
そういった(コーディングから離れて)設計に立ち返る意識が持てる
境地に達していれば、無問題だろな。
遷移マシンがMVCのM(モデル)であることに気が付くこと(>>45)が、最初の一歩。

48 ：

Viewの遷移とModelの遷移は別物。混同するとぐちゃぐちゃになる。

49 ：

Viewに遷移などない

50 ：

ViewはModelの状態を参照するけど、View自身は状態を持たないから、
遷移そのものが存在しないわな

51 ：

要するにブラウザーの状態とサーバーの状態だろ
「ブラウザー自身は状態を持たない」は正しくないこともない

52 ：

ちょっと違うかな。
一般にViewとModelは同一マシン(メモリ空間上)に存在するから、VはMの状態を参照できる。
一方、もし>>51がWebの事を言っているなら、Client(Webブラウザ)とServer(Webサーバ)は、
ネットワーク上で分散しているから、ClientはServerの状態を(直接的には)参照できない、
という違いがある。したがって、ClientもまたMVCパラダイムで設計され、ClientのMと
Server(Mのみ)との間で、規約(HTTP)に従った通信が必要になる。

53 ：

>>41
そういやオカモトのスタンダードタイプは\500〜\3000まであるが、
いったい何が違うんだろう。装着感？

54 ：

うすうす

55 ：

GUIの難しさの本質？
GUIから新しい言語が出来てしまって、それらの言語がデファクト
スタンダートを作っているから
そしてそれらの言語の特徴（矛盾しているわけではないが、
流儀としては排他的）が相互汚染防止の為に反目しあってること

56 ：

Intermediate Rails: Understanding Models, Views and Controllers | BetterExplained
http://betterexplained.com/articles/intermediate-rails-understanding-models-views-and-controllers/
これの図を見るとMVCは全部鯖側にあるようにみえるんだけど
一言にMVCと言っても色々あるんだなー

57 ：

Win32++
http://sourceforge.net/projects/win32-framework/
これよさげ
情報、日本語訳求む。
ヘッダオンリーでATLやWTLより簡単げ。

58 ：

よさげとおもって紹介してみたけどレス無い・。・。

59 ：

MVC ってよくわからん。
M がデータ処理で V がアウトプットで C がインプットで大体合ってるの?

60 ：

>>57
思いつきで作ってみました的なモノでは無く、きちんと公開して多くの人に使ってもらえる事を
意識したプロジェクトに見える。ドキュメントやサンプルも整備されてるし(英語だけど)。
UNIX(C)&Mac(realBasic)プログラマなんだが、C++とWinには以前から挑戦したいと思ってた。
だから、なかなかシンプルで良さげに見えた。とは言ってもWin32 APIは初めて見たわけだが....。
で、一部の翻訳に着手したよ。ヘルブの中にある概要("Win32++ Overview")の章。
明日くらいには公開できると思う。興味あるかな？

61 ：

thx!楽しみにしてます!

62 ：

>>60
日本で唯一解説しているらしいところはここだけみたいです。量少ない。
http://naruishi.hp.infoseek.co.jp/program/w32pp.txt

63 ：

>>58
まともな日本語も掛けない奴のレスなんか、レス返す価値などないと思ったんでね。
# つーか、なんだよ、「簡単げ」ってよ。

64 ：

無理ゲー

65 ：

>>60
>興味あるかな？
私が翻訳権を持ってるわけじゃないのでどうでもいいっちゃいいんですが
許可を得ているのかどうかにはちょっとだけ興味があります。

66 ：

Win32++の翻訳文書を公開した。
・Win32++概要
　http://www.h6.dion.ne.jp/~machan/win32pp/overview.txt
Windowsプログラミングは未経験なので、不適切だったり誤っている箇所があると思う。
特に、リバーコントロール(Rebar Control)/メッセージの反射(Message Reflection)/
CWndオブジェクト/WndProc関数に関連した部分は、無理矢理に訳した感がある。
Win32 APIに詳しい住人さん達からのツッコミに期待。

67 ：

二次的著作物とは、著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、
その他翻案することにより創作した著作物をいう（2条1項11号）。
二次的著作物に対する著作権法の保護は、原著作物の著作者の権利に影響を及ぼさない（11条）。
著作物 - Wikipedia

68 ：

>>56
MVCは、元々は普通の(ネットワークとは無関係な)GUIアプリ開発の中から生まれた。
それがWebアプリにも取り入れられるようになった経緯がある。Railsは、その代表格だね。
最近では、Webクライアント上で動くJavaScriptアプリにも取り入れられつつある。
SproutCoreと呼ばれるAJAXフレームワークが、その一例。
・SproutCore Documentation / Basics-Introducing SproutCore MVC
　http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC
だから、SproutCoreを利用するWebシステムでは、以下の３つのMVCが、同時に存在することになる。
・Webサーバ上で動くアプリケーションのMVC -- 例: Rails
・Webブラウザ自身のMVC -- このスレでの話題の中心となる、GUI向けのMVC
・Webブラウザ上で動くアプリケーションのMVC -- 例: SproutCore
>>59
思いっきり単純化すると、そのイメージで合っているよ。
・Mは、ユーザインタフェースを持たない、データ管理だけのオブジェクト。
・Vは、Mのデータを表示(出力)するオブジェクト。ユーザから見える部分になる。
・Cは、ユーザの操作(入力, 例:ボタンを押す)を受け付け、MやVへメッセージを送って、
　全体を制御するオブジェクト。

69 ：

>>67
翻訳したものに関してはね。
翻訳できるかどうかが問題で
第二十七条　著作者は、その著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する。
だからこそ、翻訳権や翻案権は明記されない限り著作者から自動的に
移譲されたりはしないことになっている。
第六十一条　著作権は、その全部又は一部を譲渡することができる。
2　著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。

70 ：

Win32++はMITライセンス =修正BSDライセンス
前述のGPLやLGPLに比べて、格段に制約の緩いライセンスとなっています。
制約となる条件がたった２点しかありません。
１つ目は「再配布時には著作権表示を残す」という事。
もうひとつは「無保証である」という事。
この２点を守りさえすれば、どのように利用しても構いません。
ライセンスをGPLに変えて再配布するもよし、
改変して独占販売するもよし、
ソフトウェアだけ頒布してソースを非公開にしてもよし。
http://smkn.xsrv.jp/blog/2009/03/summary_for_gpl_mit_cc_etc/

71 ：

要するに、元著作者の名前を入れておけばいいってことだけ。　無保証って言うのは持続しなくてもいい。
利用条件は、
無保証
著作権表示の保持
MIT License (X11 License)
http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%BC%E3%83%97%E3%83%B3%E3%82%BD%E3%83%BC%E3%82%B9#MIT_License_.28X11_License.29

72 ：

>>1に禿同
本質的に難しい（複雑）なのかもしれないけど、
どちらかというとライブラリが足引っ張ってると思う

73 ：

>>68
どうもありがと！
これで MVC は理解して卒業した事にします。

74 ：

駄目
POSAのvol1の130ページあたり読むまで許さない

75 ：

実際に自分でプログラムしなきゃ
理解したことにはならんだろｗ

76 ：

実際のコーディングはどうせライブラリのスタイルに合わせないといけないので、
モデルの話は常識程度に抑えておこうと思ってます。

77 ：

Model View ControllerはArchitecural Patternsだから
詳細設計あたりまでもってくれれば十分
でもそこまで考えたらコードまで落し込んで動かす所まで持っていきたくなるから同じことか

78 ：

もうさ、MVCが基本とかいう幻想は早く捨て去ろうよ
あんなもの、単にオブザーバーパターン使ってみましたってだけじゃん
GUIのGの字も語ってない
それよりも、FRP（Functional Reactive Programming）とか参考にした方がまだまし

79 ：

それなりに効率よく、綺麗に扱うには
Future valueとかMonadとかApplicative Functorとか
普通の言語で使うには難しいfeaturesが必須ですけどね

80 ：

そういう様式論って殆ど実りが無いんだよな…
マーケティングのバズワードとかハイプとかと同じ匂いがする

81 ：

様式論のバズワードの筆頭がデザパタ

82 ：

関数型言語風のMVCとしてはtangible valueというものもあるけどあれも続報を聞かない

83 ：

>>79
「それなりに」の程度によるけど、「実用的」というレベルならHaskellじゃなくても全然いける
連続的な時間を扱いたかったら確かに遅延評価がないと厳しいけど、
離散的な時間でよく、なんちゃってFRPならどの言語でも（もとい、ML系なら）無問題でしょ
実際OCamlでもそんなライブラリがあるし

84 ：

>>72
ライブラリが足引っ張ってる部分というのは、具体的にはどの部分なのかな？
自分が>>1の言う難しさが何であるかを考えるに、コマンドラインの対話型プログラミングは、
メニュー出力/コマンド入力/コマンド実行/実行結果出力をループさせる処理になる。
コードは、フローチャート(流れ図)という言葉があるように、連続した処理の塊(かたまり)として
読む事ができる。これに対して、GUIプログラミングでは、入力イベントごとの対応する手続きが、
断片としてコード全体に散らばってしまう。この為、プログラムを読む側からすれば、
流れるような処理ではなく、実行部分がコードのあちこちを無秩序に飛び回っているように見える。
この可読性の悪さが、GUIプログラミングを難しいものに見せているのだと思う。

85 ：

GUIプログラミングの新時代は関数型言語が開くのか

86 ：

コマンドラインでも curses とか使ったアプリはイベント駆動だね。
>>1 が言ってるのは入力待ちでブロックする様な単純なプログラムか
フィルタ系なのかな。

87 ：

さすがに>>1がcursesを使っている人物だとは、ちょっと思えないがなぁw

88 ：

>>84
足引っ張ってるのは、色々あるけど、一つはレイアウト
あれはクソ
>流れるような処理ではなく、実行部分がコードのあちこちを無秩序に飛び回っているように見える。
>この可読性の悪さが、GUIプログラミングを難しいものに見せているのだと思う。
禿同ですな
イベントからの条件分岐と「目的の処理」を分離して欲しい

89 ：

>>85
いや、その前に関数型言語が一般のプログラマに受け入れられる事が先だ
いかに関数型言語を使うことで美しく簡潔なGUIアプリケーションが書けたとしても、
関数型言語が一般のプログラマに使ってもらえなければ、
(GUIプログラミング新時代への移行に関しては)何の意味も持たない
オブジェクト指向言語も、過去に同じような批判を受け、それに耐えて現在の地位を得ている

90 ：

つ JavaScript
みんな function(){ ... } ってラムちゃんを書きまくってるからオケ。

91 ：

ここで、Win32++を推奨していこう。あとwiki作って広めるか。
http://sourceforge.net/projects/win32-framework/

92 ：

>>91
それさ、何が嬉しいのかいまいち分からないんだが、説明してもらえる？

93 ：

>>90
でも、そのラムちゃんって不純だからなぁ....

94 ：

何か問題あるんだっけ?

95 ：

WPFってかなり素性のいいフレームワークだと思うんだけど
MSと.netというだけで評価されない風潮がある感じがして悔しい
cssのdiv厨ならぬGrid/StackPanel厨になっちゃうのがアレだけど

96 ：

そもそもWPFっていう単語が何なのかまったくわからん。
WindowsPrintFoundation?

97 ：

>>90
あれは関数型言語の一部のガワだけを拝借しているに過ぎない。
プログラミング スタイルが本質的に異なるから、
ラムちゃんを書きまくってるからオケとはなかなかいかない。

98 ：

つまり、純なラムちゃんじゃないと俺の嫁じゃない
そういうことだな？

99 ：

そもそもGUIは本質的に難しさを抱えてるものだから、
どの言語、フレームワークを使っても一定以上には簡単にならないと
マが覚悟を決めないと話にならんよね。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
洋書推薦図書/洋書必読書のためのスレッド 1
関数型言語でGUIのメモ帳・電卓は作れるのか？
三次元オセロを作ろう
DarkBASIC