1001コメント354KB

GUIがむずかしすぎる

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2009/10/18(日) 17:54:43

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

0002デフォルトの名無しさん

2009/10/18(日) 18:00:37

糞スレ立てんな

0003デフォルトの名無しさん

2009/10/18(日) 18:03:39

gomen

0004デフォルトの名無しさん

2009/10/18(日) 18:07:14

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

0005,,・´∀｀・,,）っ-○○○

2009/10/18(日) 18:09:16

0006デフォルトの名無しさん

2009/10/18(日) 18:14:40

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

0007デフォルトの名無しさん

2009/10/18(日) 18:18:30

SDL とか簡単だよ。

0008デフォルトの名無しさん

2009/10/18(日) 18:21:33

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

0009デフォルトの名無しさん

2009/10/18(日) 18:43:04

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

0010デフォルトの名無しさん

2009/10/18(日) 18:49:46

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

0011デフォルトの名無しさん

2009/10/18(日) 18:55:53

guiって、C#やVBだと簡単だね。

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

0012デフォルトの名無しさん

2009/10/18(日) 18:58:21

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

0013デフォルトの名無しさん

2009/10/18(日) 18:59:07

VCL MFC WTL WindowsForm WPFは？

0014デフォルトの名無しさん

2009/10/18(日) 19:01:21

CUIは作るのが簡単だからね。

出力は標準出力。
入力は標準入力。
オプションは引数。

これだけだもの。

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

0015デフォルトの名無しさん

2009/10/18(日) 19:03:12

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

0016デフォルトの名無しさん

2009/10/18(日) 19:04:50

つ

ここいっとけ

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

0017デフォルトの名無しさん

2009/10/18(日) 19:07:18

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

0018デフォルトの名無しさん

2009/10/18(日) 21:21:01

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

0019デフォルトの名無しさん

2009/10/18(日) 21:22:54

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

0020デフォルトの名無しさん

2009/10/18(日) 22:29:42

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

0021デフォルトの名無しさん

2009/10/18(日) 22:37:04

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

0022デフォルトの名無しさん

2009/10/19(月) 00:17:43

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

0023わかんないんです（＞＜） ◆WAkan9Ey1g

2009/10/19(月) 00:56:39

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

0024デフォルトの名無しさん

2009/10/19(月) 00:59:01

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

0025デフォルトの名無しさん

2009/10/19(月) 00:59:47

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

0026デフォルトの名無しさん

2009/10/19(月) 01:03:41

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

0027デフォルトの名無しさん

2009/10/19(月) 01:23:46

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

0028デフォルトの名無しさん

2009/10/19(月) 02:57:59

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

0029デフォルトの名無しさん

2009/10/19(月) 03:28:12

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

0030デフォルトの名無しさん

2009/10/19(月) 03:34:35

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

0031デフォルトの名無しさん

2009/10/19(月) 06:48:55

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

0032デフォルトの名無しさん

2009/10/19(月) 12:38:02

アイちゃん遅いよ……

0033デフォルトの名無しさん

2009/10/19(月) 12:40:13

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

0034デフォルトの名無しさん

2009/10/19(月) 18:04:54

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

0035デフォルトの名無しさん

2009/10/19(月) 21:29:10

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

0036デフォルトの名無しさん

2009/10/19(月) 21:30:32

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

0037デフォルトの名無しさん

2009/10/19(月) 21:32:32

最近 Qt の宣伝多いな…

0038デフォルトの名無しさん

2009/10/19(月) 21:34:37

Lily ≠ Qt

0039デフォルトの名無しさん

2009/10/19(月) 21:37:08

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

0040デフォルトの名無しさん

2009/10/19(月) 21:44:10

DirectX！

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

0041デフォルトの名無しさん

2009/10/19(月) 23:24:57

DirextSEX!

0042デフォルトの名無しさん

2009/10/19(月) 23:26:38

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

0043デフォルトの名無しさん

2009/10/19(月) 23:29:37

>>42
> MacはCocoaにしてもCarbonにしても塵

なんで塵なの？

0044デフォルトの名無しさん

2009/10/19(月) 23:41:05

そういう年頃なんだろ

0045デフォルトの名無しさん

2009/10/20(火) 00:38:41

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

0046デフォルトの名無しさん

2009/10/20(火) 01:24:21

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

0047デフォルトの名無しさん

2009/10/20(火) 09:00:57

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

0048デフォルトの名無しさん

2009/10/20(火) 10:18:20

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

0049デフォルトの名無しさん

2009/10/20(火) 10:20:39

Viewに遷移などない

0050デフォルトの名無しさん

2009/10/20(火) 10:29:13

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

0051デフォルトの名無しさん

2009/10/20(火) 11:05:17

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

0052デフォルトの名無しさん

2009/10/20(火) 11:45:46

ちょっと違うかな。

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

0053デフォルトの名無しさん

2009/10/20(火) 15:26:00

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

0054デフォルトの名無しさん

2009/10/20(火) 16:10:05

うすうす

0055デフォルトの名無しさん

2009/10/20(火) 16:10:52

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

0056デフォルトの名無しさん

2009/10/20(火) 17:35:40

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

0057デフォルトの名無しさん

2009/10/20(火) 17:40:46

Win32++
http://sourceforge.net/projects/win32-framework/

これよさげ
情報、日本語訳求む。
ヘッダオンリーでATLやWTLより簡単げ。

005857

2009/10/20(火) 23:26:53

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

0059デフォルトの名無しさん

2009/10/20(火) 23:58:56

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

0060デフォルトの名無しさん

2009/10/21(水) 00:08:12

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

で、一部の翻訳に着手したよ。ヘルブの中にある概要("Win32++ Overview")の章。
明日くらいには公開できると思う。興味あるかな？

0061デフォルトの名無しさん

2009/10/21(水) 00:28:18

thx!楽しみにしてます!

0062デフォルトの名無しさん

2009/10/21(水) 05:30:37

>>60

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

0063デフォルトの名無しさん

2009/10/21(水) 09:50:04

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

0064デフォルトの名無しさん

2009/10/21(水) 09:58:13

無理ゲー

0065デフォルトの名無しさん

2009/10/21(水) 11:19:25

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

006660

2009/10/21(水) 14:38:51

Win32++の翻訳文書を公開した。

・Win32++概要
　http://www.h6.dion.ne.jp/~machan/win32pp/overview.txt

Windowsプログラミングは未経験なので、不適切だったり誤っている箇所があると思う。
特に、リバーコントロール(Rebar Control)/メッセージの反射(Message Reflection)/
CWndオブジェクト/WndProc関数に関連した部分は、無理矢理に訳した感がある。
Win32 APIに詳しい住人さん達からのツッコミに期待。

0067デフォルトの名無しさん

2009/10/21(水) 15:01:25

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

0068デフォルトの名無しさん

2009/10/21(水) 16:15:34

>>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へメッセージを送って、
　全体を制御するオブジェクト。

0069デフォルトの名無しさん

2009/10/21(水) 16:21:57

>>67
翻訳したものに関してはね。
翻訳できるかどうかが問題で
第二十七条　著作者は、その著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案する権利を専有する。

だからこそ、翻訳権や翻案権は明記されない限り著作者から自動的に
移譲されたりはしないことになっている。
第六十一条　著作権は、その全部又は一部を譲渡することができる。
2　著作権を譲渡する契約において、第二十七条又は第二十八条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する。

0070デフォルトの名無しさん

2009/10/21(水) 17:38:05

Win32++はMITライセンス =修正BSDライセンス

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

http://smkn.xsrv.jp/blog/2009/03/summary_for_gpl_mit_cc_etc/

0071デフォルトの名無しさん

2009/10/21(水) 17:41:47

要するに、元著作者の名前を入れておけばいいってことだけ。　無保証って言うのは持続しなくてもいい。

利用条件は、
無保証
著作権表示の保持
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

0072デフォルトの名無しさん

2009/10/21(水) 19:54:28

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

0073デフォルトの名無しさん

2009/10/21(水) 20:12:23

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

0074デフォルトの名無しさん

2009/10/21(水) 20:24:15

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

0075デフォルトの名無しさん

2009/10/21(水) 20:25:03

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

0076デフォルトの名無しさん

2009/10/21(水) 20:39:27

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

0077デフォルトの名無しさん

2009/10/21(水) 20:39:33

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

0078デフォルトの名無しさん

2009/10/21(水) 21:04:59

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

0079デフォルトの名無しさん

2009/10/21(水) 21:15:00

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

0080デフォルトの名無しさん

2009/10/21(水) 21:20:27

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

0081デフォルトの名無しさん

2009/10/21(水) 21:22:40

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

0082デフォルトの名無しさん

2009/10/21(水) 21:23:05

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

0083デフォルトの名無しさん

2009/10/21(水) 21:25:01

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

0084デフォルトの名無しさん

2009/10/21(水) 22:42:36

>>72
ライブラリが足引っ張ってる部分というのは、具体的にはどの部分なのかな？

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

0085デフォルトの名無しさん

2009/10/21(水) 22:52:46

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

0086デフォルトの名無しさん

2009/10/21(水) 22:53:08

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

0087デフォルトの名無しさん

2009/10/21(水) 23:10:16

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

0088デフォルトの名無しさん

2009/10/21(水) 23:27:55

>>84
足引っ張ってるのは、色々あるけど、一つはレイアウト
あれはクソ

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

0089デフォルトの名無しさん

2009/10/21(水) 23:40:25

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

0090デフォルトの名無しさん

2009/10/21(水) 23:42:33

つ JavaScript

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

0091デフォルトの名無しさん

2009/10/21(水) 23:47:58

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

0092デフォルトの名無しさん

2009/10/22(木) 00:19:48

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

0093デフォルトの名無しさん

2009/10/22(木) 01:06:04

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

0094デフォルトの名無しさん

2009/10/22(木) 01:40:15

何か問題あるんだっけ?

0095デフォルトの名無しさん

2009/10/22(木) 03:56:29

WPFってかなり素性のいいフレームワークだと思うんだけど
MSと.netというだけで評価されない風潮がある感じがして悔しい

cssのdiv厨ならぬGrid/StackPanel厨になっちゃうのがアレだけど

0096デフォルトの名無しさん

2009/10/22(木) 07:00:36

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

0097デフォルトの名無しさん

2009/10/22(木) 07:53:15

>>90
あれは関数型言語の一部のガワだけを拝借しているに過ぎない。

プログラミングスタイルが本質的に異なるから、
ラムちゃんを書きまくってるからオケとはなかなかいかない。

0098デフォルトの名無しさん

2009/10/22(木) 07:56:57

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

0099デフォルトの名無しさん

2009/10/22(木) 09:30:19

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

0100デフォルトの名無しさん

2009/10/22(木) 09:30:37

そうよ、ダーリン

0101デフォルトの名無しさん

2009/10/22(木) 10:08:16

…………。　さぶっw

■ このスレッドは過去ログ倉庫に格納されています