GUIがむずかしすぎる

1 ：デフォルトの名無しさん：2009/10/18(日) 17:54:43

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

2 ：デフォルトの名無しさん：2009/10/18(日) 18:00:37

糞スレ立てんな

3 ：デフォルトの名無しさん：2009/10/18(日) 18:03:39

gomen

4 ：デフォルトの名無しさん：2009/10/18(日) 18:07:14

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

5 ：,,・´∀｀・,,）っ-○○○：2009/10/18(日) 18:09:16

6 ：デフォルトの名無しさん：2009/10/18(日) 18:14:40

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

7 ：デフォルトの名無しさん：2009/10/18(日) 18:18:30

SDL とか簡単だよ。

8 ：デフォルトの名無しさん：2009/10/18(日) 18:21:33

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

9 ：デフォルトの名無しさん：2009/10/18(日) 18:43:04

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

10 ：デフォルトの名無しさん：2009/10/18(日) 18:49:46

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

11 ：デフォルトの名無しさん：2009/10/18(日) 18:55:53

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

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

12 ：デフォルトの名無しさん：2009/10/18(日) 18:58:21

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

13 ：デフォルトの名無しさん：2009/10/18(日) 18:59:07

VCL MFC WTL WindowsForm WPFは？

14 ：デフォルトの名無しさん：2009/10/18(日) 19:01:21

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

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

これだけだもの。

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

15 ：デフォルトの名無しさん：2009/10/18(日) 19:03:12

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

16 ：デフォルトの名無しさん：2009/10/18(日) 19:04:50

つ

ここいっとけ

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

17 ：デフォルトの名無しさん：2009/10/18(日) 19:07:18

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

18 ：デフォルトの名無しさん：2009/10/18(日) 21:21:01

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

19 ：デフォルトの名無しさん：2009/10/18(日) 21:22:54

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

20 ：デフォルトの名無しさん：2009/10/18(日) 22:29:42

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

21 ：デフォルトの名無しさん：2009/10/18(日) 22:37:04

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

22 ：デフォルトの名無しさん：2009/10/19(月) 00:17:43

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

23 ：わかんないんです（＞＜） ◆WAkan9Ey1g ：2009/10/19(月) 00:56:39

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

24 ：デフォルトの名無しさん：2009/10/19(月) 00:59:01

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

25 ：デフォルトの名無しさん：2009/10/19(月) 00:59:47

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

26 ：デフォルトの名無しさん：2009/10/19(月) 01:03:41

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

27 ：デフォルトの名無しさん：2009/10/19(月) 01:23:46

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

28 ：デフォルトの名無しさん：2009/10/19(月) 02:57:59

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

29 ：デフォルトの名無しさん：2009/10/19(月) 03:28:12

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

30 ：デフォルトの名無しさん：2009/10/19(月) 03:34:35

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

31 ：デフォルトの名無しさん：2009/10/19(月) 06:48:55

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

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

32 ：デフォルトの名無しさん：2009/10/19(月) 12:38:02

アイちゃん遅いよ……

33 ：デフォルトの名無しさん：2009/10/19(月) 12:40:13

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

34 ：デフォルトの名無しさん：2009/10/19(月) 18:04:54

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

35 ：デフォルトの名無しさん：2009/10/19(月) 21:29:10

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

36 ：デフォルトの名無しさん：2009/10/19(月) 21:30:32

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

37 ：デフォルトの名無しさん：2009/10/19(月) 21:32:32

最近 Qt の宣伝多いな…

38 ：デフォルトの名無しさん：2009/10/19(月) 21:34:37

Lily ≠ Qt

39 ：デフォルトの名無しさん：2009/10/19(月) 21:37:08

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

40 ：デフォルトの名無しさん：2009/10/19(月) 21:44:10

DirectX！

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

41 ：デフォルトの名無しさん：2009/10/19(月) 23:24:57

DirextSEX!

42 ：デフォルトの名無しさん：2009/10/19(月) 23:26:38

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

43 ：デフォルトの名無しさん：2009/10/19(月) 23:29:37

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

なんで塵なの？

44 ：デフォルトの名無しさん：2009/10/19(月) 23:41:05

そういう年頃なんだろ

45 ：デフォルトの名無しさん：2009/10/20(火) 00:38:41

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

46 ：デフォルトの名無しさん：2009/10/20(火) 01:24:21

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

47 ：デフォルトの名無しさん：2009/10/20(火) 09:00:57

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

48 ：デフォルトの名無しさん：2009/10/20(火) 10:18:20

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

49 ：デフォルトの名無しさん：2009/10/20(火) 10:20:39

Viewに遷移などない

50 ：デフォルトの名無しさん：2009/10/20(火) 10:29:13

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

51 ：デフォルトの名無しさん：2009/10/20(火) 11:05:17

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

52 ：デフォルトの名無しさん：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)に従った通信が必要になる。

53 ：デフォルトの名無しさん：2009/10/20(火) 15:26:00

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

54 ：デフォルトの名無しさん：2009/10/20(火) 16:10:05

うすうす

55 ：デフォルトの名無しさん：2009/10/20(火) 16:10:52

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

56 ：デフォルトの名無しさん：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と言っても色々あるんだなー

57 ：デフォルトの名無しさん：2009/10/20(火) 17:40:46

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

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

58 ：57：2009/10/20(火) 23:26:53

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

59 ：デフォルトの名無しさん：2009/10/20(火) 23:58:56

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

60 ：デフォルトの名無しさん：2009/10/21(水) 00:08:12

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

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

61 ：デフォルトの名無しさん：2009/10/21(水) 00:28:18

thx!楽しみにしてます!

62 ：デフォルトの名無しさん：2009/10/21(水) 05:30:37

>>60

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

63 ：デフォルトの名無しさん：2009/10/21(水) 09:50:04

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

64 ：デフォルトの名無しさん：2009/10/21(水) 09:58:13

無理ゲー

65 ：デフォルトの名無しさん：2009/10/21(水) 11:19:25

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

66 ：60：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に詳しい住人さん達からのツッコミに期待。

67 ：デフォルトの名無しさん：2009/10/21(水) 15:01:25

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

68 ：デフォルトの名無しさん：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へメッセージを送って、
　全体を制御するオブジェクト。

69 ：デフォルトの名無しさん：2009/10/21(水) 16:21:57

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

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

70 ：デフォルトの名無しさん：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/

71 ：デフォルトの名無しさん：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

72 ：デフォルトの名無しさん：2009/10/21(水) 19:54:28

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

73 ：デフォルトの名無しさん：2009/10/21(水) 20:12:23

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

74 ：デフォルトの名無しさん：2009/10/21(水) 20:24:15

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

75 ：デフォルトの名無しさん：2009/10/21(水) 20:25:03

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

76 ：デフォルトの名無しさん：2009/10/21(水) 20:39:27

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

77 ：デフォルトの名無しさん：2009/10/21(水) 20:39:33

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

78 ：デフォルトの名無しさん：2009/10/21(水) 21:04:59

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

79 ：デフォルトの名無しさん：2009/10/21(水) 21:15:00

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

80 ：デフォルトの名無しさん：2009/10/21(水) 21:20:27

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

81 ：デフォルトの名無しさん：2009/10/21(水) 21:22:40

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

82 ：デフォルトの名無しさん：2009/10/21(水) 21:23:05

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

83 ：デフォルトの名無しさん：2009/10/21(水) 21:25:01

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

84 ：デフォルトの名無しさん：2009/10/21(水) 22:42:36

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

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

85 ：デフォルトの名無しさん：2009/10/21(水) 22:52:46

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

86 ：デフォルトの名無しさん：2009/10/21(水) 22:53:08

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

87 ：デフォルトの名無しさん：2009/10/21(水) 23:10:16

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

88 ：デフォルトの名無しさん：2009/10/21(水) 23:27:55

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

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

89 ：デフォルトの名無しさん：2009/10/21(水) 23:40:25

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

90 ：デフォルトの名無しさん：2009/10/21(水) 23:42:33

つ JavaScript

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

91 ：デフォルトの名無しさん：2009/10/21(水) 23:47:58

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

92 ：デフォルトの名無しさん：2009/10/22(木) 00:19:48

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

93 ：デフォルトの名無しさん：2009/10/22(木) 01:06:04

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

94 ：デフォルトの名無しさん：2009/10/22(木) 01:40:15

何か問題あるんだっけ?

95 ：デフォルトの名無しさん：2009/10/22(木) 03:56:29

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

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

96 ：デフォルトの名無しさん：2009/10/22(木) 07:00:36

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

97 ：デフォルトの名無しさん：2009/10/22(木) 07:53:15

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

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

98 ：デフォルトの名無しさん：2009/10/22(木) 07:56:57

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

99 ：デフォルトの名無しさん：2009/10/22(木) 09:30:19

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

100 ：デフォルトの名無しさん：2009/10/22(木) 09:30:37

そうよ、ダーリン

101 ：デフォルトの名無しさん：2009/10/22(木) 10:08:16

…………。　さぶっw

102 ：デフォルトの名無しさん：2009/10/22(木) 10:42:47

純であることに拘ったって、どうせおまいらが不純にするんだろ。
最初から不純だっていいじゃないか。

103 ：デフォルトの名無しさん：2009/10/22(木) 10:53:29

もちろん不純オーケーな言語もあるし(例:OCaml)、
はじめから不純前提な言語(例:JavaScript)もある
でも、純であることにトコトンこだわった言語、
つまり純なプログラミングしか許さない言語(例:Haskell)もある
そんな純な世界だけでも、GUIプログラムは書けるんだ

104 ：デフォルトの名無しさん：2009/10/22(木) 11:41:11

まあ、アセンブラだけでもGUIプログラムは書けるしな。

105 ：デフォルトの名無しさん：2009/10/22(木) 11:52:03

つまりは、そういうこと
書ける事と、それがやさしい/むずかしいとは別の話
特に、はじめてGUIプログラミングに挑戦しようとする人にとって、
少なくとも現状だと、関数型言語の壁は、あまりに高すぐる

106 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/10/22(木) 19:24:39

>>103
>純なプログラミングしか許さない言語

確か破壊的に書く方法もあったよね。アクションだっけ？
Haskell が良いのは、副作用を禁止するのではなく副作用を
分けて記述出来る事だった様な気がするけど、俺の勘違いかな。

108 ：デフォルトの名無しさん：2009/10/22(木) 20:26:43

>>105
関数型言語（文脈から考えると純粋関数型？）でのGUIプログラムは
手続き型言語でのそれより（現状）難しいと感じてるようですが、
そう感じる理由は何でしょうか。

それは単にスタンダードと呼べるGUIライブラリが整備されておらず、
それに対する入門書も無い状態だからでしょうか。
もしそうなら、それは関数型言語に対して感じる壁とは違うような気がします。

109 ：デフォルトの名無しさん：2009/10/22(木) 20:39:06

>>108
>>105 が難しいと思ってる訳じゃないんじゃないの。
『はじめてGUIプログラミングに挑戦しようとする人にとって』、
壁が高いというのは、俺も同意見だな。

110 ：デフォルトの名無しさん：2009/10/22(木) 20:43:31

>>109
その壁が何に対して感じる壁なのか、が訊きたいです。

また、何故その壁は高く感じられるのでしょうか。

111 ：デフォルトの名無しさん：2009/10/22(木) 21:05:53

君は壁なんか存在しないと思ってるの？

112 ：デフォルトの名無しさん：2009/10/22(木) 21:07:01

>>110
状態を持ちにくいからだろ。
だいたい、GUIなんて俺には副作用の塊に見える。

113 ：デフォルトの名無しさん：2009/10/22(木) 21:13:22

>>110
横槍
たぶん入門書に載ってないからだと思われ
例えばFRPの一部であるevent（の簡易版）は、
Visual Studio 2010のF#にfirst-class composable eventsとして登場する予定
そして、それが「3日でわかる!! VisualStudio 2010」とかで紹介される事になる
そうすると、急に壁が低くなる（と多くの人は錯覚する）
要するに、技術そのものの壁じゃなくて心理的なものだと思う

114 ：デフォルトの名無しさん：2009/10/22(木) 21:16:52

>>111
初めてGUIプログラムをする者にとっての壁はあると思いますが、
それは関数型言語に備わった、関数型言語だからこその壁では無いような気がします。

初めてGUIプログラムをする者は初めてGUIの概念や考え方、組み立て方を学ぶわけですから、
それを関数型言語をベースにして学ぼうが、手続き型言語をベースにして学ぼうが、
壁は同じくらい高く感じられると思います。
そして、それは言語ではなくGUIに対して感じる壁だと思います。

私はどちらのGUIも経験しましたが、確かに関数型言語での方が勉強に時間がかかります。
ただ、それは単に資料が少ないというだけのことで、関数型言語の言語としての壁は感じませんでした。
手続き型の方が資料が少なければ、手続き型の方の勉強に時間がかかったと思います。

115 ：デフォルトの名無しさん：2009/10/22(木) 21:17:17

>>108,110
なにか関数型言語に対する(いい意味での)思い入れがある人みたいだから、
壁が何かを質問するよりも、率直に、関数型言語の良さをカキコしたほうがいいんじゃないかな
たとえば「関数型言語は....という特徴があるから、GUIプログラミングに適している」みたいに

116 ：デフォルトの名無しさん：2009/10/22(木) 21:18:34

各プラットフォームのネイティブの GUI ライブラリが関数型言語で実装されてないから
ハードルは高くなるよな。格闘技の基礎が無いのに異種格闘戦に出るなんて…

117 ：デフォルトの名無しさん：2009/10/22(木) 21:23:17

>>114
資料が少ないのが関数型の特徴だから、手続き型の方が資料が少ないという仮定は
あんまり意味が無いと思う。

118 ：デフォルトの名無しさん：2009/10/22(木) 21:26:54

>>115
いえ、思い入れは全くないんですし、
>>105 に対して関数型はいいよとかアピールする気も全く無いんです。

ただ、>>105 以外でもよく見かけますが、
関数型言語をベースにして、その上で組み立てる物の難しさに対して、
「関数型言語の壁」と言うように言語特有の難しさに括ってしまうのは、
ちょっと違和感を感じただけです。

119 ：デフォルトの名無しさん：2009/10/22(木) 21:29:28

俺も>>112に禿同。

120 ：115&105：2009/10/22(木) 21:35:17

# リロードせずにカキコしちまったゼ

>>114
言いたい事は分かるし、その通りだと思うよ
でも、ここでは「プログラミング言語そのものを比較」をしてるんじゃなくて、
「GUIプログラミングのむずかしさ/やさしさを議論」しているスレなんだ
このスレでは、言語はGUIを実現するための道具、副次的なものであるという立場

>>105で書いた「関数型言語の壁」というのは、他の住人さん達が語っているように、
単純に初心者向けの情報が少ないってことを言いたかった。

121 ：デフォルトの名無しさん：2009/10/22(木) 21:35:29

実際>>112みたいな問題って関数型だとモナドやカリー化、継続みたいな難しそうな概念を使って解決してるんだろ？
詳しくないから想像だけど。

122 ：デフォルトの名無しさん：2009/10/22(木) 21:47:20

>>116
>格闘技の基礎が無いのに異種格闘戦に出るなんて…

面白い「たとえ」だね。ワロタよ。同感だ。

関数型言語に思い入れのある格闘家さん達は、今は己の技を磨くことに集中したほうがいいと思う
気持ちは分かるんだけど、なぜ自分達の流派が分かってもらえないんダァーと、いくら主張しても、
今の格闘センスでは、空回りに終わるか、かえって他の保守的な格闘家達からの反発をまねくだけ

123 ：デフォルトの名無しさん：2009/10/22(木) 21:50:45

>>121
実際 >>112 みたいな問題はライブラリがやってくれるから、
それを使うだけのユーザーは、
どうやって実現しているのか意識する必要すらないです。

たとえば .NET Framework で
WFC がどうやってイベントのチェーンを実現しているのか
ユーザーは考える必要がないのと似ています。

だから、実際ライブラリを使うだけなら、
その資料とチュートリアルがあれば、
GUI 入門者でもちゃんと（使い方の）勉強はできます。
だから、「純粋にGUIプログラムを組むまでに至る難しさ」という点では
手続き型でも関数型でも同じ程度だと思います。

好奇心があってその内部処理を勉強しようとした時に、
初めて（純粋）関数型言語特有の考え方が顕著に現れてきます。

124 ：デフォルトの名無しさん：2009/10/22(木) 21:57:08

>>123
すいません、WFC ではなく WPF です。

・・・なんか違和感あると思った

125 ：デフォルトの名無しさん：2009/10/22(木) 21:57:17

関数型言語がむずかしすぎる(´・ω・｀)

126 ：デフォルトの名無しさん：2009/10/22(木) 22:00:09

>>123
なるほどー。けどそうなると初学者は関数型でのGUIプログラミングは言語特性との矛盾を感じながらの実装になりそうだからストレスフルだと思う。
そこが壁なんじゃない？

127 ：デフォルトの名無しさん：2009/10/22(木) 22:02:02

関数型言語にも、.NET Framework みたいな網羅的なライブラリがあって、
日本語のドキュメントやサンプルコードが豊富に揃っていればそうでしょうね。
ライブラリは FFI なんかで呼び出すとしても、ドキュメント類が無いから
何か詰まったら初心者にはお手上げじゃないかな。

128 ：デフォルトの名無しさん：2009/10/22(木) 22:02:30

>>126
ん？　言語特性との矛盾とは？

129 ：デフォルトの名無しさん：2009/10/22(木) 22:02:47

>>123
>好奇心があってその内部処理を勉強しようとした時に、

このスレの住人の好奇心はGUIプログラミングに向いているんだが....
関数型言語に好奇心があるのなら、該当するスレへ逝って、そこで大いに語れ

130 ：デフォルトの名無しさん：2009/10/22(木) 22:03:37

>>123
>「純粋にGUIプログラムを組むまでに至る難しさ」

むしろ不純な部分として議論から省こうとしてる部分が大事だったりするんだよね。
「現実的にGUIプログラムを組むまでに至る難しさ」は大いに違う訳だし。

131 ：デフォルトの名無しさん：2009/10/22(木) 22:04:14

なんだかんだでGUIはオブジェクト指向型言語の独壇場じゃね。
面倒なステート管理、プロパティ設定を程よく抽象化してくれる。

132 ：デフォルトの名無しさん：2009/10/22(木) 22:07:14

>>131
俺もそう思う。イベントドリブンなプログラムとオブジェクト指向の相性は抜群。

133 ：デフォルトの名無しさん：2009/10/22(木) 22:10:27

>>128
「基本副作用無しのはずなのになんでウインドウ出せるの？」
「ボタン押したら現在時刻をポップアップする機能って呼び出しから結果が定まらなくね？」
みたいな事だよ。

134 ：デフォルトの名無しさん：2009/10/22(木) 22:14:02

>>130
手続き型言語で CUI を学んだ者が GUI にステップアップするのと、
関数型言語で CUI を学んだ者が GUI にステップアップするのとで、
GUI をプログラムするに至るまでの難しさは、それほど違うものでしょうか。

>>1 がどちらのタイプかは知りませんが。

135 ：デフォルトの名無しさん：2009/10/22(木) 22:14:07

GUIの難しさって、要するに何やるにもライブラリに合わせないといけないことだとおもう。
全部自分で書くのは無謀過ぎるんでライブラリ使うことになるけど、そうするとライブラリに合わせた書き方をするしかない。

136 ：デフォルトの名無しさん：2009/10/22(木) 22:19:36

>>134
違うと思うよ。理由は散々出てると思うけど。

137 ：デフォルトの名無しさん：2009/10/22(木) 22:19:44

>>135
「何やるにもライブラリに合わせないといけない」ってのは、GUIに限らず、
あらゆるプログラミング(標準入出力ライブラリを含む)で共通じゃね
GUIのむずかしさとは違う希ガス

138 ：デフォルトの名無しさん：2009/10/22(木) 22:21:33

>>131
>面倒なステート管理、プロパティ設定を程よく抽象化してくれる。
じゃぁ「むずかしすぎる」訳ではないと？

139 ：デフォルトの名無しさん：2009/10/22(木) 22:21:38

>>137
ライブラリの規模が違うでしょ
GUI のライブラリの規模を無視して一般化しようとしてもダメなんじゃないかな

140 ：デフォルトの名無しさん：2009/10/22(木) 22:27:59

>>133
あぁ、なるほど、それなら納得です。
確かに初学者が感じる壁はその辺りにあります。

ただ、たいていの関数型言語を学ぶ者は、CUI プログラムを学んでいる途中で、
上記のような壁をできるだけ低くするように働く概念を学びますから、
GUIでその壁に当たっても、合点がいくには至りませんが、
ストレスフルとなるまでにはいかないような気がします。
そこでストレスフルとなるなら、CUIで勉強し直した方がいいですし。
まぁ感じ方は人それぞれですが。

はい、確かにその辺りに関数型言語でのGUIの壁がありますね。
納得しました。

141 ：デフォルトの名無しさん：2009/10/22(木) 22:29:53

>>131
細かいツッコミだけど「オブジェクト指向型言語」じゃなくて、
「オブジェクト指向手続き型言語」あるいは簡略に「オブジェクト指向言語」だろね
研究レベルだけど、オブジェクト指向分散関数型言語なんてのもあるから(例:ABCL)

142 ：デフォルトの名無しさん：2009/10/22(木) 22:36:32

>>138
どうだろ？
「なんとか一般の人間様に制御可能なレベルになった」ってレベルじゃね？
微分とか積分とかがわからん奴には「難しすぎる」ってレベルぐらいには難しいと思う。

アップルのGUIが優れてるのは何か優れた手法をとっているとかではなくて、
それこそジョブスの鬼のようなシゴキで調整されているからなんだと思う。

143 ：デフォルトの名無しさん：2009/10/22(木) 22:37:49

>>139
ならば、科学計算ライブラリは、ライブラリに合わせずにプログラミングできるの？
「何やるにもライブラリに合わせないといけない」というのは、
GUIプログラミングに固有のむずしさではないと思うよ

「GUIライブラリの規模(複雑度)が大きいから」むずかしい、という理由も同じだね

144 ：デフォルトの名無しさん：2009/10/22(木) 22:42:15

GUIの理論的なモデルってあるの？
知っている人がいたら教えてプリーズ
「なんか便利そう」で対応してたんじゃ拉致があかない

145 ：デフォルトの名無しさん：2009/10/22(木) 22:45:23

>>143
同じだと思う根拠は？

146 ：デフォルトの名無しさん：2009/10/22(木) 22:46:09

>>144
GUIの理論的なモデルって、どういうのを期待してるんだ？

147 ：デフォルトの名無しさん：2009/10/22(木) 22:47:16

コマンドラインやっとだったらズブの初心者だろう。
CUIもまともに出来ないんじゃないの?

148 ：デフォルトの名無しさん：2009/10/22(木) 22:52:16

科学計算ライブラリが具体的にどのライブラリをさしているのか分からんけど、
XMLのパースとかレイトレとかは殆どフルスクラッチで書けるからライブラリの
仕様に合わせる必要は無い。GUI をフルスクラッチで書くのは規模的に難しい。
コピペとかドラッグ＆ドロップとか日本語入力変換とかベクターフォントの描画とか
一から作るのはごめんだ。

149 ：デフォルトの名無しさん：2009/10/22(木) 22:55:21

GUIをモデル化したらCUI化するに違いない

150 ：デフォルトの名無しさん：2009/10/22(木) 22:58:06

もう飽きたし面倒くさいから
標準入出力でいいわ。

151 ：デフォルトの名無しさん：2009/10/22(木) 22:58:14

>>146
期待する性質としては、こんな感じ
1 その理論は描画とGUIコンポーネントとその組み合わせの世界を抽象化している
2 非同期に発生するイベントと内部状態の遷移と描画の結果と時間との関係を明らかにしている
3 抽象化された世界に必要十分な操作が導き出せる
4 必要十分な操作から便利な操作が合成でき、結果としてGUIライブラリの理想形が見えてくる
欲張りすぎか...

152 ：デフォルトの名無しさん：2009/10/22(木) 22:58:24

>>144
拉致しちゃダメよw

153 ：デフォルトの名無しさん：2009/10/22(木) 23:12:53

>>151
すまん、いまいち分からん。

その性質を一部でも満たした既存のモデルは何か無いか？
あるいは一部なら満たすモデル案を君が既に考えているとか。
それらと対比してくれると理解できると思うんだが。

154 ：デフォルトの名無しさん：2009/10/22(木) 23:24:14

>>148
たぶんHaskellみたいな近代的な関数型言語のことを言っているのだと思う
でも、たとえばXMLのパーズくらいはフルスクラッチで書けるとあるけど、
XMLスキーマに基づくXML文書の検証も可能なXMLパーザも
Haskellならばフルスクラッチで書けるのかな？無理じぇね？
Haskellがそれほどフルスクラッチで書ける素晴らしい言語なのだとしたら、
GUIくらいはフルスクラッチでサラッと書いて欲しいものだと思うよ

155 ：デフォルトの名無しさん：2009/10/22(木) 23:32:57

>>154
俺は関数型言語の御仁とは別人だよ。Haskell はどうでも良い。

>>137 に、

>「何やるにもライブラリに合わせないといけない」ってのは、GUIに限らず、
>あらゆるプログラミング(標準入出力ライブラリを含む)で共通じゃね

とあるから、それは違うよねと言ってるだけだよ。
例えばレイトレは違うから「あらゆる」というのは間違い。
言ってる事通じてるかな。

156 ：デフォルトの名無しさん：2009/10/22(木) 23:38:36

実際のところ GUI ほどライブラリのお仕着せが強い分野もそうそうないでしょ。
しかもそれが殆ど標準化されてない。

157 ：デフォルトの名無しさん：2009/10/22(木) 23:38:48

>>153
Fudgets
http://www.cs.chalmers.se/ComputingScience/Research/Functional/Fudgets/
これにはコンポーネント同士を演算する仕組みがあって期待するものにちょっと近い
でもまだ遠い

158 ：デフォルトの名無しさん：2009/10/22(木) 23:40:30

GUIはまだまだハッテン途上だね

159 ：デフォルトの名無しさん：2009/10/22(木) 23:40:53

>>>>137 ってさ、
各ライブラリの使い方にはクセや流儀があるから、
そのクセや流儀にプログラマの方が合わせなくちゃいけない、
それは GUI ライブラリに限ったことじゃないよ、といいたいんだと思うが。

レイトレを実行するライブラリというものがあるとして、
そのライブラリもやっぱり作法みたいなものがあると思うが、
プログラマはその作法に合わせなきゃいけないんじゃないの？

160 ：デフォルトの名無しさん：2009/10/22(木) 23:43:10

>>157
さんきゅ

今日はもう眠いから、明日読んでみる

161 ：デフォルトの名無しさん：2009/10/22(木) 23:45:35

>>159
小規模のライブラリなら自分で作り替えたり、一から作り直したり出来るでしょ。
ライブラリの癖や流儀に合わせなくても良い。

162 ：デフォルトの名無しさん：2009/10/23(金) 01:11:52

>>160
Fruitもちょっと近い
http://haskell.cs.yale.edu/frp/genuinely-functional-guis.pdf
イベント繋がりにarrowが入っているので必要十分な感じがいい
でもレイアウトほぼ無視
イベント繋がりとレイアウト繋がりとの関係も無視
描画とコンポーネントの関係も無視
まだまだ遠い

163 ：デフォルトの名無しさん：2009/10/23(金) 06:20:20

>151
おもにC#つかってるんだが、諸事情でFormとかでWPFみたいに使えるフレームワーク作った。
それでごりごり作ってる途中で同じようなことちょとおもた。
論理からでなくてボトムからの必要性からだけど。
今落とし込もうとしてるのは並列性含むモデルと状態、その遷移。それらの投影と操作にたいするUIの疎結合。
それら出来るとだいぶ生産性あがりそうな予感。

164 ：60：2009/10/23(金) 12:13:35

Win32++文書翻訳を試したという話(>>66)のカキコ主だけど、
Win32++が....と比べて易しい/難しいという話題ならともかく、
それ以上はスレ違いかなと思った。板一覧を見直したところ、
「【C++】マイナーGUIツールキット」というスレがあるみたいだから、
翻訳話については、自分はそのスレへ移動するよ。

あと、著作権についてだけど、議論してくれた住人さん達に感謝する。
自分は自信が無いので、傍観していた。
とりあえず、>>71がマトメてくれた内容を反映させようと考えている。

165 ：デフォルトの名無しさん：2009/10/23(金) 17:57:46

【C++】マイナーGUIツールキット
http://pc12.2ch.net/test/read.cgi/tech/1065627704/

166 ：デフォルトの名無しさん：2009/10/24(土) 16:23:47

GUIって画面レイアウトと処理を完全に切り離すのは本当に正しい設計なのかな。
MVCで描こうとすると、いつもVがMのプロパティを多量に参照するから、Mの隠蔽が甘くなって嫌な感じになる。

167 ：デフォルトの名無しさん：2009/10/24(土) 17:32:19

VがMを参照するのをやめて、CがVとMの仲介をするようにできないのか？
MVCの3つとも綺麗に書く方法は無いような気がするから
Cが汚い仕事を一手に引き受ければいいと思う。

168 ：デフォルトの名無しさん：2009/10/24(土) 17:55:36

そうするとMのVでの表示のために必要なインタフェースをCで再定義することになる。
自分的には微妙。
C++のfriendみたいにMを更新するものについてはCからしか見えないような感じにしてVからは参照のみと操作の起点、Cはその操作に基づく具体的なMの更新とするのが自分的には一番しっくり。

169 ：デフォルトの名無しさん：2009/10/24(土) 20:27:37

>>157
論文にざっと目を通してみた。

期待する性質１でいう「GUIコンポーネント」というのは、
ボタンやテキストボックスなどが持つ機能や役割の事で、
「描画」というのはそれらの外見の事だよね。
それらのエッセンスに目を向けて抽象化しているからこそ「モデル」なのだから、
どのモデルも性質１は満たしているはず（でなければモデルではない）。

性質２はほぼ満たしていると思う。
Fudgets は入力されたデータやイベントをストリーム型のデータで扱っていて、
入力から出力へ向かう流れの中でそのデータを発生させたり加工したりしている。
[1] GUI からの入力イベント、[2] そのイベントから状態遷移＆データ出力、
[3] 出力データのGUIでの表示、という各パーツがひとつの関数に対応していて、
流れの中でリレーのバトンようにストリームデータを受け渡している。
[1]～[3] の各パーツが流れの中でどの役割を担うのか（加工なのか表示なのかなど）
がはっきりしているから、性質２は満たしている。
それらパーツの独特の繋ぎ方が Fudgets のウリだと思う。
ただ、論文執筆時（1998）にはまだストリームに時間の概念を表すデータはない。

性質３と４がよく分からんな。
（抽象化された世界に、ではなく、抽象化された世界から、じゃない？）
Fudgets で定義されているパーツを使えば、今トレンドとなっているGUIパーツは
理論的にはほぼ表現できると思うから、そういう意味では必要十分だと思うが。

ちょっとどころか半分は期待する性質を満たしていると思うが、
期待するものには未だ遠いと感じる理由は性質３と４に関係する？
それとも性質１や２もまだ十分満たしていないと考える？

170 ：144：2009/10/24(土) 20:38:46

>>169
おぉ、論文まで読んでくれた人がいる
ありがとう
で、返事書くからちょっとまってね

171 ：144：2009/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 ：デフォルトの名無しさん：2009/10/24(土) 21:39:37

>>171
なるほど、そこまで言ってくれると「必要十分」の意味がよく分かる。

Fudgets は「この方法に帰着できる」という本質を追究するためのものじゃなくて、
imperative とは違い Functional ならこう書くのが筋が良いというのか主な主張だら、
確かに研究の目的が違うね（結果的に一部では近づいているが）。

> 私の勝手な期待について議論してくれてありがとう
いや、こちらこそかなり興味深く、勉強になった。
たぶん GUI プログラムをより分かりやすくする、より容易にすることに繋がると思う。

173 ：144：2009/10/24(土) 22:35:31

>たぶん GUI プログラムをより分かりやすくする、より容易にすることに繋がると思う。
そう連想してくれる人がいるんだ
私の期待が頓珍漢じゃない事は証明されたので、絶対誰か似たような研究をしている人がいるはずだ
けど、ググっても見つからない
教えてエロい人

174 ：デフォルトの名無しさん：2009/10/24(土) 22:51:13

理論が完成すると、それまでの試行錯誤が無かったことにされる。
それで、「新しい」理論が、試行錯誤という「古い」ものを打破する、
と考える人がいるけど
試行錯誤という過程と、理論という結果を対立させるのは変じゃないか。

コードで試行錯誤しないなら、舌先三寸で試行錯誤するしかなくなるんだよ。

175 ：144：2009/10/24(土) 23:38:38

試行錯誤という過程を否定したように聞こえたのなら、ごめんなさい、気を付けます
でも、もうそろそろ結果（理論）が欲しい。強く
理由もあります
一つはマルチタッチのような複雑な入力インターフェイスが一般化してきたら、
このままではGUIの開発が破綻する危惧を強く持っているから
少し遅れてWebの世界でも同じ事が起こるでしょう
もう一つは現在でもGUIの開発が非効率的過ぎるために全世界的に無駄なコストが垂れ流れていると認識しているから
最後の一つは私が会社でGUIを作る仕事をやっていて苦痛だから

176 ：デフォルトの名無しさん：2009/10/24(土) 23:55:23

GUIにかぎらず状態の取り扱いから並列性なども含めて銀の弾丸になるような理論・結果は出来てないでしょ。
のでお舞が自分に都合のいいものを作れ。

177 ：144：2009/10/25(日) 00:33:59

精進します
>GUIにかぎらず
でも、ここだけ。
例えば並列性で言えば、アクターモデル、Software Transactional Memory、Concurrent MLのようなある程度「モデル」に近いものがあります
その下位にはπ計算のような基礎もあります
状態の取扱いというと一般的になりすぎて難しいですが、
オートマトンという強力なモデルがあります
その上に正規表現やPEGが構築されています
これらのモデルは銀の弾丸ではありませんが、不可欠で、ソフトウェアの飛躍に大いに貢献しています
こういうものがGUIの分野にも欲しいのです
諦めた方がいいですか？

178 ：デフォルトの名無しさん：2009/10/25(日) 06:40:53

>>177
開発現場からの悲痛な叫びに聞こえるが、
美しい理論と泥臭い現実とのギャップに苦しんでいるのは、
君だけじゃないよ！！

横レス失礼

179 ：デフォルトの名無しさん：2009/10/25(日) 09:43:20

開発現場からの悲痛な叫びを汲み取って、
とりあえず答えをいち早く提示してくれるのは、
いつも大抵MSですね。

180 ：デフォルトの名無しさん：2009/10/25(日) 09:56:04

>>179
え！？
kwsk

181 ：デフォルトの名無しさん：2009/10/25(日) 10:07:21

その答えが更なる叫びを生み出すわけですが…

182 ：デフォルトの名無しさん：2009/10/25(日) 10:27:38

X-window時代はMotifでシコシコやっていたけど、今じゃあ簡単にできるようになったよね。
むしろ、今の方がどういう経緯というか仕組みで動作しているのか分からなくなった感じだな。
クラスライブラリ便利すぎ（　・ω・）ｙ─┛～～

183 ：デフォルトの名無しさん：2009/10/25(日) 10:35:54

XLibはうんこすぎるのでその詳細なんて知るだけ無駄だから気にする必要ないと思うよ

184 ：デフォルトの名無しさん：2009/10/25(日) 10:54:52

>>180
MSは抽象的な理論からというよりは、
現場の問題を解決する方向で技術を開発してるように
私には見える。

たとえば、IEの拡張とか、WPFやLINQとか。

それが叩き台となるんだけど。

185 ：デフォルトの名無しさん：2009/10/25(日) 11:27:52

>>180

>>181再び
一般に「叩き台」という言葉は良い意味で使われるけど、MSの場合は、それが当てはまらないｗ
初級GUIプログラマにとっては、かえって阿鼻叫喚をもたらす災厄だったりする

186 ：デフォルトの名無しさん：2009/10/25(日) 11:58:39

そうだねえ
.netやらWPFやらsilverlightやら最近のMS技術に付き合ってきた印象では、どれもおおむね
バージョン1→技術コンセプト扱い。使い物にならない。将来的にサポートを切られるので危険
バージョン2→格段にバージョンアップする。そこそこ使い物になる。1とは互換性がない
バージョン3→意欲的でユニークな新機能も搭載し始めるようになる。使い物になる

という道筋を歩いてるのが面白いなあと。
「MS＝バージョン3の法則」は意図的だな絶対

187 ：デフォルトの名無しさん：2009/10/25(日) 13:54:25

C++なんか捨ててVBにしなよ　VBなら超簡単

188 ：デフォルトの名無しさん：2009/10/25(日) 14:58:44

ＶＢならC++ Builderに来いよ(´･ω･`)

189 ：デフォルトの名無しさん：2009/10/25(日) 15:32:23

>>188

http://www.componentsource.co.jp/products/c-builder-2010-j/index.html
\ 98,700 (税込) 1 開発ライセンス

買えませんｗ

190 ：デフォルトの名無しさん：2009/10/25(日) 15:36:06

無料配布してるぞ

191 ：デフォルトの名無しさん：2009/10/25(日) 15:42:23

トライアル版しかなかった

192 ：デフォルトの名無しさん：2009/10/25(日) 16:56:20

TurboExplorerシリーズは公開停止だぜ

193 ：デフォルトの名無しさん：2009/10/25(日) 17:24:38

>>177
筋はいいと思うけど、モデル構築自体が大変な作業になるんだけどっていうような無茶な要求が出てくるのがGUI。
「こうやった方が(モデル的に)スマートです」と言っちゃうのは技術屋の都合でしかないしね。

194 ：144：2009/10/25(日) 21:17:34

>>193
もしかして、「GUIのモデル」が出来たとしても、
それを逸脱する要求に対応しなくてはならなくなって、結局使えず、
使おうとすると、スマートだけども使えないモデルを客に押しつける事になる、
と考えています？
だからモデルなんて考えるのは諦めろという訳ですね
うーん、考えられなくもないですが、その「無茶な要求」の例が欲しいですね
そもそも「GUIのモデル」が出来ていないのでその弱点を議論できないのですが、
もし始めからムチャそうな話が分かっていれば、そこをカバーできるように抽象化していけます
ぜひご協力を

195 ：デフォルトの名無しさん：2009/10/25(日) 22:09:21

javaのawtを解析してみればどうかな、自分に必要な関数だけそろえて後は移植すると・・・
ちなみに自分はLSI-C86に移植してみた
ttp://www.forest.impress.co.jp/article/2006/08/03/explorerdos.html

196 ：144：2009/10/25(日) 22:27:43

>>193
あっ、もしかして私が期待しているGUIモデルを機能ミニマムなものだと勘違いておられる？
私が期待しているGUIモデルは対象機能を絞ってミニマムを考えようという方向ではなく、
シンプルだけれども強力な抽象化をしようという方向です
「そんなもの無理www」と言われればそれまでですが

197 ：デフォルトの名無しさん：2009/10/25(日) 22:50:13

Aの入力結果でBの候補が決定されるようなUIを作る時に
「冷静に考えたらAとBはここで同時に設定する必要性ないよね？なんで一画面なの？
　Aの入力分析してBの候補を出すけど、そのあとAの入力変えたらBに矛盾が出るよ？」
って言っても
「例外ケースで矛盾が出るのはそれとして、利用者はこの画面で同時に入れたいんだよ！」
と押し切られるケースは多い。

じつはまさにそんな設計のせいで、新規機能の開発が遅れてる製品があるんだけど、
その責任は開発持ちっていうのはなんだかなぁ～って思ったりもする。

198 ：デフォルトの名無しさん：2009/10/25(日) 22:51:19

>>196
>勘違いておられる？
勘違いておられました。

199 ：デフォルトの名無しさん：2009/10/25(日) 22:53:52

>>195
それは >>144 が求めているものとはちょっと違うと思う。
GUIモデルをクラスと考えれば、javaのawtというのはそのインスタンスだ。
>>144 が考えるのは、この比喩で言えばクラスの方。

awtを設計するにおいて基にした考え方、実現方法を知って、
それを >>144 が期待する条件という観点で分析する。

その為にはawtのソースコードやクラス階層図などより、
どちらかと言うと論文の方が欲しいところ。
論文なら、awt以前の何の問題をどう解決したのかが簡潔に書かれているはず。

そういう分析を「解析」と言っているのなら、単に私の勘違いだが。

200 ：デフォルトの名無しさん：2009/10/25(日) 23:01:28

>>199
なるほど、自分には無理っす。

201 ：デフォルトの名無しさん：2009/10/25(日) 23:04:49

FRP関係の研究を追い掛けていくぐらいしか無いかな
一人の人間の脳でやるにはややこしすぎる問題だ

202 ：デフォルトの名無しさん：2009/10/25(日) 23:13:18

おっと、sage忘れてた。

>>201
仕事ではやりたくないが、
趣味でやる分には知的活動として面白いな。

203 ：144：2009/10/25(日) 23:36:59

>>197
具体例ありがとうございます
GUIは思っている以上に複雑になり得るものだと認識しておきます
>>201
やはり有望なのはFRP関連になりますか
私もそれ以外見付けられていないのが現状です

204 ：144：2009/10/26(月) 00:11:29

GUIのモデル化へ向けて、（今のところ）鍵だと思われる考え方まとめ
1 time varying value
2 composable event
3 software transactional memory(or join calculus)
4 linear programming

205 ：デフォルトの名無しさん：2009/10/26(月) 23:22:30

↓に制約プログラミングがどうたら、それを使ってGUIがどうたらとかあるけどどうよ？
自分はまだそこまで読み切ってない。

http://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 ：デフォルトの名無しさん：2009/10/27(火) 00:17:39

Amazon へのリンクは http://amazon.jp/dp/4798113468/ でオケ

GUI は理論が実装に勝てない分野の一つじゃないかな。

207 ：デフォルトの名無しさん：2009/10/27(火) 17:28:10

スレ違いだが、なんでamazonはようつべみたいに、
コピペ用の短いURL載ってないんだろうな？

208 ：デフォルトの名無しさん：2009/10/27(火) 18:10:13

（俺の嫌いな）SEOってやつだよ。

長いリンク・・・本の題名が含まれたリンクが張られるだろ？
たくさんリンクされているページはよいページ、
そしてそのページの内容は、リンクの文字と関連がある。
リンクの文字は検索される。

この板ならこれぐらい言えば、理解してもらえるだろう。

209 ：デフォルトの名無しさん：2009/10/28(水) 12:40:31

>>205
あぁ、なんだっけ、ガウディ本って言うんだっけ
GUIの話が載ってるなら読んでみようかな
制約系の手法も部分的に期待しているし

210 ：デフォルトの名無しさん：2009/10/29(木) 20:48:32

causal commutative arrows
http://lambda-the-ultimate.org/node/3659
Yampaが例に出てるし一読してもいいかな

211 ：デフォルトの名無しさん：2009/12/08(火) 16:56:52

会社で無理やりPGにさせられたけどGUIはCUIにくらべて格段にむずすぎますぅ

212 ：デフォルトの名無しさん：2009/12/08(火) 17:15:26

Tcl/Tkでもやりなさい

213 ：デフォルトの名無しさん：2009/12/08(火) 19:59:45

javafxのbind構文はどうだろ
劇的にGUIプログラミング楽になったりする？

214 ：デフォルトの名無しさん：2009/12/13(日) 00:22:56

ＧＵＩは、サンプル読んでイベントハンドラのとこ重点にソース読んでれば理解が早いと思うよ。
サンプルに処理を追加して、既存のイベントから呼ばせてみると仕組みが分かるかと。
javaのswingとかシンプルだから触ってみては？
SWTも良いかも。

215 ：デフォルトの名無しさん：2009/12/14(月) 15:39:44

Javaってどこにマヌアルあるの？

216 ：デフォルトの名無しさん：2009/12/14(月) 15:41:28

「java api」でググるとよろし

217 ：デフォルトの名無しさん：2009/12/14(月) 16:00:18

>>216
おお、こんな所があったのか。
Net豆のヘルプから辿れるようにしとけばいいのに。

218 ：デフォルトの名無しさん：2009/12/16(水) 17:33:55

JavaScriptとかVBAとかTcl/Tkとか、そこからやってみれば？>>1

219 ：デフォルトの名無しさん：2009/12/16(水) 18:38:50

逆にむずいだろ
VB6でやるのが一番

220 ：デフォルトの名無しさん：2009/12/16(水) 18:53:40

VBはVC++なみに難しかった記憶がある。最近はそうでもないの？
VBなら最初からC#のほうがよくないかな？

221 ：デフォルトの名無しさん：2009/12/18(金) 00:00:24

VBはな、イベント処理の仕組みが理解し辛いのよ。
誰でも作れるように、難しい箇所はラップして理解させないようにしてる。

VBIやっても、多言語でGUIは使いこなせないのがほとんど。
VBでも凄い人は居るけど、そんな人は多言語も使える人だったりする。
VB、C++、ゲームで組み込みとか色々やったけど、javaがシンプルで無難だと思うよ。

222 ：デフォルトの名無しさん：2009/12/18(金) 00:08:34

Tcl/Tk は簡単で良いね

223 ：デフォルトの名無しさん：2009/12/21(月) 12:50:37

簡単だよね

224 ：デフォルトの名無しさん：2009/12/25(金) 14:05:58

ウインドウズアプリを作るならウインドウズの仕組みを知ってて当然

225 ：デフォルトの名無しさん：2009/12/30(水) 00:28:55

そしてその仕組みが広大なんだよな
やりたいことへの到達点が遠すぎる
一見意味不明なtypedefが更にやる気を削いでいく

226 ：デフォルトの名無しさん：2009/12/30(水) 15:07:55

このOSじゃないと！ってのがなけりゃJavaとかでいいんだよ

227 ：デフォルトの名無しさん：2009/12/31(木) 08:49:00

それでwxやGTK+、Qtを使うようになるんだよな
しかもLLバインディングで
そして「見た目がなんかWindowsと違ってキモい」と言われるんだよ

228 ：デフォルトの名無しさん：2010/01/01(金) 11:08:49

.NETはフォームエディタも含めて十分に簡単だと思うけどそれじゃダメな理由はなんなのかな。
WPFじゃなくてWinFormsのほうね。WPFはリッチなデザインのGUIが欲しい人以外には不要だと思う。

229 ：デフォルトの名無しさん：2010/01/01(金) 21:02:47

HSPやっときゃいいじゃん。やりつづければWindowsのしくみなんていやでもわかる

230 ：デフォルトの名無しさん：2010/01/02(土) 21:27:22

>>228
>.NETはフォームエディタも含めて十分に簡単だと思うけどそれじゃダメな理由はなんなのかな。
.NETでGUIを作っていて難しいと感じたことは無いですか？
イベントがいつ発生するのかとか、その順番とか、自分が欲しいイベントはどれなのかとか。
もしくはテキストコントロールやグリッドコントロールに思い通りの動きをさせるにはどうすればいいかとか。

231 ：デフォルトの名無しさん：2010/01/03(日) 23:48:13

.NET FW で難しいとか思うんなら
もういっそ諦めればいいと思うんだ。

232 ：デフォルトの名無しさん：2010/01/04(月) 12:16:41

>>231
諦めちゃうの？もう十分に簡単？
難しいとか思うから改善したくなるわけで、諦めたらそこでおしまいですよ。
（他の優先事項があるってのはそうかもしれないけど、ここはGUIのスレなので）
.NETにもRxとかいうFRPっぽいやつが実装されてくるらしいけど、
http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx
現状で十分に簡単なら必要ないね？

233 ：デフォルトの名無しさん：2010/02/20(土) 16:17:18

＞＞１
がんばれ～

234 ：デフォルトの名無しさん：2010/02/21(日) 01:28:46

とりあえずC++の文法やったんだがGUIがどうすればいいかわからん
Qt wxWidgets MFC win32api どれやればいいんだ？
MFCとかwin32apiは過去のものなの？

235 ：デフォルトの名無しさん：2010/02/21(日) 02:28:18

過去のもの
もちろん今でも使えるけど
わざわざそんな面倒な方法をとらない
Cに対するアセンブラみたいなもの

236 ：デフォルトの名無しさん：2010/02/21(日) 02:57:52

友達ならMFC薦めるなってばっちゃが言ってた

237 ：デフォルトの名無しさん：2010/02/21(日) 03:15:10

友達なら当たり前

238 ：デフォルトの名無しさん：2010/02/21(日) 13:45:59

もっさりでも手軽さを重視すればC#
面倒くさくてもぬるぬるが好きならMFC
自他共に認める変態ならAPIのみ

239 ：デフォルトの名無しさん：2010/02/21(日) 23:55:27

>>234
Qtやりましょうよ。

240 ：デフォルトの名無しさん：2010/02/22(月) 01:31:36

もうHTMLでいいじゃん。

241 ：デフォルトの名無しさん：2010/02/22(月) 02:22:56

オレにとっては一時期の飯の種であったMFCが
コケにされるのは寂しいが、さすがにお勧めはできないな
Win32APIはWindowsを知るという意味では無駄にならないと思うがね

242 ：デフォルトの名無しさん：2010/02/22(月) 02:28:28

MFCは無駄すぎ

243 ：デフォルトの名無しさん：2010/03/02(火) 23:12:51

xlibに挫折
Qtは拡張構文が追加されてそうで嫌
で、gtkmmを学び出す

244 ：デフォルトの名無しさん：2010/03/03(水) 03:28:33

gtk/gtk++/gtkmm は糞
Qt は良いよ

245 ：デフォルトの名無しさん：2010/03/03(水) 09:29:35

拡張構文ってgccとvc使っているんだけど

246 ：デフォルトの名無しさん：2010/03/03(水) 13:31:33

Q_OBJECTやslotsはなぁ

247 ：デフォルトの名無しさん：2010/03/03(水) 16:33:11

マクロだろ

248 ：デフォルトの名無しさん：2010/03/03(水) 18:13:46

マクロに拒絶反応を示すのは抽象的思考が出来ないほど知能が低いということ

249 ：デフォルトの名無しさん：2010/03/03(水) 18:47:24

Qtっていまだにmoc必須なん？

250 ：デフォルトの名無しさん：2010/03/03(水) 18:48:29

moc 無かったら Qt じゃないだろ

251 ：デフォルトの名無しさん：2010/03/03(水) 18:59:02

気持ち悪いね

252 ：デフォルトの名無しさん：2010/03/03(水) 19:00:12

気持ち悪いね

253 ：デフォルトの名無しさん：2010/03/04(木) 04:06:04

Qtって、foreachとかも追加されてなかった？
fltkはC++の地味な機能しか使わんとかなんとか

254 ：デフォルトの名無しさん：2010/03/04(木) 04:45:04

http://qt.nokia.com/doc/4.0/qt4-tulip.html

FLTKは知らん。

255 ：デフォルトの名無しさん：2010/03/04(木) 08:21:48

emit なんてのもある

256 ：デフォルトの名無しさん：2010/03/11(木) 22:01:11

>>244
gtk/gtk+/gtkmm のどこがだめ?

257 ：デフォルトの名無しさん：2010/03/23(火) 17:51:26

CUIの達人ですがGUIはさっぱりです

258 ：デフォルトの名無しさん：2010/03/23(火) 18:05:28

Qtって前少し使ったときあまり良い本とか文書が無かったけど今はどうなんだろう
designer でGUIデザインするのはGUIですれば良いしできるのに，
demoを含めて打ち込む方法を説明していたりするのが以前は意外と多かった
Molentkin とか参考になった覚えある

259 ：デフォルトの名無しさん：2010/03/24(水) 00:10:20

説明を書く側からすると、GUIで画像貼付けて手順書くより
打ち込んだソースを解説する方が楽なんだよね・・

260 ：デフォルトの名無しさん：2010/03/24(水) 00:59:17

GUIが難しいのは、どういうタイミングと順番で実行されるか分からない
コード片（イベントハンドラ）がたくさんあって、
それらがどう呼び出されようとも正しく動作するように条件分岐やらフラグ
やらを管理しなきゃいけないからじゃないかな

261 ：デフォルトの名無しさん：2010/03/24(水) 10:34:35

せっかくのGUIなのに画面遷移=プログラムフローになっちゃってるソフトは使いにくい

262 ：デフォルトの名無しさん：2010/03/25(木) 22:57:32

コンソールこそ我らが故郷
そのまま突き進め

263 ：デフォルトの名無しさん：2010/03/26(金) 02:20:48

コソンール

264 ：デフォルトの名無しさん：2010/03/26(金) 07:09:34

GUIでまじで躓いたわ
あの情報量の多さは異常だろ
何が必要で必要でないかの判断がつかなかったからマジでつらかった

265 ：デフォルトの名無しさん：2010/03/26(金) 11:46:22

Win32APIでGUIを作るなら、センスがない限りある程度パターンとして覚えるぐらいでないとつらいと思う。

266 ：デフォルトの名無しさん：2010/03/26(金) 12:10:49

GUIの目的の大部分は「普通のUI」を作ることだよな
普通じゃなくて良いならGUIなくても構わないことが多い
何が普通で何が普通でないかを判断するところが、GUIの難しさだ

267 ：デフォルトの名無しさん：2010/03/26(金) 14:25:31

結局C++Builderから離れられん(´･ω･`)

268 ：デフォルトの名無しさん：2010/03/26(金) 14:33:53

ＶＳ２００８のMFCアプリだど、ウィザードで超ｶｯｺｲｲGUIを作ってくれるぞ
むずかしすぎって・・・

269 ：デフォルトの名無しさん：2010/03/27(土) 01:36:51

VS2008でリボンとかついたから
試してみたけど超うんこだったわ

270 ：デフォルトの名無しさん：2010/03/27(土) 01:47:57

VSとQt両方使ってる人が比較するとどういうところが良し悪しなんだろう？
単純に全体として良し悪しではないと思うんで宗教戦争にする気は無いんだけど

VSの方がドキュメントは多い，Qtはマルチプラットフォームというのは俺でもわかるが

271 ：デフォルトの名無しさん：2010/03/27(土) 08:54:38

Qt は Multiligualization でも力を発揮する

272 ：デフォルトの名無しさん：2010/03/27(土) 18:45:13

内はいまだにMFCから離れられん

273 ：デフォルトの名無しさん：2010/03/27(土) 22:12:45

(´・ω・)ｶﾜｲｿｽ

274 ：デフォルトの名無しさん：2010/03/28(日) 12:31:28

色々あり杉て難しいです(´；ω；｀)

275 ：デフォルトの名無しさん：2010/03/30(火) 16:28:52

いっそのこと、HTMLとJavaScriptだけでUI作ったら？
Dijitとか、jQuery UIなんか使えばそこそこ高度なものが作れる。

276 ：デフォルトの名無しさん：2010/03/30(火) 20:37:06

つ ttp://ExtJS.com
つ ttp://SmartClient.com

277 ：デフォルトの名無しさん：2010/04/01(木) 21:22:32

すいません、初歩的なことなんですが、GUIってグイですか？ジーユーアイですか？
わたしわグイって言って単ですけど、先輩がジーユーアイって言い出して
顔から火がでるほどはずかしかったので教えてください÷

278 ：デフォルトの名無しさん：2010/04/01(木) 21:25:44

さて、グイ派とジーユーアイ派の一悶着が済むまで見守るとするか

279 ：デフォルトの名無しさん：2010/04/01(木) 21:33:12

通じればOK
通じなければ通じるように言いましょう。

280 ：デフォルトの名無しさん：2010/04/01(木) 21:36:36

Dr. GUY

281 ：デフォルトの名無しさん：2010/04/01(木) 22:08:16

まあ、普通はジーユーアイだろうけど、グイと呼ぶ人もいるからいいんじゃね。
http://ja.wikipedia.org/wiki/GUI
と思ったが、
http://eow.alc.co.jp/GUI/UTF-8/
こっちではグイと発音する、ってなってるな。
もしかすると英語圏ではグイのほうが普通なのかも。

似たような言葉で、
http://ja.wikipedia.org/wiki/GNU
ってのがあるが、これをジーエヌユーと言うとちょっと恥かしいかもしれない。

282 ：デフォルトの名無しさん：2010/04/01(木) 22:08:56

おれはグーイだな

283 ：デフォルトの名無しさん：2010/04/01(木) 22:11:32

じゃあオレはギュイ

284 ：デフォルトの名無しさん：2010/04/01(木) 22:34:44

じゃあギニュー(特戦隊)で

285 ：デフォルトの名無しさん：2010/04/02(金) 05:11:04

G.U.I!

286 ：デフォルトの名無しさん：2010/04/02(金) 21:44:36

ギュイ

287 ：デフォルトの名無しさん：2010/04/03(土) 00:56:57

牛慰

288 ：デフォルトの名無しさん：2010/04/04(日) 13:20:11

GUI ←グイ
CUI ←クイ
YUI ←どれもおんなじ歌ばっか　しかもヘタクソ

289 ：デフォルトの名無しさん：2010/04/04(日) 17:20:51

>>288
どUI

290 ：デフォルトの名無しさん：2010/04/10(土) 23:41:25

基礎が終ってやっとグイに進んだけどむずかしすぎる。。。

291 ：デフォルトの名無しさん：2010/04/11(日) 01:17:44

>>34
はげどう

292 ：デフォルトの名無しさん：2010/04/11(日) 17:37:06

GUIの難しさって、CUIと違ってデフォルトがないってだけじゃないの?

293 ：デフォルトの名無しさん：2010/04/11(日) 18:36:09

なにがむずかしいの？
まさかとは思うけど、C+WIN32APIのみ作ってるの？

妥協して、MFCなりATLなりWTLでも使え
これなら、むずかしすぎるってことはない

さらに妥協できるなら、.NETでも使え
これなら、サルでもつかえるよ

294 ：デフォルトの名無しさん：2010/04/11(日) 18:49:07

デフォルトでどの程度妥協すべきか、判断できないな

295 ：デフォルトの名無しさん：2010/04/12(月) 00:30:04

GUI作るのが簡単とか思っているのはまだ初心者

296 ：デフォルトの名無しさん：2010/04/12(月) 01:40:19

ＧＵＩは簡単だろ？

ソフトウェア設計の大半はデータ構造とアルゴリズムだぞ
GUIなんてドカタに任せておけばオｋ

297 ：デフォルトの名無しさん：2010/04/12(月) 01:50:02

データ構造とアルゴリズムは多少大規模でも気にならないが、GUI は目が回る。

298 ：デフォルトの名無しさん：2010/04/12(月) 03:06:59

確かにGUIだとテストやデバッグが大変

299 ：デフォルトの名無しさん：2010/04/12(月) 03:19:28

難しい簡単という尺度よりも
面倒くさいとか楽だとかしんどいという尺度の方がしっくりくる感じ

300 ：デフォルトの名無しさん：2010/04/12(月) 03:21:40

だれかが言ってたけど
CUIに比べて処理の流れが
組み合わせになるから
無限に拡散してしまう

301 ：デフォルトの名無しさん：2010/04/12(月) 11:50:34

普段Javaで業務用アプリ書いてるから、GUIが面倒とか思うことはないけど、
最初CでWindowsアプリ書いた時は（3.1～95）確かにメンデーと思った。
あ、MFCは初対面のときからソリの合わないものを感じてC++Builderに避難しました。

302 ：デフォルトの名無しさん：2010/04/12(月) 13:45:38

OWLってまだ使ってる人いるの？

303 ：デフォルトの名無しさん：2010/04/12(月) 20:18:21

GUIの難しさは、他の人間相手に使いやすさを考えることだろ。

304 ：デフォルトの名無しさん：2010/04/12(月) 22:53:16

GUIって言ってもどこまで完成度求めるかじゃないの？
取りあえず機能的には Ok というのならマウスの位置掴んだり
ボタンとかボックスたくさんつくったりとかそんな大変じゃない
拘りだしたり動かしだすと自由度も大きいしキリが無い
事前にしっかりレイアウト決まってるならそんなに大変じゃないと思う

305 ：デフォルトの名無しさん：2010/04/13(火) 01:16:00

問題を二つに分けて考える必要があるね

一つはインターフェイスデザインという意味での難しさ
Webの画面もGUIの一種と考えれば、インターフェイスデザインがアプリケーションにおいて
どれほど重要でありながらも難しいものかが分かるでしょう

二つ目は開発者の視点から見た作成の難しさ
GUIコンポーネントをベタペタ張ればお終いと思っているのは役たたずのマネージャー
非同期通信(例えばDB問い合わせとかCGIアクセスとか)との連携、
可変なウィンドウサイズと動的なレイアウトとの戦い、
複雑なイベントチェーンの管理等々

306 ：(u＿・y) ◆e6.oHu1j.o ：2010/04/13(火) 08:40:37

GUIはCUIの10倍位は難しいだろ
今後も、さらに難しさレベルは増えていく可能性がある
いまはまだ、2Dの無機質なソフトが多いけど
そのうちフェードとか、自作メニューバーとか、３Ｄ化してるアプリが当たり前になってきたら
敷居あがりまくりなんだけど

307 ：デフォルトの名無しさん：2010/04/13(火) 18:24:12

マルチタッチとか考えなきゃいけなくなると、もうやだ

308 ：デフォルトの名無しさん：2010/04/13(火) 22:31:39

マルチタッチは低レベルなポイントなどにアクセスしなくても、
たいていはもっと高レベルなジェスチャーにアクセスする程度で十分だから、
それほど難儀しないと思う。

309 ：デフォルトの名無しさん：2010/04/22(木) 08:58:33

スラッシュドットより。まあ大学の情報工学科でこうだからなあ…

http://slashdot.jp/hardware/comments.pl?sid=492519&cid=1752368
>某大学の情報工学科でプログラミングを教えていますが、今でも演習はCLIベースです。
>演習室には最新のMacが並んでいますが、演習自体はターミナルとEmacsで行います。:-)

>GUIよりもまずは基本的な原理をわかってほしいということもありますが、私を含めた
>多くの教員がGUIを使った開発経験に乏しいのも確かですね。最近の学生にとっては
>CLIベースのソフトウェアは半完成品のような印象を与えるみたいで、いまひとつ演習に
>身が入らない人がそれなりにいるのは確かなので、今後のカリキュラムは何とかせねば
>とは思っています。

310 ：デフォルトの名無しさん：2010/04/22(木) 09:28:55

そんな馬鹿に迎合した授業しても仕方ないのになぁ

311 ：デフォルトの名無しさん：2010/04/22(木) 11:32:20

すごい残念な大学だな
高い授業料払っているのに

312 ：デフォルトの名無しさん：2010/04/22(木) 11:58:23

「半完成品のような印象」とか "Worse is Better" とか
パラドクスが日常茶飯事だという事をまず最初に教えるべきだ

313 ：デフォルトの名無しさん：2010/04/22(木) 14:26:31

GUIといっても色々あるけどな

「GUIを使った」開発（大抵IDEの事）→初めからIDEばかりで教えるべき
かには疑問が残る

「GUI付きのソフト」を開発→プログラミングならばまずCLIで開発できて
それからGUI付きの開発に行くべき
（GUIきれいでも中身書けないじゃ話にならん）

情報工学科でGUI含めた開発まで行き着けないというのならそれは寂しいが

314 ：デフォルトの名無しさん：2010/04/22(木) 20:36:49

>演習室には最新のMacが並んでいますが、演習自体はターミナルとEmacsで行います。:-)

うちと似てるな。うちはターミナルだけじゃなくてEclipseを使った演習もやるけど。

プログラミングの講義はそれなりに揃ってるけど、GUIプログラミングをシステマティックに
教えている科目はないんじゃないかな。そもそもGUIプログラミング自体一過性の技術なので
（プログラミング関連で一過性じゃないものって何？って言われそうだけど、相対的にみた
場合）、どうしても教える内容としての優先度は低くなるんだよね。

315 ：デフォルトの名無しさん：2010/04/22(木) 22:08:07

おまえが生きているうちは無くならないから

316 ：デフォルトの名無しさん：2010/04/22(木) 23:37:59

やらない理由が教える側が出来ないからというのが情けない

317 ：デフォルトの名無しさん：2010/04/23(金) 00:27:00

しかもコメントの書き方ではIDEとGUI付きのアプリの違いを意識しているか危ないし…
IDEでCLIのアプリを作ることも，EmacsみたいなCUIでGUIアプリ作ることも十分可能なんだが

318 ：デフォルトの名無しさん：2010/04/23(金) 00:57:40

この藪蛇な流れを見るとやはりGUIには手を出さないのが賢いと思える

319 ：デフォルトの名無しさん：2010/04/23(金) 03:14:38

４年間もあるのにGUIやらんのか

320 ：デフォルトの名無しさん：2010/04/23(金) 07:48:18

俺が出た学科は半分以上が数学や理論の講義だった。λ計算とか。
プログラミングも実践より理論という感じの講義が多かったな。
まあでもアルゴリズムやその解析をみっちり勉強できたのはよかったかも。

321 ：デフォルトの名無しさん：2010/04/24(土) 01:33:06

GUIの作り方なんて上っ面を大学で教える必要はないわな
情報の学生さんはλ計算や計算可能性の話や圏論なんかを勉強してきてください

322 ：デフォルトの名無しさん：2010/04/24(土) 13:52:38

まぁ大学出たらそんなもの勉強する時間まず無いからね

323 ：デフォルトの名無しさん：2010/04/24(土) 16:36:23

基礎できてる人はGUIのAPI程度、本一冊斜め読みして
ちょっとしたGUIアプリぐらい数日でつくるよ
研究室でもできるやつはできるでしょ

そういう人が居ない場所だと
レベルの低さを認識できないかもね
基礎ができてればGUIの習得ごときで長時間費やすものじゃないのに

324 ：デフォルトの名無しさん：2010/04/24(土) 18:03:01

ここってそういうスレだったっけか

325 ：デフォルトの名無しさん：2010/04/25(日) 01:09:09

確かに。

GUIの何が難しいのか、俺にはさっぱりわからん。

326 ：デフォルトの名無しさん：2010/04/25(日) 04:26:53

ちょっとしたやつじゃなくて
本格的なのやれよ

327 ：デフォルトの名無しさん：2010/04/25(日) 08:12:22

カーナビとか

328 ：デフォルトの名無しさん：2010/04/25(日) 18:50:37

>>326
どういったものが本格的かどうかわからんが、面倒なだけだろ
すくなくとも難しくはない

329 ：デフォルトの名無しさん：2010/04/26(月) 01:22:36

>>328
横レスですが、難しいです
通常、イベントハンドラが長時間の処理に陥ってしまうと画面諸共応答がなくなるために、
そのような処理は完了イベントを挙げるような非同期な仕組みに変更しておく必要があります
（例えば、初期化やDB検索やネットワーク通信など)
ところが、このような複数のイベントループを持つ一連の処理を正しく行うためには
別の全てのイベントとの整合性を担保しなければならなり、これが大変複雑になります
パズルと一緒で、依存関係が多くなると"面倒"が"難しい"に変わります

330 ：デフォルトの名無しさん：2010/04/26(月) 05:43:28

ちょっとしたGUIくらいすぐ作れるとか言う奴は
ちょっとしたGUIしか作れない

331 ：デフォルトの名無しさん：2010/04/26(月) 09:35:50

>328
株式チャートとか、ビジオみたいの作ってみなはれ。

332 ：デフォルトの名無しさん：2010/04/26(月) 09:38:34

GUIなんて私の仕事じゃないと言い続けている私は、
実はGUIはちょっとしたものしか作れない。
つーか、UI何それ、そんな律速要因要らないよ。ってのが私の領分。

333 ：デフォルトの名無しさん：2010/04/26(月) 12:33:09

よくそんなしょうもないこと書きに来たな

334 ：デフォルトの名無しさん：2010/04/26(月) 12:43:31

>>329
パズルはパズルでも論理パズルだから、
やはり難しというよりは面倒の方が近いと思うが。

そりゃ、根気がなかったり、仕事のスケジュール配分にミスがあれば、
時間がないんでぱっと解決するアイデアに頼ろうとして難しいだろうけど。

335 ：デフォルトの名無しさん：2010/04/26(月) 20:42:09

システムのインフラを作ってるような人から見れば、くだらなくてただ面倒な
だけのものに見えるかもしれないけど、難しいし、凝ればいくらでも凝ること
ができる、奥の深い分野だと思うよ。

336 ：デフォルトの名無しさん：2010/04/26(月) 20:57:29

>>335
> 凝ればいくらでも凝ることができる、奥の深い分野

それには激しく同感。
ユーザーインターフェースのデザイン関係の本を読んでみるとよく分かる。

ただ、「難しいし」これが分からん。
それは単に、それを実現するための知識が不足しているからではないのか。
もっと身にあった対象から順にじっくりと少しずつ知識と経験を積んでいけば、
特に難しいしと感じる所はほとんど無いと思うが。
気が競って本当は踏むべきステップを飛び越そうとしたとか、
飛び越さざるを得なかったとか、そんなんじゃないのか？

337 ：デフォルトの名無しさん：2010/04/26(月) 22:31:40

>もっと身にあった対象から順にじっくりと少しずつ知識と経験を積んでいけば、
>特に難しいしと感じる所はほとんど無いと思うが。
逆にどういう時に難しいのか聞きたい

338 ：デフォルトの名無しさん：2010/04/26(月) 23:03:36

限られた時間内に知識を得るのが難しいんだな
もし時間が無限にあれば、難しいものなんて殆ど無くなるだろう

339 ：デフォルトの名無しさん：2010/04/26(月) 23:16:38

SEXの欲求を抑えるのは時間があればあるほど難しくなる

340 ：デフォルトの名無しさん：2010/04/26(月) 23:58:23

簡単に諦められたら、それは「難しかった」とは言えない
GUIには、諦めたくないと思わせる何かがある

341 ：デフォルトの名無しさん：2010/04/27(火) 01:32:30

>限られた時間内に知識を得るのが難しいんだな
>もし時間が無限にあれば、難しいものなんて殆ど無くなるだろう
つまり、無限に時間があればGUIは難しくないだろう、と
じゃぁ、有限の時間を生きている私達にとってGUIは難しい？それとも難しくない？

342 ：デフォルトの名無しさん：2010/04/27(火) 07:25:35

>>337
おそらくこういう知識がまだ足りないと分かっても、
その知識をステップバイステップで学べる環境にない時に
（参考図書などが見つからなかったり）、
資料探しを諦めて自分で解決しようとすると難しく感じる。

それ以外は、特に難しくない。

時間だって、無限の時間とかなんでそんな大げさに考えるのか不思議だ。
納期が迫っているとか以外なら、じっくり学ぶ時間なんて
ちゃんとやりくりして捻出できるだろ。

343 ：デフォルトの名無しさん：2010/04/27(火) 08:17:46

>資料探しを諦めて自分で解決しようとすると難しく感じる。
自分で解決しようとして、例えばどんな問題が難しく感じました？
GUIを如何に簡潔にプログラミングするかは難しい問題ではないですか？
ちなみに世界中どこを探しても答えが載っている参考図書はないと思います
（あるならぜひ教えてほしい）

344 ：デフォルトの名無しさん：2010/04/27(火) 12:53:02

>>343
>自分で解決しようとして、例えばどんな問題が難しく感じました？
Yampa を活用した GUI ライブラリの仕組みを早く理解したくて、
ライブラリ内を色々巡った時はなかなか理解できず、相当難解だった。
ACM に FRP の論文が大量にある事が分かって一からじっくり勉強してみると、
次第に理解できてきた。

> GUIを如何に簡潔にプログラミングするかは難しい問題ではないですか？
難しいと感じるのは、きっと「簡潔とは何か」をしっかり定義しないまま、
闇雲に簡潔にしようとしているからだろう。
そのソースコードが以前に比べてどのような状態になったら簡潔になったと満足するのか、
ちゃんと自分の頭に中に思い描けるのなら、
そのために不足している知識を得て実験を繰り返すだけだろ。

>ちなみに世界中どこを探しても答えが載っている参考図書はないと思います
何を当たり前のことを言っているのだ？
「答え」そのものはさすがに無いだろ、問題なんて千差万別なんだから。
でも問題を抽象化したり、別の問題との関連を考えれば、
ヒントとなるものは世の中にかなり大量に存在していると思うぞ。

345 ：デフォルトの名無しさん：2010/04/27(火) 20:03:38

なんかズレてるな
いろいろと…

346 ：デフォルトの名無しさん：2010/04/27(火) 20:57:42

>>344
とても頭脳明晰な人みたいなのでもういいです
GUIは難しくない、面倒なだけ
それでいいです、すみませんでした

347 ：デフォルトの名無しさん：2010/04/28(水) 21:04:36

その態度が面倒臭がり

348 ：デフォルトの名無しさん：2010/04/28(水) 23:03:38

なんだよ、FRPとか論文もしっかり読んでる人だからつまんない話は終わりにしようと思ったのに、なんだよ
だいだいあなたはGUIが難しいかどうかについて具体的に何も触れなかった
同じ時間で同じようにステップバイステップで問題に挑戦したとして、
他の問題に比べてGUIが特徴的にどのように難しいのか（もしくは難しくないのか）を議論したかったのに、
一足飛びにやろうとしてるだの目標を決めてないだのなんだのメタな話ばかり
できればGUIを記述する際に問題となる具体的な話をしてくれ

349 ：デフォルトの名無しさん：2010/04/28(水) 23:11:06

>>329が具体的に書いてるじゃん
要するに非同期プログラミングの難しさであると

350 ：348：2010/04/28(水) 23:26:49

>>329は私が指摘した難しさ
329をもってしても"面倒なだけ"という主張だったので
非同期な複雑さを整理する方法や対案が議論されるかもしれないと期待して
質問してたりしてたのっ
FRPとかでもいいので、もしGUIに思う所があれば参考になるので言ってください

351 ：デフォルトの名無しさん：2010/04/28(水) 23:48:20

そりゃすまんかったｗ
俺は今初めてこのスレちょっと見ただけだから

352 ：348：2010/04/29(木) 00:34:05

>>351
人違いスマソ

353 ：デフォルトの名無しさん：2010/04/29(木) 00:56:26

>>329
まず、「イベントループ」という言葉は具体的に何を指しているのか、
何故「それが複数必要なのか」を説明できるか？

そして、「面倒が難しいに変わる」という場合の「難しい」というのは、
理解するのが困難であるという意味の難しいなのか、
それとも現実的な時間で解決に導くことが不可能に近くなるという意味の難しいなのか。

>>344 で先に挙げられた質問に答えているように、
私は理解するのが困難であるという意味の難しいと解釈して発言している。

354 ：348：2010/04/29(木) 01:45:48

>まず、「イベントループ」という言葉は具体的に何を指しているのか、
>何故「それが複数必要なのか」を説明できるか？
うん？その説明によって何が知りたいのか分からない
とりあえず応えるけど、
イベントループはユーザーの操作やウィンドウからのイベント処理を一手に扱っているループのこと
複数必要って言うのは、
一連の処理が長時間に渡る場合に一回のループでその処理をしてしまうと
画面が固まったり他のイベント処理が進まなくなるので、
一連の処理を複数回のループに分ける必要があるという意味

>そして、「面倒が難しいに変わる」という場合の「難しい」というのは、
>理解するのが困難であるという意味の難しいなのか、
>それとも現実的な時間で解決に導くことが不可能に近くなるという意味の難しいなのか。
少なくとも後者ではないわな
「面倒が難しいに変わる」を補足すると、
規模が小さければ頭を使わなくてただ単に手を動かせば済むことだったのに、
複雑さが増えてくると、
あーだこーだと考え込まなきゃいけない状況になって間違いが増えるので、これを"難しい"と言っている
そういう意味ではFRPライブラリを理解するのが難しいという時の難しいとは違う
"複雑(ふくざつ)しい"とでも言えばよかったかな(そんな日本語ないけど)

あと、もう難しい云々の言葉の定義と議論はやめにしないか
つまらないと思う
それよりも何が簡潔かとか、どうすれば簡潔かを議論したい

355 ：デフォルトの名無しさん：2010/04/29(木) 01:55:44

>>354
イベントループ複数って、いわゆるDoEventsの類？
GUIイベントループが意味もなく複数あるなら、それはあまりいい設計じゃないな……
スレッド、コルーチン、継続のようなものを利用したほうがいい
時間がかかる仕事は裏スレッドでやればいいだけだろう

勿論、非同期I/Oなどの目的で、非GUIのイベントループが別途必要になることは
普通に有り得るけどな

356 ：348：2010/04/29(木) 02:32:35

いい感じに具体的になってきた
>>355
誤解させているようだけど、
基本的にGUIイベントループは一"本"
GUIイベントループが複数"本"走っているんじゃなくて、
例えばDB検索して表示するという一連の処理に複数"回"のループが必要という意味ね
その一連の処理の間に別のイベントが処理されるから、IDLE状態とは異なるハンドリングが
必要になる
DB処理中もフォーカスカーソルは動かしたいけどリターンキーは効かないようにとか言う仕様とか泣きたくなる

357 ：デフォルトの名無しさん：2010/04/29(木) 02:37:38

>>356
意味は分かったが、言っちゃ悪いが説明が悪かったな

要は気持ちとしては一連である処理の流れが、実装の上で断続的になる
といいたいんだろ？
それ自体は非同期プログラミングでのごく基本的な問題だな
さっきも言ったがコルーチンとか使えると一連の流れのコードとして書けるので
楽になる場合がある

あんたの言うように、複数の状態管理／制御が絡む場合は面倒くさいことになるな

358 ：348：2010/04/29(木) 08:02:33

"複数持って"がいかんかったね
ありがという
>>357
コルーチンいいね

359 ：デフォルトの名無しさん：2010/04/29(木) 09:56:08

女と合法的にセックスする難しさに比べたら
>>353 の言うGUIの分かりにくさは難しさの内に入らない

360 ：デフォルトの名無しさん：2010/04/29(木) 12:35:26

>>356
DB検索して表示するという「一連の処理」に複数回のループが必要になるのは何故？
もしかして、「DB検索する」という処理と「表示」という処理を
一括りに処理しようとしていないか？
処理の単位を２つ分けて、スレッドなりでそれぞれ処理すれば良くないか？

この場合、DB検索する処理は普通は一回のループで可能だろ。
（繰り返し回ることがないからループという言い方がそもそも当てはまらないが）
DB内を検索し、目的のデータを集め、それらを表示更新すべきデータリストに登録する。
この処理の単位なら、SQL を投げて結果を処理するだけだから、
繰り返す必要が無く一回のループで可能なはずだ。
最後に、表示更新すべきデータリストの内容が変更されたことをイベントで通知する。
最後でなくても、複数データを適当な塊に分けて入力するたびに通知しても良い。
また、表示更新すべきデータリストでなくても、要は表示処理を担当している処理単位が、
何が更新されたのかが分かればいい。

表示処理の方は、表示更新すべきデータリストの内容が変更されたイベントを拾い、
今画面に見せている部分に変更があれば、画面を更新すればいい。

DB検索の開始と終了のそれぞれに、また別のイベントを投げるようにすれば、
ユーザー入力処理を担っている処理単位の方は、
「DB処理中もフォーカスカーソルは動かしたいけどリターンキーは効かないように」
という仕様も容易に実装できる。
（念のために言っておくが、スレッドなどを使って分けておく必要がある）

361 ：デフォルトの名無しさん：2010/04/29(木) 14:03:31

一回のループって結局何回回るんだ

362 ：デフォルトの名無しさん：2010/04/29(木) 14:06:41

do{一回のループ}while(0);

363 ：デフォルトの名無しさん：2010/04/29(木) 14:22:18

>>361
言葉尻捕まえるくらいしか、突っ込めないのかｗ

364 ：デフォルトの名無しさん：2010/04/29(木) 20:55:07

>>360
>この場合、DB検索する処理は普通は一回のループで可能だろ。
>（繰り返し回ることがないからループという言い方がそもそも当てはまらないが）
"ループ"ってイベントループの事なんだけど...伝わらなかったようです

>DB検索の開始と終了のそれぞれに、また別のイベントを投げるようにすれば、
ちなみに、"一連の処理"をGUIと共に実装する方法としては、この方針で
おおよそ問題ないと思います

ただ、DB検索をバックグラウンド処理に移して完了通知をイベントにした瞬間、
"DB検索中"という状態が増えた事に注意してね
全てのイベントハンドラについて、その状態を加味して書くようにしないと、
DB検索完了時として想定していなかった変な状態に遷移してしまっている場合が出てきてしまう

ちなみに、DB検索が失敗したら検索中フラグを適切に落とさないと、
今度はDB検索中状態が延々と続くことになってしまう

DBだけならまだしも、ネットワーク通信、ドラッグアンドドロップなど、
複数イベントループが必要な処理は沢山ある
全てのイベントハンドラについて、
それらの組合せを全て考慮して記述することが容易とはとても思えない
少なくともすぐ間違えるはず

365 ：デフォルトの名無しさん：2010/04/29(木) 23:16:21

>>364
> それらの組合せを全て考慮して記述することが容易とはとても思えない

それらは本当に「組み合う」のか？
全てのイベントハンドラの中で依存関係のある、
つまり組み合わせを考慮しなければならない組はどれくらいある？

どのようなイベントハンドラとどのようなイベントハンドラの
どのような組合せをどのように考慮しなければならないのか、
具体例を出して説明できるか？

そして、それらの組み合わされる処理の何を記述するのが大変なのだ？
それはプログラマが全てを事細かく記述するのではなく、
大まかな関係を引数で与えたら自動的にイベントを裁いてくれるような
仕組み（関数やクラスやモジュールなど）を作る方が比較的楽なのではないか？
それができれば、すぐ間違える事は少なくなると思うが。

366 ：デフォルトの名無しさん：2010/04/30(金) 07:20:38

>それらは本当に「組み合う」のか？
本質的には全て組み合う
なんらかの前提条件が満たされている場合、かつその前提条件がバグによって壊されない場合のみ、
組合せを省略して書いてもよい

367 ：デフォルトの名無しさん：2010/04/30(金) 11:38:56

こんだけ長文が続くんだから
間違いなくGUIがむずかしすぎるのだ

368 ：デフォルトの名無しさん：2010/04/30(金) 12:33:05

>>366
例えばどんな前提条件が満たされてる時に組合せを省略して書けるの？

369 ：デフォルトの名無しさん：2010/04/30(金) 20:37:37

>大まかな関係を引数で与えたら自動的にイベントを裁いてくれるような
>仕組み（関数やクラスやモジュールなど）を作る方が比較的楽なのではないか？
>それができれば、すぐ間違える事は少なくなると思うが。
イベントの条件判定部分だけ切り出してプログラミングできるのが、
まさに"FRPのevent"でしょ？
そういう意味では、FRP使えでFAなんじゃなかろうか

370 ：デフォルトの名無しさん：2010/04/30(金) 20:41:48

>>368
例えば、
ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更しておけば、
そのGUIコントロールが通信中にイベントを受け取ることはあり得ないので、
disableにしたコントロールのイベントハンドラについては、
ネットワーク通信中かどうかを判定するロジックは省略できる

ただしdisableにし忘れるとアウト

371 ：デフォルトの名無しさん：2010/04/30(金) 21:02:08

>>370
>ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更しておけば、

そうしたら通信先が死んでたりするとタイムアウトするまでGUIは無反応にならない？

372 ：デフォルトの名無しさん：2010/04/30(金) 21:09:20

>>370
ネットワーク通信に入る直前にGUIコントロールを全部disable状態に変更するのと、
ネットワーク通信に入る直前にGUIコントロールを全部
「ネットワーク通信中にされると都合が悪いユーザー操作を無視する」状態に変更するのと、
なにか根本的に違うのか？

まさか、無視する処理が難しいとか言わんだろうな

373 ：デフォルトの名無しさん：2010/04/30(金) 22:28:33

（GUIコントロールをdisableにするなどして）ユーザー操作を無視して良いのなら
組み合わせを省略できる（=難しくない）ってことじゃないの？

374 ：370：2010/04/30(金) 23:40:15

>>373
そうです
あくまで組み合せを省略できる一例を示しただけで、
別にdisableにする事を推奨している訳ではないです

逆にdisableにするとGUIが無反応になったり色々嬉しくないので、
むしろそういう安易な対策は好ましくなく、
イベントハンドラできちんと状態を考慮する必要があると皆認識していると分かりました

375 ：デフォルトの名無しさん：2010/05/01(土) 01:54:21

つか、GUIなんてどうでもよくね？

376 ：デフォルトの名無しさん：2010/05/01(土) 04:25:53

でも最近のgnomeでもgconf-editorとかないと
設定死ぬほど面倒だよ
というか不可能だよ

377 ：デフォルトの名無しさん：2010/05/01(土) 09:01:55

コメントを書かないと保守が不可能だよっていう議論に似てる
本体のコードが変更されると、周辺のコメントとかGUIはすぐ古くなって問題を起こす

378 ：デフォルトの名無しさん：2010/05/01(土) 13:54:27

>>374
だかさら、
> 「ネットワーク通信中にされると都合が悪いユーザー操作を無視する」状態に変更するのと、
> なにか根本的に違うのか
という質問に答えてないだろ？

もし同じであれば、
あなたの言う「GUIが無反応になったり色々嬉しくない」状態は回避しつつ、
あなたの言う「安易な対策」で解決できそうではないかと言いたい。

根本的に違うのであれば、どのように違うのかを示して欲しい。
わたしは本質的に同じと思っているから。
（どちらもトリガによって状態を変更し、状態に合わせて処理を分岐する）

> イベントハンドラできちんと状態を考慮する必要がある

なにやら、きちんと状態を考慮するのが難しいと言っているように聞こえる。
設計時にちゃんと必要な状態やトリガを洗いざらいリストアップしているか？
リストアップしたものの中で関連性が高いもの、依存しているもの、
一連の処理として分割できないもの、できるもの、ちゃんと仕分けしているか？
それぞれの状態遷移図や状態遷移表などを「大きな紙」に描いたりしているか？

379 ：デフォルトの名無しさん：2010/05/01(土) 14:47:57

学者が研究するような難しさと、現場で感じる難しさが、根本的に食い違ってる

380 ：デフォルトの名無しさん：2010/05/01(土) 16:00:33

>設計時にちゃんと必要な状態やトリガを洗いざらいリストアップしているか？
>リストアップしたものの中で関連性が高いもの、依存しているもの、
>一連の処理として分割できないもの、できるもの、ちゃんと仕分けしているか？
>それぞれの状態遷移図や状態遷移表などを「大きな紙」に描いたりしているか？
全てのボタンやメニューについて全部？
そんな事したことない
たぶんすぐ古くなってそれだけの労力が報われないと思う

そのコストを受け入れるより、
プログラムの作り方でなんとかならないのかなー？

381 ：デフォルトの名無しさん：2010/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 ：デフォルトの名無しさん：2010/05/01(土) 17:37:20

ボタンには当然、それが押された時のアクションを定義するだろう。
アクションには、他のボタンの有効/無効や状態も切り替える事も含まれる。
君ならどうする？

383 ：デフォルトの名無しさん：2010/05/01(土) 17:57:37

>>380
>全てのボタンやメニューについて全部？

なんでボタンやメニューから考え始めようとするんだよ。

まず実現させたい機能が先だろ。
それを洗い出して、その機能を実現させるための処理の組み合わせを考え、
それらの組み合わせる処理が他の処理と排他的な関係にあるのか、
同時に起こってもいいものなのか、などの関係を洗い出して、
最後の最後にその機能を発動させるスイッチとして、
ボタンやメニューなどを考えるんだよ。

機能よりもスイッチの方が多くなるのだから、
先に昨日動詞の関係をまとめておけば、イベントのごちゃごちゃも、
先にボタンとかを考え始めてた時よりは設計が楽になる。

384 ：デフォルトの名無しさん：2010/05/01(土) 18:47:11

プログラミングの初学者がGUIに壁を感じることはあると思うぜ
既存のコンポーネントで完結するなら
それほど手間じゃないんだけどな
オレも昔MFCで苦労した事あったから
GUIは誰にでも出来て簡単だとは言わないよ

385 ：デフォルトの名無しさん：2010/05/01(土) 18:49:06

俺はGUIで上手くコードを抽象化するのが苦手

例えばディレクトリ以下のファイルをコピーするという単純な処理を
例に挙げると、
何も考えずにその手続き「だけ」を書くのは簡単だが、
GUIなら実際には進捗ダイアログを出したいだろう
というわけで、進捗ダイアログを出すことを前提にベタでコードを書くと、
それ「無し」のコードとは似ても似つかないものが出来上がる

スレッドを使える場合はまだシークエンシャルに手続きを書けるだろうから、
adviseやhookっぽい仕組みを使えば、両者で同じ部分を抽象化しやすい
かもしれない
が、GUI化することで本質的にイベントドリブンなコードになってしまう場合は
そうすることも難しくなる

気を抜くと、汎用性もへった暮れも無い、抽象度の低い、ベタなコードが
量産されてしまうことになる

386 ：デフォルトの名無しさん：2010/05/01(土) 19:31:56

>>383
「現場」は「紙芝居」をまず作るんだよ
察してやれよ

387 ：デフォルトの名無しさん：2010/05/01(土) 19:37:32

だな
そして、「現場」では仕様作成者とプログラマが別の人間だな
「仕様」とは「紙芝居」のことで
その段階で内部状態やその整合性、実装上の都合が考慮されていることは
まずないな
そしてプログラマは「どうあるべき」ではなく、「紙芝居に合わせる事」を
求められるわけだ

388 ：デフォルトの名無しさん：2010/05/01(土) 19:47:12

GUIの難しさは（開発側の）人間系にあったということか・・・

389 ：デフォルトの名無しさん：2010/05/01(土) 20:00:01

>>388
俺は>>385の理由で俺にとっては難しいけど
書き捨てコードは書きたくないが、書き捨てでないコードを書くのが難しい
だからGUIを書きたくない気持ちにさせられるんだと思う

390 ：デフォルトの名無しさん：2010/05/01(土) 20:50:00

>>385
> 進捗ダイアログ

これをちゃんとやるのは難しいよねえ。　

391 ：デフォルトの名無しさん：2010/05/01(土) 20:51:39

>>390
それはお前に知識が不足してるだけ、
別に難しくはない

392 ：デフォルトの名無しさん：2010/05/01(土) 21:26:13

>>387
それは GUI だからなのか・・・

393 ：デフォルトの名無しさん：2010/05/01(土) 21:31:55

>>391
「難しい」って、誰も計算機科学における難問であるとかいう意味で言ってねえから
その単語が気に食わないなら、「凡人には難しい」とか「面倒」と
言い換えてもいいと思うよ

進捗ダイアログは、時間の見積もり、進捗表示、キャンセル、
（場合によってはロールバック）、といった、処理の本質とは関係ない
仕事を発生させる
べた書きすれば可能だが、結構泥臭い話なので、
進捗ダイアログと、それとやりとりする本質的な処理を
美しく抽象化するのは俺には難しいな

394 ：デフォルトの名無しさん：2010/05/01(土) 22:01:23

「俺には難しいな」と言ったきり、そこで止まっているなら、
本当にただの凡人だけどね。

当然、文献を当たって調べたり、自分で考えたり、
実験を繰り返したり、質問したりして、抽象化の方法を勉強してるんでしょ。

なら、そのうちものに出来るよ

395 ：デフォルトの名無しさん：2010/05/01(土) 22:03:31

「難しい」=やりたくない
関わりたくない

396 ：デフォルトの名無しさん：2010/05/01(土) 22:05:29

>>394
いや俺は本当にただの凡人だよｗ
以前職業的なSEだったこともあるが、もう辞めた

今でも自分のためのコードを書くことはあるが、非本質的なコードや
書き捨てのコードを書きたくは無いから、そういう要素が多くなりがちな
GUIを書こうという気になることがそもそも滅多に無い
ゲームつくりが趣味なら良かったんだが

397 ：デフォルトの名無しさん：2010/05/01(土) 22:14:55

勉強したらできるようになるよ！
みたいな話はもういいよ・・・

398 ：デフォルトの名無しさん：2010/05/01(土) 22:52:59

>>397
勉強のコツが分かると、面白くなるんだけどな
俺は問題を分解して関連を図示するを理解したら、面白くなった
そりゃ、興味が薄れたり他のものに移ればやる気が無くなるのはしょーがないが

399 ：デフォルトの名無しさん：2010/05/01(土) 22:58:22

GUIが簡単とか言ってる人のGUIを見てみたいものだ

400 ：デフォルトの名無しさん：2010/05/01(土) 23:20:23

例えばプロセスを作るかスレッドを作るか決めたいとき、
どちらか選ぶためには、一方は簡単でもう一方は難しいと言えないと駄目だと思う。
どちらも簡単だと言ってしまうと、そこで止まってしまう。

401 ：デフォルトの名無しさん：2010/05/01(土) 23:28:38

スレをざっと流し読みしてみたが
CUI～GUIの間で悩んでる人っていなくね？
難しさ＝情報量というただの困難というつまらないものや
和算証明の類のひねりものだったり
それはGUI固有の問題ではないよね？という
あなたはUI以前の排他でも躓くというレベルの人であったり
話し込めば最終的には哲学・宗教になりそうな人

GUIが難しいというなら
GUI固有の問題を引き合いに出さねば説得力がまるでない

402 ：デフォルトの名無しさん：2010/05/01(土) 23:31:16

> GUI固有の問題を引き合いに出さねば説得力がまるでない
上で出てたんじゃないの？
イベントドリブン／非同期プログラミング特有の問題だとか
まあ非同期プログラミング全般がそうだから、GUI固有でもないけど

403 ：デフォルトの名無しさん：2010/05/01(土) 23:48:37

shellで走らせる類のコマンド引数受け取ってサッっと走って
すぐ終了するようなのに比べたら、そりゃ「相対的に」難しいってか面倒だと思うし
そんなの自明だと思うんだけど

・イベントドリブンなので、単純にトップダウン／シークエンシャルに書けない
・入力も多いし、出力も多い、単にprintf()じゃ済まない。要はやることが多い
・自分の都合で終われない。いつまで実行されてるか分からないので、リークが致命的

404 ：デフォルトの名無しさん：2010/05/01(土) 23:55:22

shellで走らせる類のコマンド引数受け取ってサッっと走って
すぐ終了するようなのをあらかじめいっぱい作っておいて
それをまとめる部分だけGUIにすれば良いと思うよ

405 ：デフォルトの名無しさん：2010/05/01(土) 23:58:55

>>403
難しいと面倒臭いはイコールとは思わないので2番目はスルー
1,3はGUI固有とは言えないサジ加減だよね

406 ：デフォルトの名無しさん：2010/05/02(日) 00:00:23

GUI固有ではないのは、抽象化したからだろ

407 ：デフォルトの名無しさん：2010/05/02(日) 00:06:41

イベントによる状態遷移だって、抽象化してしまえば
上向き構文解析でやってることと同じだから GUI 固有ではない

408 ：デフォルトの名無しさん：2010/05/02(日) 00:08:20

厳密な「GUI特有」に拘る意味が全く分からないんだが

409 ：デフォルトの名無しさん：2010/05/02(日) 00:19:26

上向き構文解析固有でもないしな
なにも話せないｗ

410 ：デフォルトの名無しさん：2010/05/02(日) 00:23:58

むしろGUIに特有でないものを含め、様々な概念・知識が一度に必要になるところに
難しさがあるように思う

411 ：デフォルトの名無しさん：2010/05/02(日) 00:29:56

>>406
おかしなローカルルールだな

>>408
スレタイがそれですから

>>407
>>409
それなのにここまで伸びるって不思議だよね
だから401で疑問を問いかけたんだ

412 ：デフォルトの名無しさん：2010/05/02(日) 00:46:54

>>411
「イベントによる状態遷移」の作法をGUIの話題として話すのはNG
なぜなら上向き構文解析でやってることと同じだから
おかしいだろこれ
GUIに引き寄せて語っても構わないんだよ

413 ：デフォルトの名無しさん：2010/05/02(日) 00:48:55

GUIが難しいか・・・
それって客の目に触れし、感じ方が人それぞれだから難しいと？
そうでないんなら、GUIなんて決まりきったことばっかじゃん

414 ：デフォルトの名無しさん：2010/05/02(日) 00:48:57

>>411
いやスレタイは単に「GUIがむずかしすぎる」と言っているだけだろ

Aに似た性質の難しさをBが持っているからといって
Aが難しいと言ってはいけないことにはならない
それこそ意味不明な主張だな

415 ：411：2010/05/02(日) 01:26:25

>>412
それは「何処」から引き寄せてくるのでしょ？
「CUI」と前提しますとCUIを舐めすぎじゃ？
1プロセス1スレッドばかりがCUIではありませんよ。
ちなみに
401=405=411≠407
察して欲しかったな。

>>413
俺もそう思う。
見栄えだったり操作性だったり描画性能だったりそんなとこだよね。
難しいとうか、際限のない鬱陶しさ。
もちろん、GUI特有の知識も必要だし
理解しなくては出来ない事も多々あるけど
排他で悩むってなんだよとｗ
それ以前の会話でしょとね。

>>414
包括関係にあるからその論理は成り立たん。

416 ：デフォルトの名無しさん：2010/05/02(日) 08:57:57

>排他で悩むってなんだよとｗ
排他で悩む機会がGUI以外に無かったんだろ

GUI特有ではないというのは綺麗事であって
現実にはGUI以外で排他で悩むような身近な例が無いんだよ

417 ：デフォルトの名無しさん：2010/05/02(日) 10:31:45

> 現実にはGUI以外で排他で悩むような身近な例が無いんだよ
そうでもないんじゃないの
CGIでおもちゃみたいなアクセスカウンター作るにしても排他は必要だし

まあGUIで多用されるオブザーバーパターン／コールバックみたいなのは
マルチスレッド初心者がデッドロックで嵌りやすい典型例ではあると思うけど

418 ：デフォルトの名無しさん：2010/05/02(日) 11:15:53

Observerパターンは separation of concerns 要はswitch文をバラバラにする仕組み
イベントハンドラに依存関係があったりする場合は
そもそもセパレートしたらダメじゃん

419 ：デフォルトの名無しさん：2010/05/02(日) 11:44:56

>>418
定石を知らないのが「初心者」なんでしょ

420 ：デフォルトの名無しさん：2010/05/02(日) 12:41:42

>>416
要するに、GUI の実装で悩んでるんなら、
GUI 以外の色々な分野に "も" 目を向けろってことだよな。
そうすればヒントになりそうなものは色々あるんだし。
視野の狭さが招いた「行き詰まり≒難しさ」なんでは

421 ：デフォルトの名無しさん：2010/05/02(日) 22:30:01

>>418
>Observerパターンは separation of concerns 要はswitch文をバラバラにする仕組み
>イベントハンドラに依存関係があったりする場合は
>そもそもセパレートしたらダメじゃん
でも、GUIコンポーネントが既にObserverパターンのlistener側を要求してくるので、
ライブラリを使う側としてはどうしようもないです

もしObserverパターンがだめなら、自前でGUIライブラリを作ると仮定して、
どういう設計がいいでしょうか？
なにかアイディアがあったら教えてほしいです

422 ：デフォルトの名無しさん：2010/05/02(日) 22:51:16

私がいつも疑問に思っているのは、
"現状のGUIのむずかしさ"は致し方ないのか？
それとも、もっと優れた作り方があって、多くのGUIライブラリがそれに気づけていないだけなのか？
という事
FRPみたいな新しいGUIの作り方が出てきてるけど、
実際に使ってみた人いますか？

423 ：デフォルトの名無しさん：2010/05/02(日) 23:23:11

優れた作り方ではないが
「問題が完全に把握できないときは、解決策も提供しないのが最善の方法である。」

Observerもオブジェクト指向も提供しない、余計なことはなにもしない
「小さな政府」がいいと思う

424 ：デフォルトの名無しさん：2010/05/02(日) 23:39:55

>>422
> もっと優れた作り方があって ...
> FRPみたいな新しいGUIの作り方が出てきてるけど、...

たぶん、ちょっと勘違いしてると思う。

[Reactive Programming]
簡単に言えば、a = 1 + b という式を定義しておけば、
変数 b を変化させた時に a も「自動的に」変化する、という仕組み。
たとえば、a を画面の背景色として、b をボタンとすると、
b の変化（ボタンが押された）に伴って a が変化（画面が赤くなる）する。

確かに宣言的に定義できるというメリットは大きいけど、
何と何を紐付けるか、紐付けた事による周りへの影響は、
ある事柄が紐付いた時に別の紐付けを解く必要があるか、
別の日も付けた事柄との間に時間軸上での依存性はあるか、
などはやはり人間が考慮しなくちゃならない。

イベント処理が難しいと感じてる人たちにとっては、
似たような悩みがつきまとうと思う。

425 ：デフォルトの名無しさん：2010/05/03(月) 00:30:42

GUI の難しさとして言われていることのほとんどは >>410 に集約すると思う。

426 ：デフォルトの名無しさん：2010/05/03(月) 09:47:33

今まで何年もJavaやってきて最近になってC/C++やりはじめたんだけど、
ようやくポインタとか仮想関数とかなんとなく理解でけた。
いよいよWindowsアプリを勉強しようと思うんだけど、GTK++たかQtとか
いろいろあるけど、どれやったらえんだろ？　おしえてちょ。ちなみに
あまり金もってない。　Qtって無料の開発環境あるんだろか？

427 ：デフォルトの名無しさん：2010/05/03(月) 10:41:28

>>426
とりあえず高級GUIライブラリを使わず Win32API でゴリゴリやっとけ。
メッセージループの回し方も知らないんではスタート地点にも立ってない。

猫でもわかるプログラミング（http://homepage2.nifty.com/c_lang/）
ここの [Windows SDK編第１部] と [Windows SDK編第２部] を
自分でプログラムしながらざっと追えばいい。
１ヶ月くらいでこなせるだろ。
そうすると、高級GUIライブラリや Java のライブラリが
内部で何をやっているのか、だいたい想像できるようになって、
勉強がはかどる。

428 ：デフォルトの名無しさん：2010/05/03(月) 10:47:18

>>427
激しく同意
同じこと書こうとしたら先を越されたｗ

429 ：デフォルトの名無しさん：2010/05/03(月) 11:18:42

>>427
うっしゃ！　おおきに。意味はよくわからんが、やるきになた。

430 ：デフォルトの名無しさん：2010/05/03(月) 12:54:02

>>426
何年もJAVAやってる奴が、C++で仮想関数をようやく理解できたっておかしくね？

JAVAで何をやってたんだｗ

431 ：デフォルトの名無しさん：2010/05/03(月) 14:12:01

目的が達成できれば問題ない

432 ：デフォルトの名無しさん：2010/05/03(月) 14:43:27

レスをもらうのが目的だったんですねわかります

433 ：デフォルトの名無しさん：2010/05/03(月) 15:30:20

JAVAはJDK1.0.2の頃から１０年以上やって、アプリやアプレットを
数えきれんぐらい作ったけど、
仮想関数なんて見た事も聞いた事もなかったよ。ポインタはうわさぐらいは
聞いたけど。

434 ：デフォルトの名無しさん：2010/05/03(月) 15:33:09

まあJavaじゃ継承すればポリモーフィックに動作するのが当たり前だから
仕方ないね

435 ：デフォルトの名無しさん：2010/05/03(月) 16:03:25

仮想関数なんて言葉はないかもしれんが、
C++の仮想関数をようやく理解できたってのは変だろ
CやBASICをやってた人なら話は別だが、JAVAをやってたら、
「仮想関数って言うんだ、フーン」程度で終わるだろ

436 ：デフォルトの名無しさん：2010/05/03(月) 16:10:39

JavaでAbstractClass作ったことないのか？

437 ：デフォルトの名無しさん：2010/05/03(月) 16:11:32

C++には仮想関数と純粋仮想関数があることを知らない人は多い

438 ：デフォルトの名無しさん：2010/05/03(月) 16:27:58

JAVA10年だが、コンパリルエラーで"***はAbstractClassです。"という
フレーズをよく見るが、AbstractClassというものに興味を持った事も
疑問を持った事も一切ない。

439 ：デフォルトの名無しさん：2010/05/03(月) 16:30:38

>>438
お前は１０年間何をやってたんだ？
そんなんじゃ、ろくなものつれないだろ？

440 ：デフォルトの名無しさん：2010/05/03(月) 16:33:04

なんでも速攻で作るので結構重宝されてる。鼻歌まじりさ。

441 ：デフォルトの名無しさん：2010/05/03(月) 16:46:31

new mouthadapter{ public void actionLister(hogehoge); }とかこんな感じだろ？

442 ：デフォルトの名無しさん：2010/05/03(月) 16:54:52

>>440
GUIだけなら、誰でもそうだろ？

443 ：デフォルトの名無しさん：2010/05/03(月) 17:00:57

もうね、JAVAやってると理論はどうでもええの。
ちゃちゃっと作ってエラーでたら、ネット検索にその部分を貼り付けて出た
例文見て適当にそれをペーストしたら動く。

444 ：デフォルトの名無しさん：2010/05/03(月) 17:24:03

何が猫でもわかるだっつの　文章も読みにくく、説明がヘッタクソ

445 ：デフォルトの名無しさん：2010/05/03(月) 17:38:23

おまえは猫以下か

446 ：デフォルトの名無しさん：2010/05/03(月) 20:10:33

>>444
猫に分かるように書くとああなるんだよ

447 ：デフォルトの名無しさん：2010/05/03(月) 20:30:19

わかたぞ！
仮想関数とはJAVAのimplementsされるクラスみたいなもんか。
なーんだ、そんな事なら早く言ってくれよ。まったくっ

448 ：デフォルトの名無しさん：2010/05/03(月) 20:37:21

>>444

C/C++言語以前に、猫言語を習得していないと、あのページは読めないぞ

449 ：デフォルトの名無しさん：2010/05/03(月) 20:39:26

ということはなんだ、インターフェースの事じゃねぇか。
アプリつくる時にゃ１つや２つは作ってるけど。。。
これで仮想関数なるものがやっとわかったぜおおきに。

450 ：デフォルトの名無しさん：2010/05/03(月) 20:46:07

>>447
全然違う
このコードを走らせてみて理解汁
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;
}

451 ：デフォルトの名無しさん：2010/05/03(月) 21:10:19

Javaも内部的な関数呼び出しには、
invokevirtual
invokeinterface
invokestatic
invokespecial
の４種類あって、invokespecial（コンストラクタ）とinvokestatic（staticメソッド）はポリモーフィックには動作しないよ。

452 ：デフォルトの名無しさん：2010/05/03(月) 21:11:37

>>451
ああ全てと言っちゃうと語弊があったね
指摘サンクス

453 ：デフォルトの名無しさん：2010/05/03(月) 21:14:18

そうかー（っても、はっきりは理解してないが、雰囲気はわかる気がする）
ややこしいもんだな。Javaも俺の知らん内部でややこしくやってるわけか。

454 ：デフォルトの名無しさん：2010/05/03(月) 21:14:54

ポリモーフィックも知らずにJAVAをよく１０年もやれたなｗ

455 ：デフォルトの名無しさん：2010/05/03(月) 21:24:47

あえて踏み込まなければなんでもいけるっしょ
ExcelやWordと同じ

456 ：デフォルトの名無しさん：2010/05/03(月) 23:09:56

その場限りを続けてるとどうなるのか、身をもって知ったわけだ。
10年は無駄じゃなかった・・・と思うよ

457 ：デフォルトの名無しさん：2010/05/03(月) 23:19:55

１０年つっても７歳～１７歳だからな

458 ：デフォルトの名無しさん：2010/05/03(月) 23:26:41

>>457
っあ、なんだ趣味でやってるような、ｦﾀでしたかｗ
だったら、何の問題もないんじゃねｗ

459 ：デフォルトの名無しさん：2010/05/03(月) 23:44:25

17 歳の猫以下が誰に重宝されてたのかが気になるところだが・・・

460 ：デフォルトの名無しさん：2010/05/04(火) 08:52:51

GUIが難しいスレに集まったヤツらが初心者を笑うとは
目くそ鼻くそを笑うの典型だな。

461 ：デフォルトの名無しさん：2010/05/04(火) 09:06:33

どんなFramework使おうが
独特のポインタ概念とイベント概念が存在していて
どれも異なったやり方をしてるけど
決して無くなることのない部分で
分からない人はこの辺が分からないんだろうな
C++のクラスとポインタ概念が分かればどれも同じことをやってるだけなんだけど
結局内部で何をやってるか調べられるようになるだけど
Frameworkで用意されたものを見せられるだけじゃ
C++やJavaを熟知した人間にも分からないよ
なんかこう統一して欲しい部分ではあるな

462 ：デフォルトの名無しさん：2010/05/04(火) 17:17:49

日本語でOKとまでは言わんが、もう少し落ち着け

463 ：デフォルトの名無しさん：2010/05/04(火) 17:43:04

>>461
そんなあなたにＵＭＬ

464 ：デフォルトの名無しさん：2010/05/04(火) 17:52:02

>>462
ＧＵＩが難しすぎる　という以前に自分の読解力、知識のなさを棚に上げるのはどうかと思う

465 ：デフォルトの名無しさん：2010/05/04(火) 18:09:09

>>464
では訊くが、>>461 は結局のところ「何を統一して欲しい」と言ってるんだ？

それは >>461 が言う「決して無くなることのない部分」なのか？
（そもそも、その部分が何を指してるかもやや曖昧だが）

466 ：デフォルトの名無しさん：2010/05/04(火) 18:20:05

>>465
>「何を統一して欲しい」
コンピュータ手続き処理

ISO9000 シリーズを参照

467 ：デフォルトの名無しさん：2010/05/04(火) 18:37:53

この程度もわからんボケキチガイが上司なのか
かわいそうに
かわいそうに

468 ：デフォルトの名無しさん：2010/05/04(火) 18:52:56

>>463 は「UMLで解決できるもの」が統一して欲しい対象だと解釈しているようだが、
>>466 はコンピュータ手続き処理というものが統一して欲しい対象だと解釈している。

どっちなんだ？どっちも違うのか？
それともコンピュータ手続き処理とやらは UML で統一できるのか？

469 ：デフォルトの名無しさん：2010/05/04(火) 18:53:49

以下　無能なループ

＝＝＝　開始　＝＝＝

470 ：デフォルトの名無しさん：2010/05/04(火) 23:05:45

これから必要なのはドキュンメイトとコードの一元化

471 ：デフォルトの名無しさん：2010/05/04(火) 23:14:05

一応ここGUIスレなんだから、GUIに絡めた話は端折らずに説明してくれよ
そのドキュンなメイトとコードの一元化によってGUIの何とかという問題を解決するよ
とかさ

472 ：デフォルトの名無しさん：2010/05/05(水) 00:03:39

↑ドキュンメイト

473 ：デフォルトの名無しさん：2010/05/05(水) 00:19:06

>>471
それ以前に、ドキュンなメイトとコードの一元化ってのがどういう状態をさしているのか理解できん

474 ：デフォルトの名無しさん：2010/05/05(水) 14:08:08

>>473
あなたは理解しなくていいです

475 ：デフォルトの名無しさん：2010/05/05(水) 14:13:32

GUIができないやつは無能

476 ：デフォルトの名無しさん：2010/05/05(水) 14:42:01

能なんて飾りです

477 ：デフォルトの名無しさん：2010/05/05(水) 16:48:09

誰だ！　悪名高き「猫でもわかるC言語」を紹介しとるのは、
この本は猫どころか相当頭のいい者でも混乱させるだけで、
ポインタでC習得挫折者を続出させたA級戦犯的入門書じゃないか。

478 ：デフォルトの名無しさん：2010/05/05(水) 16:50:00

2行目までは同意
3行目は猫が出る前からポインタ問題は存在していたから同意出来ない

479 ：デフォルトの名無しさん：2010/05/05(水) 16:53:55

>>477
1~476スレの間でそんな本を紹介してたヤツはいないが

480 ：デフォルトの名無しさん：2010/05/05(水) 17:34:03

オブジェクト指向なGUIに挫折したら誰が戦犯になってくれるんだ？

ポインタの挫折は被害者に加勢して加害者の悪名を高めておきながら、
OOとGUIは挫折したら自己責任とか、まさかそんな事は言えないよな

481 ：デフォルトの名無しさん：2010/05/05(水) 20:10:23

あきらめろ
迷惑だ

482 ：デフォルトの名無しさん：2010/05/05(水) 20:46:58

「本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメイン
の言語となる望みを絶ったのは、永久凍土の問題なのだ。」

483 ：デフォルトの名無しさん：2010/05/06(木) 01:24:28

>>480
君の思考はまさにこれ
http://ja.wikipedia.org/wiki/%E9%98%B2%E8%A1%9B%E6%A9%9F%E5%88%B6
赤ちゃんやキチガイと同じ

選択肢は3つ

独裁者になる（思い通りになるものを作る、作らせる）
世捨て人になる（思い通りにならないものには触れない）
慣れる（学習する）

何でもかんでも人とせいにするのはやめましょう

484 ：デフォルトの名無しさん：2010/05/06(木) 02:41:18

選択肢は4つ

独裁者になる（思い通りになるものを作る、作らせる）
世捨て人になる（思い通りにならないものには触れない）
慣れる（学習する）
人を使う（他人にやらせる）

成功するのは後者だ

485 ：デフォルトの名無しさん：2010/05/06(木) 21:46:19

構造化プログラミングからやりなさい
いきなりオブジェクト指向はあなたに無理

486 ：デフォルトの名無しさん：2010/05/06(木) 21:48:43

N88-BASIC 時代みたいに
上から下へと処理が流れる時代ではないのよ

色々なプログラムがあって、メッセージを受け取り、どのプログラムに
送信するかＯＳが決める
そして、そのプログラムを実行するタイミングもＯＳが管理する
これを理解できない限りWindowsプログラミングはあきらめたほうがいい

487 ：デフォルトの名無しさん：2010/05/06(木) 22:05:07

>>483
人を原因にするのがイヤなら人以外の物でいいから、とにかく原因を探そう

488 ：デフォルトの名無しさん：2010/05/06(木) 22:18:24

HTMLで成功して
すこしずつ、慣れるのがいい
結果が欲しいんだろ？

もしくは、printf( "hello world\n" );からでもいい
ゆっくりやるのがいい

489 ：デフォルトの名無しさん：2010/05/06(木) 22:22:56

もしくは、ＧＵＩの何が難しいのか原因を探る、考える
自分は、この処理の流れがわかｒない
なぜ、こう処理されるのか、
原因と結果を自分で確かめる、実行する　人のせいにしない

時には人に相談するもよし
ここまでくると、自分は、どこのどういう処理、形式が分からないという内容の
発言で自分はここまでは理解できます
という自己表現が必要
自分ができないことを紙にかいてみる
したいことも書いてみる
そこから、何が原因でできないかを考える

490 ：デフォルトの名無しさん：2010/05/06(木) 22:36:17

どう書く？orgにGUIの問題ってあったっけ
解くのもむずかしいが、出題するのもむずかしい気がする

491 ：デフォルトの名無しさん：2010/05/07(金) 13:30:34

猫Cの人は日本語能力が低いつーか、猫語以下だね・・・・

492 ：デフォルトの名無しさん：2010/05/07(金) 13:58:47

フォトレタッチソフトを作りたく色々調べていたのですが
レイヤー機能の作り方みたいな講座サイトってないでしょうか？

493 ：デフォルトの名無しさん：2010/05/07(金) 15:02:45

レイヤーってリストじゃね？

494 ：デフォルトの名無しさん：2010/05/07(金) 15:26:06

レイヤーがそういうものだっていうことさえ
今時点ではわからず。

GUIでレイヤーをつかう、という情報がどこから仕入れられるのでしょうか

495 ：デフォルトの名無しさん：2010/05/07(金) 15:36:36

つ http://msdn.microsoft.com/ja-jp/library/ms997507.aspx

496 ：デフォルトの名無しさん：2010/05/07(金) 15:48:17

すんません
フォトレタッチソフトで言うところのレイヤーです。

497 ：デフォルトの名無しさん：2010/05/07(金) 15:52:13

まずペイントは作れるのかね？

498 ：デフォルトの名無しさん：2010/05/07(金) 15:58:56

GIMPのソースコードに書いてあるよ

499 ：デフォルトの名無しさん：2010/05/07(金) 16:07:50

あんなもの読みたくもないから
必要な部分だけ抜き出して

500 ：デフォルトの名無しさん：2010/05/07(金) 16:08:58

了解
待ってろ

501 ：デフォルトの名無しさん：2010/05/07(金) 16:09:54

暇を見つけてやるから
３カ月ほど待ちなされ

502 ：デフォルトの名無しさん：2010/05/08(土) 08:21:39

わかった
たとえ３ヶ月後にバージョンアップしてて
つかいものにならなくてても待つ

503 ：デフォルトの名無しさん：2010/05/09(日) 08:22:46

俺が大好きなハンゲで麻雀が弟に回線切られてできなくなった
このクソキチガイ弟が

504 ：デフォルトの名無しさん：2010/05/09(日) 08:24:40

プロセスとかスレッドとかって何だよ
俺は海外留学できたくらい英語ができる人間様だ
ハンゲじゃ貴族で誰もがおれをしたってる
麻雀もできやしねぇ弟なんかクソゴミ

そんなクソゴミが俺様に逆らうってのは殺されたいのか？あ？

505 ：デフォルトの名無しさん：2010/05/09(日) 08:30:54

弟がクソのように何が「ハンゲの麻雀は牌操作してる」だ
お前の理屈なんかききたくものねー
麻雀は通にしかわからない選ばれた者だけの一流のゲームだ

相手の捨て牌さえ見てれば、相手の役なんかわかるんだよクソボケ
麻雀のＤＶＤでも不正はできねぇって言ってるんだ
リアルでも不正できねぇのに　ネトゲで不正できるわけねぇだろ

506 ：デフォルトの名無しさん：2010/05/09(日) 10:26:35

とりあえずスレ違いだ

507 ：デフォルトの名無しさん：2010/05/09(日) 18:45:13

CUIからGUI(win32API)に移ったとき難しかったのは、
画像の表示、イベントドリブンだったな。

画像表示はBitBltで行うが、HDCの部分が分かりにくい。
出力先、元がHWND、HDC、HBITMAPどれの場合でも、
ひとつの関数で出力できる関数を作ると使いやすい。

イベントドリブンは、わざわざコールバック関数に投げるのが意味不明だった。
GetMessageで得たMSG構造体をメッセージループでそのまま使えれば、
while(1){c = getch()}みたいな使い方と似ていて分かりやすいのだが。

実際自分はそのやり方でやる事で使いやすくなった。
WM_PAINT、WM_COMMAND、WM_CLOSEは
メッセージループの方には来ないので、
関数のstatic変数などに記憶する必要がある。

ただ、javaやas3はこの技が使えなく、文法もさらに厳しく、
結局、オブジェクト指向風の考え方が必要になってきた。

508 ：デフォルトの名無しさん：2010/05/09(日) 18:49:13

うん、いるね
すべての関数がstaticな人
意味わからん

509 ：デフォルトの名無しさん：2010/05/09(日) 18:57:47

API → コールバック関数 → 自前イベントキュー → 別スレッド

これで勝つる

510 ：デフォルトの名無しさん：2010/05/10(月) 00:14:52

>>507
釣りじゃなくて本気だったらお前は向いてない

511 ：デフォルトの名無しさん：2010/05/10(月) 01:32:37

キューに色んな種類のイベントを入れると、静的な型情報がかなり失われてしまう。
動的に型タグを調べなおしたりするから静的型の意味が無い。
イベントドリブンに拘るのはそういう事情もあるんだろうな。

512 ：デフォルトの名無しさん：2010/05/10(月) 02:00:25

麻雀は頭の悪い人がやる遊びだからｗ

513 ：507：2010/05/10(月) 07:08:41

現在、コードのどの位置なのか、目で追えないと分かりづらくて。
正規？の書き方もできるが、時間はかかってしまう。
as3はstaticな関数とか使えない(はずだ)から書かざる得ない。
DirectXやアイフォンならCベースで書けるらしいけど。

>>509 >>511
ヒントに勉強させてもらう、サンクス。

514 ：デフォルトの名無しさん：2010/05/10(月) 21:58:25

opengl表示するのに、どの言語が一番いいのかわからん

515 ：デフォルトの名無しさん：2010/05/10(月) 22:11:41

Cにきまっとる

516 ：デフォルトの名無しさん：2010/05/10(月) 22:54:11

Cとrubyは多少勉強してるんだが、趣味のプログラミングで手軽にGUIアプリ作れる言語のオススメってある？
できたら書籍が多く出てる言語がいいんだけど

517 ：デフォルトの名無しさん：2010/05/10(月) 22:59:24

C#
C++ + Qt
QtRuby
Java + swing

518 ：デフォルトの名無しさん：2010/05/11(火) 11:11:45

OOpわかってるならC#じゃない？

519 ：デフォルトの名無しさん：2010/05/11(火) 11:15:44

PyQt4

520 ：デフォルトの名無しさん：2010/05/11(火) 12:40:37

手軽と言えばHSPでしょ

521 ：デフォルトの名無しさん：2010/05/11(火) 12:42:10

wxPython

522 ：デフォルトの名無しさん：2010/05/11(火) 12:42:51

>>516
GUI アプリ作りたいなら Ruby だけは止めとけ

523 ：デフォルトの名無しさん：2010/05/11(火) 16:10:47

HSPで十分。

524 ：516：2010/05/11(火) 17:09:36

とりあえずC#を勉強してみることにしてみた
いろいろと情報サンクス

525 ：デフォルトの名無しさん：2010/05/16(日) 00:23:43

いまさらながらtcl/tkをはじめた。超簡単にGUIを作れてびっくりした。

526 ：デフォルトの名無しさん：2010/05/23(日) 16:30:52

small talkがいい

527 ：デフォルトの名無しさん：2010/05/25(火) 18:35:36

＞＞１の気持ちがよくわかる…

528 ：デフォルトの名無しさん：2010/06/02(水) 21:10:52

今SwingでGUIアプリ作ってるんだけど、プログラムより配置とかの設計で悩むのだが何かいい読み物ない?

529 ：デフォルトの名無しさん：2010/06/02(水) 21:58:13

>>528
配置だけならデスクトップのアイコンの自動配列をマネれば・・・
どこらへんで悩んでいるのかｋｗｓｋ

530 ：デフォルトの名無しさん：2010/06/02(水) 23:27:33

>>528
デザイニング・インターフェース
http://www.amazon.co.jp/dp/4873113164/

あるいは、関連本

531 ：デフォルトの名無しさん：2010/06/03(木) 13:20:41

つ ttp://bookweb.kinokuniya.co.jp/htm/4893621416.html

532 ：デフォルトの名無しさん：2010/06/10(木) 02:42:01

test

533 ：デフォルトの名無しさん：2010/06/14(月) 16:23:41

GTKがむずい

534 ：デフォルトの名無しさん：2010/06/16(水) 11:54:12

Qt いいよ

535 ：デフォルトの名無しさん：2010/06/17(木) 19:49:18

GTK はくそ

536 ：デフォルトの名無しさん：2010/06/24(木) 00:14:52

>>534
Qtはいいけど、高すぎ

趣味かえるレベルではない

537 ：デフォルトの名無しさん：2010/06/24(木) 00:22:56

Cocoa は楽で良いわ。見た目も良いし、簡単だし。
20 年近く前から連綿と続いているというのも凄い。

538 ：デフォルトの名無しさん：2010/06/24(木) 01:50:35

>>536
qtのどこが高いんだ？
無料ジャン

539 ：デフォルトの名無しさん：2010/06/24(木) 08:48:16

だね
Qt は趣味で使うなら無料だし，個人でチマチマやる程度なら
商用でもLGPL版で行けそう
企業でソフト売るために本格的に使うなら高いという程の値段じゃないし

540 ：デフォルトの名無しさん：2010/06/24(木) 21:34:59

>>539
>企業でソフト売るために

ソース付ならQtにライセンス料払わずに売っても良いんだよね

541 ：デフォルトの名無しさん：2010/06/24(木) 21:49:54

>>540
LGPLと商用ライセンスのどちらかを選べるようになってる
ただし、フリー版で開発して発売する段階になって商用ライセンス取るのは一応NGとされてる

542 ：デフォルトの名無しさん：2010/06/24(木) 22:20:40

LGPLは原理的にはソース公開を必要としない場合もあるけど
Qtの場合にはそういう状況にならなそうだな

> ただし、フリー版で開発して発売する段階になって商用ライセンス取るのは一応NGとされてる

それは知らんかった
まずフリー版で試してうまく行きそうだったら商用買うなんていかにも
ありそうなシナリオだと思ってた

543 ：デフォルトの名無しさん：2010/06/25(金) 20:37:21

企業がソフトを売るためにLGPL使う

544 ：デフォルトの名無しさん：2010/06/26(土) 23:21:39

よくわかんないのでコピペして
コンパイルして売りますね

545 ：デフォルトの名無しさん：2010/07/13(火) 17:28:28

Qtって
これまでの流れからすると、古いプラットフォームや人気のないプラットフォームは
あっさり中止する感じですね。その上、古いバージョンは配布していないようですので
切り捨て文化だと思います。

つまり、商用でごりごりVerUpしていくならともかく、個人利用ではドンドンVerUPして
ついて行くか、見捨てられた古いVerのQTで頑張るかという決断を強いられる。
ついていくとなればOSやらH/Wやらの更新が発生し、自作ソフトの旧Ver使用者は
なし崩し的に捨てる事になるでしょう。一方、古いQTで頑張るならばもしQTにバグや
セキュリティホールが見つかれば自身で直すか、自作ソフトの機能を変更／削除して
ごまかす事になるでしょう。また旧QTが入手困難であるため、開発協力者は現れない、
QTの機能は増えないというのも頭が痛いところですね。

546 ：デフォルトの名無しさん：2010/07/13(火) 22:16:27

>>545
Qt4ってQt3との互換性維持しているはず
Qt3が2001，Qt4が2005年に出たみたいだけど，
それってそんなに「切り捨て文化」なの？

ちなみに「個人利用」って商用のソフト書く場合について？
GPLとかなら最新版使えるよね

547 ：デフォルトの名無しさん：2010/07/13(火) 23:00:30

>>545
それってQtに限らず、どんなツールキット(ライブラリ)にでも当てはまることじゃないのかな。

たとえば、自分はRuby-GTKとRuby/Tkでプログラミングすることが多いんだけど、
Ruby-GTK2の登場でRuby-GTK(GTK1ベース)の開発は打ち切りになった。
まぁ打ち切りになるのは分かるんだけど、メンテナがいないのか、最近のLinuxディストリ
(具体的にはDebian/Lenny)ではパッケージ配布まで中止されたから、自前でRuby-GTKを
ビルドしなければならない。また、仮にRuby-GTKにバグが見つかった場合には
(今のところ経験は無いけど)、自力での解決を迫られることになると思う。

また、VineLinux1.x時代に作った(Tk7.xベースの)Ruby/Tkスクリプトも、
最新のLinuxディストリで動かすには移植作業が必要になる。(大した手間じゃないけどね)

あと、Qtについては触った事が無いというか、使う必要性を感じていない。
理由は、特定のベンダに縛られた仕様に依存したくない事と、GPLの強制が嫌だから。

548 ：デフォルトの名無しさん：2010/07/13(火) 23:13:09

GPLってなんのこと？

今はGTKは完全にQtに追い越され
いつ消えるのかって状態だと思うけど。

ま、GNOME関係があるから生き残るだろうけどね。
それ以外のマルチプラットフォームライブラリとしては
Qtの方がすべての点で上。

549 ：デフォルトの名無しさん：2010/07/13(火) 23:15:22

×GPLってなんのこと？
○GPLの強制ってなんのこと？

http://ja.wikipedia.org/wiki/Qt
ライセンスには商用版とオープンソース版があり、
現在のオープンソース版のライセンスはLGPL（Qt4.5より）およびGPL である
商用版を購入するとQt 商用ライセンス（Qt Commercial Developer License）でソフトウェアを開発することができる[2]。

LGPL版は、2009年3月にリリースされたQt 4.5から提供され始めた。
これによりQtは営利企業にとってもより使いやすいライブラリーとなった。

550 ：デフォルトの名無しさん：2010/07/13(火) 23:17:57

今のQtはツールキットではないからね。

マルチプラットフォームライブラリ＋GUIツールキット＋IDE（統合開発環境）
Visual Studio＋Windows SDKに近い存在だよ。

551 ：547：2010/07/14(水) 00:18:13

>>548
>今はGTKは完全にQtに追い越され
>いつ消えるのかって状態だと思うけど。

オープンソースコミュニティ(gnome.org)が存続する限り、GNOME(=GTK)が消えることは
ありえないと思いますけど。gnome.orgが解散を表明!!とかGTK開発の放棄を宣言!!みたいな時事について
情報はお持ちですか？。もし持っていないのなら、それは>>548の個人的な願望、あるいは妄想でしょう。

>それ以外のマルチプラットフォームライブラリとしては
>Qtの方がすべての点で上。
QtはGTKより後発で、しかも営利団体の庇護の基にありますから、機能性や技術情報の整備状況などを
総合的に比較すれば、その通りだと思います。これはCocoa(by Apple) vs. GNUstep(by GNU)の
関係と似ています。また、マルチプラットフォーム性については比べようもありません。
もし私が「仕事で」ツールキットを選択できる立場にあったとしたなら、間違いなくQtを選ぶでしょう。

ただし、「個人的な趣味のプログラミングで」ツールキットを選ぶなら、GTKを選びます。
理由は前(>>547)にも書いたように、特定のベンダの意向に縛られたくないからです。
(私はCocoa/CarbonやWPF/Win32も嫌いです。)これは個人の主観の差であるとしか言いようがありません。

>>549
これは勉強不足でした。WikipediaとNOKIAのサイトを見ると、すべてのプラットフォームで
LGPLが適用できるみたいですね。>>547の「GPLの強制」という発言は取り消します。

552 ：547：2010/07/14(水) 00:49:52

>>550
>Visual Studio＋Windows SDKに近い存在だよ。

Qtが提供するのは(統合開発環境ではなく)GUI開発環境でしかないと思いますけど。

たとえばWCF(Windows Communication Framewok)によるサービスを提供している
アプリがリモートWindows Server上で動いていて、そのサービスを利用したいとします。
Qtの統合開発環境では、そのようなネットワークサービスを抽象化したマルチプラットフォーム
フレームワークを利用できますか？(SOAPは機能性が著しく制限されるのでN.Gですよ)

たとえば、MacOSX上でGTDアプリを開発しようとして、アドレスブックやiCal(カレンダ)の
情報とリンクする機能を実現したいとします。Qtの統合開発環境では、そのようなアプリケーション間
連携サービスを抽象化したマルチプラットフォームフレームワークを利用できますか？

もちろん、このようなプラットフォーム固有のサービスに依存しないアプリ開発は多く存在するでしょう。
また、マルチプラットフォーム性を開発の最優先事項に据えることの可能なプロジェクトも存在します。
そのようなケースはQtで対応できるはずだし、Qtを選ぶべきでしょう。

でも、(上に挙げた２例のように)プラットフォーム固有サービスの利用が大前提(必須)となる開発の場合、
アプリ内にQt依存のコードとプラットフォーム固有フレームワーク依存のコードが混在することになります。
これらが正常に動作することをQtの開発元は保証してくれますか？(有償ライセンス下でOK)
トラブルが発生した場合、国内の代理店はまじめに対応してくれますか？

何を言いたいかというと、QtのGUI開発環境がVisual Studio(あるいはXCode)に近い存在であるという主張は、
誤解をまねきかねない誇大な表現、あるいはおこがましい主張ではないか？という疑問です。

553 ：デフォルトの名無しさん：2010/07/14(水) 01:27:34

>>552
その理屈でいくと、VisualStudio+M$以外のライブラリの組み合わせも保証が無いからダメじゃん

554 ：デフォルトの名無しさん：2010/07/14(水) 07:15:00

>>551
共産党員のかたですか？

555 ：デフォルトの名無しさん：2010/07/14(水) 09:27:59

>>552
> >>550
> >Visual Studio＋Windows SDKに近い存在だよ。
>
> Qtが提供するのは(統合開発環境ではなく)GUI開発環境でしかないと思いますけど。

確かにVisual Studio+Window SDK に近いというと>>552みたいに
曲解する人間もいるだろうから止めた方が良いかもね

ただ「GUI開発環境でしかない」というのもどうかなとは思うな
ウィジェットはもちろん，タイマー，SQL，webkit,
ネットワーク，OpenGLとかのAPI装備してる

基本的にフレームワーク(Qt)+IDE(Creator)だと思うがな

他社のプロプラのライブラリとシームレスに連動することが
IDEの条件（大体IDEじゃない，それいうならフレームワーク）
だという主張なの？かなり奇妙な主張だと思う
君の定義で「統合開発環境」なんて存在するの？

556 ：デフォルトの名無しさん：2010/07/14(水) 10:17:36

保証された環境でプログラミングなんて夢のような世界だな。

557 ：545：2010/07/14(水) 14:28:05

>>547
Ruby-GTK2ってRuby-GTKを使っていた環境そのままで
動作しませんか、動くなら私の言いたい切り捨てとは
ちょっと違う例だと思います。
他にも自前で対応についても、使ってる時点でRuby-GTKの
一員なのではないかと思います。だから、Ruby-GTKを
継続してメンテしたいのならやればいいのだと思います。
ファイルすら置かせてもらえないなら思いっきりforkして
も良いかと思います。

Qtを勘違いしていたようです。多分Qtライブラリの方
（Creatorとか含まない方）はGPLだし新規にプロジェクト
作ってForkしてもいいんでしょうね。

558 ：デフォルトの名無しさん：2010/07/15(木) 02:29:58

>>555
きっと >>552 はQtCreatorを知らなかったんだろうね

559 ：デフォルトの名無しさん：2010/07/15(木) 07:35:59

Qt CreatorがGUI開発環境とは思わない理由

GUIをRADでぽちぽちおくことができる・・・だけではなく、
そこからコードの雛形を作れる。

もちろんそこからQt Creator上でコードを書いていける。
もちろんコードは色付いていたり、デバッガも内蔵していて
ブレークポイントで止められたり、変数の中身を見れる。

MercuriaやGitにも対応。

コンパイラはcygwinだけではなく、Visual Studioのコンパイラも使用可能
プロジェクトファイルはqmake。これはいろんなプラットフォーム用の
makeファイルに変換して実行できる。

ソースコードを書きやすくするための機能がIDEに統合されているとはいえ
コンパイル環境は結局は、既存のコンパイラ・Makeを使っているので、
実行ファイル生成自体は普通のエディタでの開発と変わらない。
だからやろうと思えばプラットフォーム固有のライブラリと連携も可能

> アプリ内にQt依存のコードとプラットフォーム固有フレームワーク依存のコードが混在することになります。
> これらが正常に動作することをQtの開発元は保証してくれますか？(有償ライセンス下でOK)

ようは違うライブラリを混ぜて、正常に動作することを保証するかって事だろ？
そんなこと保証しているところあるの？

560 ：デフォルトの名無しさん：2010/07/15(木) 07:48:42

>>557
> Qtを勘違いしていたようです。多分Qtライブラリの方
>（Creatorとか含まない方）はGPLだし新規にプロジェクト
>作ってForkしてもいいんでしょうね。

QtライブラリはLGPLと商用のデュアルライセンスね。
GPLだとソースコード公開しないといけなくなるけど、
QtはLGPLなのでQtで作ったアプリはソースコード公開しなくていい。

561 ：デフォルトの名無しさん：2010/07/17(土) 01:47:30

qtって、cmakeとかqmakeとか覚えること多そうでヤだ
gtkって、どんな点でqtより劣ってるの？

562 ：デフォルトの名無しさん：2010/07/17(土) 01:55:00

>qtって、cmakeとかqmakeとか覚えること多そうでヤだ

はぁ？

563 ：デフォルトの名無しさん：2010/07/17(土) 03:08:43

ビデオカードとのやり取りをするとCPUの実行速度が2CPI程度に落ちるな
相当レイテンシがあるんだな

564 ：デフォルトの名無しさん：2010/07/17(土) 10:44:58

>>561
Qt Creator とか IDE 使っていれば qmake とか意識しないよ
Qt はC++ native なので C++ 派には使いやすいのと Qt Creator
はできが良くて使いやすい

好みもあるだろうから Gtk で満足ならそれでいいんじゃないか

565 ：デフォルトの名無しさん：2010/07/19(月) 13:13:15

Qtいいけど、WxWidgetsの方がネイティブっぽくて良い

566 ：デフォルトの名無しさん：2010/07/19(月) 14:04:03

wxwidgets だとどの IDE でGUI部品のレイアウトの調整とかするの？

567 ：デフォルトの名無しさん：2010/07/19(月) 14:09:19

kita2とか、kdevelopとか、kateとか、
見栄えが良くて軽快に動作して、ガンガン落ちるイメージ.
wxwidgetsって昔からあるわりには、あまりつかわれてないような

568 ：デフォルトの名無しさん：2010/07/19(月) 15:37:24

見た目とか、ライセンス的にwxwidgetsを
使おうと思っていたときもあってけど、

QtがLGPLライセンスになってIDE込みになってからは
Qtが最善のマルチプラットフォーム環境になった。

X Window Systemアプリだけを作るのなら
gtkでいいけど、OS依存のアプリは作りたくない。

569 ：デフォルトの名無しさん：2010/07/19(月) 16:30:30

gtkって、マルチプラットフォームをうたってないか？
宗教臭いのがダメなだけで

570 ：デフォルトの名無しさん：2010/07/19(月) 20:05:58

GTKは糞

571 ：デフォルトの名無しさん：2010/07/19(月) 21:05:22

プログラマはWindowsとLinux,UNIX分かれた方がいいと思う

572 ：デフォルトの名無しさん：2010/07/19(月) 22:06:05

Macもなw

573 ：545：2010/07/19(月) 22:40:48

正直Macを含まなくてよいなら、どれでもそこそこ動くんだよね。
Macの互換性の低さに嫌気がさすのか、どれもこれも問題を
抱えてしまうようだ。

574 ：デフォルトの名無しさん：2010/07/19(月) 23:13:30

> どれでもそこそこ動くんだよね。
インスコ厨の意見のようだ

575 ：デフォルトの名無しさん：2010/07/20(火) 00:29:03

実際、決定版のGUIライブラリを発見したわけでも
垢の他人の作ったGUIライブラリと心中する気もないので、
いろいろと少しづつ齧ってたりしていますが、
即他人を厨あつかいとは、やはりMacって書くとわくのかな。。。

576 ：571：2010/07/20(火) 19:45:41

Macはその他で

577 ：デフォルトの名無しさん：2010/07/20(火) 20:52:16

>>571
QtについてはMac版の開発キットが公式リリースされているので、
他のプラットフォーム(LinuxやWindows)と同様な開発が可能です。

GTK(GNOME)については、標準でX11(Xサーバ)が付属しているので、
必要なライブラリを自力ビルドできるスキルをデベロッパが持っていれば、
完璧なUNIXマシンとして開発が可能です。GIMPが代表例ですね。
GTK for Win32のように環境変数やレジストリで悩む(発狂する!!)ことはありません。
また、GTKonOSXと呼ばれ、(X11無しで)Cocoaをレンダリングエンジンとして動く
GTKのOSX移植版開発プロジェクトが開始され、ベータ版がリリースされています。

またTcl/Tkに至っては、AquaTkと呼ばれるCarbonをレンダリングエンジンとして動く
TkのOSX移植版フレームワークが10.4(Tiger)から標準でインストール(OSに付属)されます。
言い換えると、UNIX上で動いているTcl/TkやRuby/Tkスクリプトは無変更でOSX上で動きます。
Windowsのように、ユーザがActiveTclをインストールしなければならないといった手間はありません。

このようにUNIXとして見たMacOSXは、LinuxやBSD等との「高度な互換性」が実現されています。
この辺の情報は、UNIXの知識があるMacデベロッパであれば、常識でしょう。
それなのに「Macの互換性の低さ」とか言い出すトワイライトゾーンの住人の妄言には頭が痛いです。
自分は>>574ではありませんが、>>573のカキコは「厨あつかい」されてもしかたのない内容だと考えます。

578 ：デフォルトの名無しさん：2010/07/20(火) 22:42:41

javaかmonoで良い気がするんだけど、
みんなネイティブとかバイナリにコダワルの？

579 ：577：2010/07/20(火) 23:37:54

>>577冒頭行にある、アンカ>>571は>>573(>>545?)の誤りでした。

大変、失礼しました。>>571

580 ：デフォルトの名無しさん：2010/07/21(水) 10:27:25

やっぱりMacはNGワードだったな。
ずきゅーんと打ち抜いたせいか>>577みたいのがわいちゃった、

581 ：デフォルトの名無しさん：2010/07/21(水) 10:58:16

>>578
見た目がネイティブじゃないと大衆受けないのはJavaで
一応の結論が出てるかも。M＄の勝手なネイティブGUIに
いちゃもんを付けていた陣営は未だにこびり付いてる
みたいだけど、SWTはがんがんいってます。
でもMacを入れるとJavaだのGTKだの自前で描画からがっつり
やってるようなGUIライブラリじゃないとやっていけないみたい。
X11も謹製以外の実装はENDしちゃうくらいきな臭い世界。
商用のQTは頑張ってネイティブGUIサポートしてるけど、
即ぎり文化だし、親会社は携帯電話で戦争状態にあり
いつ停止してもおかしくないと思う。
XULなら開発者集団も多く末永くつきあえそうだから、MULの
方がいいのかもしれないとか考えてしまう。

582 ：デフォルトの名無しさん：2010/07/21(水) 19:35:53

>>581
日本語でオケー

583 ：デフォルトの名無しさん：2010/07/22(木) 00:03:04

こういう業界では遠い将来について考えるより現時点で使いやすい
ものを使うのが良いと思うけどな
何が起きるかわからんし，乗り換える必要がでたらその時はその時

これももし選択肢が自分にあるならばだけどな
そうじゃなければやるべきことをやる

584 ：デフォルトの名無しさん：2010/07/22(木) 00:59:56

Delphiのひとはかわいそうだったな

585 ：デフォルトの名無しさん：2010/07/23(金) 23:17:23

言語自体は変わっても、覚えなおすのに対して時間かからないからいいんだけど
その言語で作ってきたGUIコンポーネントがゴミになるのは痛すぎる

586 ：デフォルトの名無しさん：2010/07/24(土) 13:42:59

中身の普通の言語（C++等）でかかれた部分は基本的に生かせるから
GUI部分からできるだけ独立させておくことがやっぱり大事だわな
MVCとか言ってもあまりにも陳腐だが…

587 ：デフォルトの名無しさん：2010/07/24(土) 15:08:31

GUI部分が小さくてModelが大きいならMVCでいいが、安っぽいGUIしか作れないぞ。
問題は、リッチなGUIを作りたいが後で粗大ゴミが出るのは痛いってこと。

588 ：デフォルトの名無しさん：2010/07/24(土) 15:16:53

http://pc11.2ch.net/test/read.cgi/gamedev/1274510516/
これ？

589 ：デフォルトの名無しさん：2010/07/25(日) 04:32:39

たしかにRailsのGUIはショボい

590 ：デフォルトの名無しさん：2010/07/25(日) 11:06:35

>>587
とはいえ，中身をできる限り独立させておけば構造と中身はリサイクルできる

リッチなGUIを作り直すのは手間がかかるが，プロトタイピング/試行錯誤が
終わった状況でスタートするから，だいぶ楽だと思うぞ

591 ：デフォルトの名無しさん：2010/07/25(日) 23:00:29

>>585
Delphi以降だと、MFCやVisualBasicを使っていたWindowsプログラマだろね。
今のWPFにしても、いつまで持つのやら....。とはいっても、彼らは
「変化があっても皆一緒だから無問題」といふレミング思考な人達だから無自覚なんだけど。

>>589
スタンドアロンなGUIツールキットとWebアプリケーションであるRailsを比較して、何を言いたいの？

592 ：デフォルトの名無しさん：2010/07/26(月) 00:22:00

コモンコントロールみたいに、作った部品をウインドウにしてDLLに詰めて
ラッパー作って操作できるようにすれば、Winでやる限り
ゴミを出さずにどの言語でも使いまわせるっちゃ使いまわせるんだろうけど
ラッパー作るのも大変なんだよな

593 ：デフォルトの名無しさん：2010/07/26(月) 18:47:53

お馬鹿さんな>>589は放置するとして、JavaScriptベースのGUIツールキットの進化には驚かされる。
たとえばSproutCoreというライブラリでは、Flash等の余計なプラグイン無しに、純粋なJavaScriptだけで
完全なGUIをWebブラウザ上に実装できる。
もちろんオープンソースで無償利用できるし、PHPやRailsなどとデータを連携させる実装も可能。

・SproutCore 公式ホームページ - "Demos & Sample Code" を開くと実行できるオンラインデモを試してくれ
　http://www.sproutcore.com/

SproutCoreについては、以下の文書が詳しい。(ただし英語)

・Cocoa for Windows + Flash killer = SproutCore
　http://www.roughlydrafted.com/2008/06/14/cocoa-for-windows-flash-killer-sproutcore/

日本語版については、新・Mac板の「Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7」スレの#197以降を参照。

他にも、これらは商用ライブラリになるけど、デスクトップ向けGUIツールキットに匹敵するライブラリも開発されている。
どちらもオンラインデモを体験できるから、ぜひ試して欲しい。

・DHTML UI toolkit
　http://dhtmlx.com/index.shtml

・EJS TreeGrid
　http://www.treegrid.com/treegrid/www/Index.html

594 ：デフォルトの名無しさん：2010/07/27(火) 16:01:46

>>593
FxやＩＥでも表示崩れたりihone_demoとか動作しないんだが。
あとは環境によるのだろうけど重すぎて快適なGUIとは言いがたいかも。

595 ：593：2010/07/28(水) 21:58:50

>>594
実際に触ってみてくれたんだね。嬉しい。（アクセス規制でレスが遅れた、スマン。代行をお願いしています。）

>FxやＩＥでも表示崩れたりihone_demoとか動作しないんだが。
・Firefoxは最新(安定?)版では表示崩れを確認できなかった。
　　==> 細かいところまで確認はしてないけどね
・Internet Exprolerは最新ECMA Script仕様/HTML5対応がメタメタで、JavaScriptライブラリ側で不足機能を
　エミュレーションするという無理矢理な実装になっているから、部分的な表示崩れはしかたないのかも。
　　==> Webブラウザの中では圧倒的なシェアを占めるIE対応が不完全な事が大きな問題(障害)になるのは事実だけど
・iphone_demoは、その名の通り(iPhoneやiPod touchといった)Apple製iOS搭載デバイス向けのデモだから、
　パソコンのブラウザでは動作を禁止しているのではないかと推測。
　　==> 2週間前にはOSXのSafari上で、iPhone風のMusic Libraryをブラウジングできるデモが動いていた

>あとは環境によるのだろうけど重すぎて快適なGUIとは言いがたいかも。
NetBookクラス(Atom/1GB)クラスだと重さが目立つかもしれないけど、今時の普及機クラス(C2D/4GB)なら
軽快に使えるのではないかと。あと、パソコンのハード性能進化はすさまじいから、個人的には楽観視している。

596 ：デフォルトの名無しさん：2010/07/31(土) 11:07:21

XULでいいんじゃね。

597 ：デフォルトの名無しさん：2010/07/31(土) 16:30:42

IEとネスケとOperaがあるだけでもおなかいっぱいだったのに
最近はWebkitが電撃参戦してますます面倒なことになったけど
10年くらいしたらさらにブラウザエンジンは増えてんのかな

598 ：デフォルトの名無しさん：2010/07/31(土) 20:24:32

dana

599 ：デフォルトの名無しさん：2010/08/09(月) 22:33:24

結局、誰もTkを超えられなかった

600 ：デフォルトの名無しさん：2010/08/20(金) 12:07:41

>>541
これ、なんでNGなんだ？

そもそもLGPLだってリリースするときのライセンスだから、
社内で開発している間はLGPLでも問題ないはずだが

だから、リリースするときにLGPLが嫌だから商用ライセンスとって、
それ使ってリリースは全然有り得る話

というかどうやったら、それをNGとして強制できるのか知りたい・・・

601 ：デフォルトの名無しさん：2010/08/20(金) 13:56:21

嘘を嘘と見抜けない人には2chは向いていないと思う

602 ：デフォルトの名無しさん：2010/09/11(土) 16:02:33

CでCUIを勉強しおわってGUIがむずするぎる

603 ：デフォルトの名無しさん：2010/09/11(土) 16:34:38

それはつまり
Cがわかっていなかったということ
やりなおせ

604 ：デフォルトの名無しさん：2010/09/11(土) 16:39:42

GUI のプログラミングは質が違うから初め戸惑うと思うよ
「コツ」や「ノリ」みたいなのを掴むと楽
標準でCはGUIは無いからどのフレームワーク使うかによっても違ってくる

605 ：デフォルトの名無しさん：2010/09/11(土) 17:33:30

CUIは入力処理がコード内に散らばっているのが普通だけど、
GUIはイベント駆動だから入力を一ヶ所にまとめるコーディングが必要
Cとか言語とは無関係に、どこかで発想の転換が必要になる

606 ：デフォルトの名無しさん：2010/09/11(土) 18:05:33

一度コーディングから離れてFSM(Finite State Machine, 有限状態機械)、
いわゆるステートマシンの初歩を勉強してみるのはいかが？

注意するのは、オートマトンとか自由文脈文法みたいな理論は(まだ)必要無いという事。
事象(イベント)/状態/遷移という概念を理解できれば、GUIプログラミングなら必要十分だから。

607 ：デフォルトの名無しさん：2010/09/11(土) 18:26:38

Cを学んだってことはCでGUIってことになるだろうけど
ガシガシ書く系のGUIになっちゃうだろうな
Cなら C++ に行ければ良いと思うんだけどC学んだところでまたC++ってキツいかも

JavaやC++でGUI coding するけど C でする気起きない

608 ：デフォルトの名無しさん：2010/09/11(土) 18:31:59

C#やってからで遅くない

609 ：デフォルトの名無しさん：2010/09/11(土) 18:52:03

C言語でGUIってことは、Win32(Windows)あるいはGTK(Linux)なのかな？
どちらにしてもコードをガシガシ書く系(by >>607)になっちゃうね
PythonやRubyみたいなスクリプト言語でGUIに慣れるのがいいと思うんだけどなあ

ただ、そのスクリプトを学ぶという苦労を受け入れるってのが前提になる
いずれにせよ、GUIができるようになるのにも、楽な道はどこにも存在しない
壁を破れるようになるまで、ただひたすら頑張るしかないよ

610 ：デフォルトの名無しさん：2010/09/11(土) 19:09:59

>>605
CUIは、スタック上のデータ構造が刻々と変化していくのが普通
GUIはクラスだから、状態は変わるが構造じたいは変わらないようなコーディングが必要
(ただしスレッドを使えばCUIの発想でコーディングできる)
どこかでスレッドを使うか、一切使わないかの見極めがむずかしい

611 ：デフォルトの名無しさん：2010/09/11(土) 19:25:39

>>610
イベント駆動の代わりにスレッドを使うってのは、
資源の排他制御やスレッド間通信みたいな新たな問題を持ち込むだけだから、安易な発想だと思う

バックグラウンドで重い処理を動かしつつ、同時に(並行して)GUIでの操作を可能にする、
というのが目的なら、スレッドの導入は理解できるのだけれど

理想は、手続き型言語ならコルーチン、関数型言語なら継続(コンティニュエーション)を使った
安全なGUIプログラミングなんだけど、そんなGUIフレームワークはまだ存在していないから(あるかな？)、
ひたすらイベント駆動で頑張るしかないというのが、現実的な解だったりする

612 ：デフォルトの名無しさん：2010/09/11(土) 19:31:09

>>611
>バックグラウンドで重い処理を動かしつつ、同時に(並行して)GUIでの操作を可能にする、
>というのが目的なら、スレッドの導入は理解できるのだけれど

自己レスになるけど、上の部分は、「並行処理が必要な部分に限定してスレッドを導入し、
それ以外の全体構造はイベント駆動で実装するのなら理解できる」という意味

613 ：デフォルトの名無しさん：2010/09/11(土) 20:14:42

スレッドは危険、コルーチンは存在しない、消去法が現実的、
絶望した！

614 ：デフォルトの名無しさん：2010/09/11(土) 20:19:03

悲しいけど、それが現実なのよw
だからGUIがむずかしすぎるという話になって、以下ループ....

615 ：デフォルトの名無しさん：2010/09/11(土) 20:27:10

>>610
Webの世界なら、まだマイナーだけどSmalltalkのSeaSideに代表される継続渡しを応用した
Webフレームワークが、JavaやRubyとかでもボチボチ登場しつつあるんだけどねえ。
GUIはWeb以上に複雑だから、フレームワークとなると...

参考までに、Webフレームワークのケースに関する記事を紹介

・境界を越える: 継続とWeb開発、そしてJavaプログラミング
　　　-- プログラマーにとってはステートフル・モデルが、ユーザーにとってはステートレス
　　http://www.ibm.com/developerworks/jp/java/library/j-cb03216/

616 ：デフォルトの名無しさん：2010/09/12(日) 12:45:51

クライアント・サーバーも一種の並行処理だが、安全だ。
ということは、その安全なノウハウを一般のGUIに応用すればよい。
例えば「スレッドを作るよりもプロセスを作るほうが安全だ」とか。

617 ：デフォルトの名無しさん：2010/09/12(日) 13:04:19

>>615
Ajaxで解決じゃね？

618 ：デフォルトの名無しさん：2010/09/12(日) 18:39:07

だいたいわかった。
未だにリリースされ続けているVCLが最高ってことだ。

619 ：デフォルトの名無しさん：2010/09/12(日) 22:14:56

マルチスレッドも慣れてるほうだと思うけど、
とにかくデザインセンスがない。
これはどうしようもないんか…

620 ：デフォルトの名無しさん：2010/09/12(日) 22:53:02

使いやすい画面仕様について勉強したいんだけど、
Webデザイン系の学校てことになるのかね？
今までは、本や他のアプリを見ながらの独学だから、
もう少し体系だった知識を身につけときたいと思っている。

621 ：デフォルトの名無しさん：2010/09/12(日) 22:57:46

使いやすさならMacを使えばおｋ

622 ：デフォルトの名無しさん：2010/09/12(日) 23:31:29

>620
DesigningInterfaceかっとけ

623 ：デフォルトの名無しさん：2010/09/13(月) 00:10:20

>>620
省スペースな画面が使いやすい
エロゲーの箱みたいに宣伝のために場所を塞ぐデザインはやめてほしい

624 ：デフォルトの名無しさん：2010/09/13(月) 00:40:22

>>620
Macなら
Apple Human Interface Guidelines
ttp://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html

Windowsなら
Windows Vista User Experience Guidelines
ttp://msdn2.microsoft.com/en-us/library/Aa511258.aspx

ってところ？
探せば日本語訳もあると思うよ。

625 ：デフォルトの名無しさん：2010/09/13(月) 01:13:44

>>624
どちらもwebページのデザインの悪さにがっかり

626 ：デフォルトの名無しさん：2010/09/13(月) 14:37:08

>>616
最近のWebブラウザは、スレッドからプロセスへ移行しつつあるみたいだね。
Flash等のプラグインでbugがあった場合、スレッドだとブラウザ全体がclashするけど、
プロセスなら(メモリ空間が分離されているから)clashするのは該当するコンテクスト
(タブとかウィンドウ)だけで済むから、ブラウザ全体の安定性が向上する。

627 ：デフォルトの名無しさん：2010/09/13(月) 22:12:37

>626
おかげでChromeメモリ食いまくりですよ(；´Д｀)

628 ：デフォルトの名無しさん：2010/09/14(火) 04:14:30

>>626-627

http://userdisk.webry.biglobe.ne.jp/001/182/51/N000/000/000/123059667090116220038_20081230092125.png
http://4.bp.blogspot.com/_u2aiR-t24t0/Sz43UsHVoYI/AAAAAAAACdI/H9G_CSnysEQ/s1600-h/ChromeProcessesTaskManager4.jpg
http://www.tecue.com/wp-content/uploads/2010/03/chrome.jpg
http://neta-times.net/wp/wp-content/uploads/prosesmane.png

ネタ画像じゃなくて実際、拡張いれまくってるとひどいからな

そういやIE8もいつの間にか複数プロセス立ち上げるようになってるね。
FirefoxもFlashだけ別プロセスになって巻き込んで落ちることが減ったな。

629 ：デフォルトの名無しさん：2010/09/18(土) 00:02:10

3Ｄの描写と編集のためにＧＵＩでエディットできるような
そういうことに使える書籍とか教えて

出来ればＣ++の資産が使えるような

630 ：デフォルトの名無しさん：2010/09/18(土) 01:17:33

>>629
3D描画向けにOpenGL(あるいはそれを抽象化したフレームワーク)を扱えるツールキットは
数多く存在して書籍も豊富にある。でも3Dモデラーのような3Dモデルを対話的に編集する
機能を提供するGUIフレームワークは極めて限定されてしまう。

(3Dには詳しくない)自分が唯一知っているのは、Jun(じゅん)というVisualWorks(Smalltalk)上で動く
3Dフレームワークのみ。残念ながらC++には対応していないが、Javaへの移植版もある。
無償で利用できるから、まずは触ってみてそのアイデアや設計法を学ぶのがいいのではないかと思う。
公式サイトは以下。豊富な解説が(もちろん日本語で)用意されている。

・http://aokilab.kyoto-su.ac.jp/jun/index-j.html

書籍としては、Junの開発リーダである青木淳氏が書いた以下がお勧め。

・http://aokilab.kyoto-su.ac.jp/documents/BlackBook/index-j.html

631 ：デフォルトの名無しさん：2010/09/18(土) 01:40:22

へー青木さんいま京産大にいるんだ

632 ：20：2010/09/18(土) 13:58:18

>>22,23,24

良書の紹介感謝です。
そうそう、画面は大きければいいわけじゃないと最近気付きました。
学校は料金が高いし、やはり働きながらだと辛いかなｗ

633 ：デフォルトの名無しさん：2010/09/18(土) 14:54:39

学校に勤めれば良いのでは

634 ：デフォルトの名無しさん：2010/09/18(土) 20:02:20

フォトレタッチソフトを作りたいのですが
そのための書籍やサイトなどご存知でしたら教えて下しア

635 ：デフォルトの名無しさん：2010/09/18(土) 21:09:27

>>634
GIMPなどのソースを見るのが一番じゃないの？

636 ：デフォルトの名無しさん：2010/09/18(土) 21:30:39

>>629と>>634は同一人物みたいだね

637 ：デフォルトの名無しさん：2010/10/11(月) 09:52:35

VisualC++だけでGUIやろうとしてた俺だが
turboC++をどうにかインスコして、使ったら
これまたGUIが楽しくなった

今ではちんちんもおっきくなって、いい子とだらけです

638 ：デフォルトの名無しさん：2010/12/20(月) 07:53:43

フリーのGUIビルダー・RADツールを探していて疑問に思ったのだが

どうしてGUIビルダーの類は、レイアウト結果を中間形式で出力して、それを色んな環境・言語用に変換、もしくは実行時に解析してレイアウトする、
というアプローチを取らず、最初から特定の環境・言語にのみ特化したコードを直接出力してしまう事例が多いのだろう？

環境が異なる毎に、延々と、ツールの数だけ、車輪の再発明を繰り返してきたように見える…
それでいて、それらツールが吐き出した出力結果は、特定の環境・言語でしか利用できない
これはとんでもなく非効率ではないのか。もっと使い回しや共通化を模索していいのではないか？
・ XMLなりなんなりで、UIレイアウトと実処理は分離してアプリを作るほうが、皆幸せにならないか？
・ UIの使い勝手は試行錯誤で決まってくるところもあるが、その都度、実処理を含んだコードを弄るのはアホではないか？
・中間形式さえ決まっていれば、レイアウトツール単体の使い勝手を向上できるのではないか？
・一つのレイアウトツールを使えれば、どの環境でもGUIアプリが(見た目だけは)サクッと作れるようにならないか？

しかし、そういうアプローチを取っているのは、MSのWPFぐらいしか見当たらなかった…なぜ？
ハッカーは車輪の再発明が好きなのか？それともWYSIWYGを侮蔑して、難解なレイアウトもエディタで四苦八苦して構築することに無性の喜びを感じているのか？
プログラマーこそがデザイナーよりも使い勝手のいいUIレイアウトを作れるのだ、的自惚れがあるのか？どうもわからない…

639 ：デフォルトの名無しさん：2010/12/20(月) 08:19:12

中間形式を策定することは難しいのだろうか？
MIDIにおけるGM規格や、MSX規格のように、
「全ての連中が最低限できること」を羅列する仕様になって
貧相なことしかできなくなるのだろうか…？

なんだかスゲー無駄なことを、世界中でやっちゃってる気がする
どうしてこうなった

640 ：デフォルトの名無しさん：2010/12/20(月) 09:05:07

GUIのためだけに何か作るのは無駄だろ
クライアントとサーバーの分離、というアプローチが既にある
それならサーバー側はCUIになるから環境に依存しないだろ

641 ：デフォルトの名無しさん：2010/12/20(月) 11:42:37

>>638
つまりそれってWEBアプリのことでしょ。いろんなツールあるもんね。

642 ：デフォルトの名無しさん：2010/12/20(月) 13:38:26

>>638
一応Gladeってもんがあるぞ。GTK+用だけどな

643 ：デフォルトの名無しさん：2010/12/20(月) 14:27:44

中間形式の種類が増えるだけさ。
元の木阿弥。

644 ：デフォルトの名無しさん：2010/12/20(月) 20:13:17

>>640
Xの悪口はそこまでだ

645 ：デフォルトの名無しさん：2010/12/23(木) 14:58:23

>>640
どうしてそれがデスクトップアプリの仕組みでも主流にならなかったんだろう
それとも、これからそれが主流になっていくんだろうか…

でもその前にWebアプリが主流になるのだろうか
ブラウザだけあればどの環境でも似たような作業ができる
たしかに…極限まで共通化を成した姿かもしれないなあ…

でも世の中ネットが使える環境ばかりでもないような気もするが

646 ：デフォルトの名無しさん：2010/12/23(木) 16:13:00

>>645
ここはGUIスレ。
ネットワークの話題はスレ違い……という考え方が主流だからじゃないか。

647 ：デフォルトの名無しさん：2010/12/23(木) 16:28:57

ネットが使えない環境だったらなおのこと
クライアントとサーバーの分離なんて非効率。

648 ：デフォルトの名無しさん：2010/12/23(木) 16:43:28

    http://www.youtube.com/watch?v=0mEHKFibv0g
    http://www.youtube.com/watch?v=JQvLt7DQhaI
    http://www.youtube.com/watch?v=MZHEzDmXO2w

649 ：デフォルトの名無しさん：2010/12/23(木) 16:44:33

主流、主流とはいうけど、Windowsでデスクトップアプリをまともに作れるのってMS製品だけじゃん。
だから他のプラットフォームや言語に対応する意味が無い。

650 ：デフォルトの名無しさん：2010/12/23(木) 17:06:42

分離すると一々ソケット作ってプロトコルも決めないといけない。
レジスタやスタックに積んでCALLするだけの簡単さに勝てるわけがない。

651 ：デフォルトの名無しさん：2010/12/23(木) 17:22:08

ネットはあくまでマルチタスクの手段。
問題は、シングルタスクのプラットフォームに対応する意味があるのか？ってこと。

652 ：デフォルトの名無しさん：2010/12/27(月) 13:04:57

ウインドウシステムとアプリのプロセス間通信のデータ量が少ないなら、
ネットワーク越しでいいけど、
大量ならネットワークは足枷になる。
linuxもXのネットワーク透過性捨てて、ローカル描画に変えようとしてる。

653 ：デフォルトの名無しさん：2010/12/27(月) 13:40:54

ネットワーク透過で思い出したんだが
よく "参照透過" といって副作用を制限するのは、メモリを共有したいからなんだな。

逆に、メモリを共有しないなら副作用は無害で
共有しないでコピーするということは、コピー先はローカルでなくてもよい。

654 ：デフォルトの名無しさん：2010/12/28(火) 01:51:15

>653　
なんか色々ちがうとおもうぞ・・・

655 ：デフォルトの名無しさん：2010/12/28(火) 11:43:16

>>652
「むずかしすぎる」じゃなくて「足枷になる」だけなら、大きな進歩だろ
ここでその足枷を捨てろと言うのは、ちがうと思う

656 ：デフォルトの名無しさん：2010/12/28(火) 18:56:28

サーバとクライアントに分離とかそういう話ではないように思う

例えば、XRCを読んでGUIのレイアウトをする機能が
Tk、Gtk、Qt、その他モロモロでデフォルトで用意されてれば済む話じゃないのか
(自分が調べられてないだけで既にあるのかもしれないけれど)

画像編集ツールが最低限psd対応していれば
レイヤーを保持したデータをあちこちで使い回せるように
GUIデザイン・レイアウトにもpsdみたいなデファクトスタンダード？があれば
デスクトップアプリ、Webアプリ、OS、言語に関係なく、そのレイアウトデータが流用できるんじゃないか

どうして各ツールがコードそのものを吐き出して
プログラマーがそのコードに直接実処理を書いていくのか、その思想がわからない
データとプログラムに分離しようというアプローチをあまり見かけないのが不思議なんだけど
そうはできない理由があるんでしょうかね？＞オープンソース界隈

657 ：デフォルトの名無しさん：2010/12/28(火) 20:19:45

wxWidgetsはXRCでいけりゅ

658 ：デフォルトの名無しさん：2010/12/28(火) 21:44:41

procedure callで分離するか、octet streamで分離するかだろ
RPCやORMと同じ気がする

659 ：デフォルトの名無しさん：2010/12/29(水) 21:47:42

>>656
VBやDelphiやC#だってバラバラだし、何故オープンソース界隈が目の敵になってるんだw

660 ：デフォルトの名無しさん：2010/12/30(木) 05:29:38

オープンソースなのになんで規格を合わせられないんだ、って話じゃないの？

というか俺がそう感じてるんだけどな
オープンなのに独自規格乱立とかバカかｗ　どれだけ車輪の再発明だよっていう

ま、「他人のためにソースを提供し、デバッグすれば、社会はよくなりますよ」とか
社会主義的お花畑だからなｗ　そうそう上手くいくわけもないんだが

661 ：デフォルトの名無しさん：2010/12/30(木) 06:06:46

しかし実際自分の作った物が他人に利用されると快感になるからな

662 ：デフォルトの名無しさん：2010/12/30(木) 06:46:59

>>660
オープンソースな事と、規格の標準化は全く関連がない。
言ってることめちゃくちゃだし。

663 ：デフォルトの名無しさん：2010/12/30(木) 10:33:10

むしろステレオタイプなことを言ってる気がする
競争するなら全部企業秘密にするのがふつうで
オープンにするなら全員で協力するのがふつうだと

664 ：デフォルトの名無しさん：2010/12/31(金) 00:01:08

>>656
GUIプログラミングした事あるのかなぁ
GUIコンポーネントはAPIなどに直結してる
APIを統一というのは絵に描いたぼた餅かそれ以上

良い開発環境であればGUIコーディングはGUIでできるから尚更分離しにくい
GUI，オブジェクトとかを統一的にGUIで繋げることができるNeXTSTEP IB（今や
MacOSに受け継がれている）は評価が高かった
統一できるところで規格化すれば GUI のデザインはしにくくなるし改良しにくくなると思う
ちょっと変更するだけで委員会とかで議論して決めなければならないわけだからね

665 ：デフォルトの名無しさん：2010/12/31(金) 16:40:23

>>655
足枷になってUI/UXが劣り、競合ソフトとの争いに負けるから、
ソフトが死ぬ。そんなソフトしか作れないなら、プラットフォームが死ぬ。
linuxのようにデスクトップとしての土俵を諦めるか、
javaのようにビジネスアプリに割り切ってニッチに専念するか。

>>656
動的に変化するUIはどうすんの？
webブラウザのように各言語のフレームワークにdomの実装を強制するの？
また、リフレクションの有無でUI要素と制御のバインドもだいぶ違いがでる。
結局のところ、html+domに収束すると思う。

666 ：デフォルトの名無しさん：2010/12/31(金) 17:59:17

>>665
誰もAPI統一しろって言ってないだろ
GUIライブラリにやり取り可能な互換規格を作るべきって話

モニタ・キーボード・マウスがほぼ全世界共通なのにGUIだけ独自仕様でバラバラって現状がおかしい
オープンソースの責任とまでは言わないが、オープンにしてる意味なくね？　って気はするわ

667 ：デフォルトの名無しさん：2010/12/31(金) 22:57:21

ラッパー層がいくつもあるだけだろ

668 ：デフォルトの名無しさん：2010/12/31(金) 23:32:56

>>666
いいたいことはわかるし統一してくれとは思うけど

> モニタ・キーボード・マウスがほぼ全世界共通なのにGUIだけ独自仕様でバラバラって現状がおかしい

いきなりハードウェアの話になってきたな。
モニタ・キーボード・マウスがよく使われるほんの一部であって、
「GUIだけ」独自仕様ってこたあないだろw

マウスですらちょっとしたものはメーカー毎にドライバ作ってるし、
そういうものはUnixでは・・・

モデム、NIC、グラフィックカード今までもいろいろ通りすぎてきたよ

669 ：デフォルトの名無しさん：2011/01/01(土) 00:28:52

>>666
GUIとAPIは完全に切り離せるのか？
現実的に合意できるのか？
できたとして動きが取れなくならないのか？
統一された最低限で皆満足できるのか？

GUIコンポーネントはマウスに比べて複雑さが全然違うと思うよ
あとハードに比べてソフトは変更は簡易な分変更のペースも速いからな

670 ：【だん吉】：2011/01/01(土) 00:32:48

マウスだってMacとか1ボタンだったりして統一されてないぞ

671 ：デフォルトの名無しさん：2011/01/01(土) 04:12:45

>>670

672 ：デフォルトの名無しさん：2011/01/14(金) 02:14:38

>>664
>モニタ・キーボード・マウスがほぼ全世界共通なのにGUIだけ独自仕様でバラバラって現状がおかしい

大抵のバンドはギターとベースとドラムとボーカルの構成で一緒なのに
生み出される音楽は全然違うみたいな…

モニタ・キーボード・マウス→ツール
GUI→表現

>>668
Mac はもうトラックパッドの時代。マルチタッチは超便利だよ。

673 ：デフォルトの名無しさん：2011/01/14(金) 03:13:38

>大抵のバンドはギターとベースとドラムとボーカルの構成で一緒なのに

一緒じゃないんだよ実は

674 ：デフォルトの名無しさん：2011/01/16(日) 19:42:47

コンソールのC言語プログラミングを終わらせただがGUIが急激に難しい・・・
私の知能ではとてもムリ・・・

675 ：デフォルトの名無しさん：2011/01/16(日) 20:28:37

>>674
プログラムの構造的な違いは次の二点だけだけど、

・処理する順番に記述するのではなく、イベントに応じた細かい処理を沢山揃える
・プログラムを画面表示、イベント処理、内部データの変更の3つの部分に分けて記述する

何をするにもプラットフォームの流儀を憶えないと
いけないのは、慣れるまでは面倒だよね。

676 ：デフォルトの名無しさん：2011/01/16(日) 20:59:28

そのプラットフォームの流儀を無視した要求出す顧客を説得する方法を教えてくれorz

677 ：デフォルトの名無しさん：2011/01/16(日) 21:03:44

>>676
具体的にどんな要求？

678 ：デフォルトの名無しさん：2011/01/16(日) 21:04:11

>>675
上はCUIのwhile～fgets～switchと大差ないよね
下は管理しやすい形にした一つのパターンというだけで
GUIとは直接関係無いよね

679 ：デフォルトの名無しさん：2011/01/16(日) 21:09:37

>>678
それぞれ、

上はイベント駆動
下は MVC

の説明。

もちろん CLI でもイベント駆動や MVC を使う事はあるけど、
>>674 を悩ませているのはここら辺じゃないかなと思って
書いてみた。

680 ：デフォルトの名無しさん：2011/01/17(月) 01:58:26

そうだね
>>674 は CUI を利用した GUI も作れないだろうね

681 ：デフォルトの名無しさん：2011/01/17(月) 02:20:47

>>680
ttp://s2.etowns.slyip.net/~c_cpp_homework/cgi-bin/joyful/img/27.txt

682 ：デフォルトの名無しさん：2011/01/17(月) 04:08:50

>>675
ありがとうございます！
イベントプロシージャh

683 ：デフォルトの名無しさん：2011/01/17(月) 15:20:40

GUI自体は簡単だよ
何事も慣れだよ

684 ：デフォルトの名無しさん：2011/01/17(月) 20:43:46

ただ単にコード量が多いというだけでも難度は上がるけどね
晴天と濃霧じゃ運転の難度は異なるって意味で

たまにそのへん度外視して話す人がいるから困る

685 ：デフォルトの名無しさん：2011/01/17(月) 21:12:05

最初に書いたときには、大量のおまじないに戸惑った記憶がある。

686 ：デフォルトの名無しさん：2011/01/17(月) 21:17:37

いやいや、イベントドリブンは難しいですよ。
どっから呼ばれるか全く分かりませんですしね・・・

687 ：デフォルトの名無しさん：2011/01/17(月) 21:23:19

メッセージボックスとかモーダルダイアログを表示したときの
メッセージループを理解してないやつが多すぎるのは確か。

688 ：デフォルトの名無しさん：2011/01/18(火) 03:35:07

何事も単純なものがいいよね

689 ：デフォルトの名無しさん：2011/01/18(火) 11:21:30

道を歩きやすいように単純にするのであって
単純さのために退路を断つのはただの自殺行為

例えばjavascriptの魅力はイベントドリブンではなく
ajaxやcgiという逃げ道が確保されている点にある

690 ：デフォルトの名無しさん：2011/01/18(火) 14:50:24

>>674
OS依存のGUIアプリなら、C#かVB.netやれ。驚くほど簡単だぞ。

どうしてもコンソールのようなプログラムでGUIやりたいなら、今時ならwebアプリの形式が糞みたいにらくだぞ。
サーバー側を処理したのをJSONで返すだけにして、GUIはJavaScriptで作る。
RESTみたいな構造でJavaScriptとのやりとりはJSONでやってるだけだし、GUIはjQueryや周辺のライブラリを使うと楽。

いまどきメインの言語でGUI作る必要ない時代。
それこそC言語でやる必要がまったくないが・・・

691 ：デフォルトの名無しさん：2011/01/18(火) 21:30:45

つ ttp://SmartClient.com
つ ttp://ExtJS.com

692 ：デフォルトの名無しさん：2011/01/18(火) 22:15:34

低スペックなマシンなので、Cで書かれたものの方が嬉しい

693 ：デフォルトの名無しさん：2011/01/19(水) 00:19:25

Cで書かれたものなら何でも速くなると思うなよ

694 ：デフォルトの名無しさん：2011/01/19(水) 00:22:51

Cでも遅いプログラムは書けるけど、
同じプログラムならCの方が速い

695 ：デフォルトの名無しさん：2011/01/19(水) 01:23:50

>>694
webアプリのスクリプトは氷山の一角で
その下にあるブラウザとサーバはすでにCで書かれている。
同じプログラムを書くのではなく
複雑なブラウザや複雑なサーバとは違うものを書くのだ。

696 ：デフォルトの名無しさん：2011/01/19(水) 01:34:16

俺のブラウザはC++で書かれているけど?
サーバサイドはJavaが多いし、JavaVMはC++だ

697 ：デフォルトの名無しさん：2011/01/19(水) 01:41:46

だからなに？

698 ：デフォルトの名無しさん：2011/01/19(水) 01:44:02

>>696
C++って方言が多いよね
テンプレートや継承や例外やコンストラクタまで制限することがある
どこの方言で書かれているのかな

699 ：デフォルトの名無しさん：2011/01/19(水) 02:29:45

関西弁ですが、何か？

700 ：デフォルトの名無しさん：2011/01/19(水) 05:24:05

名古屋だぎゃ！

701 ：デフォルトの名無しさん：2011/01/19(水) 14:28:31

やっぱりC言語でないと時代に勝てない

AndroidがiPhoneに勝てない点: ニュースの社会科学的な裏側
http://anlyznews.blogspot.com/2010/12/androidiphone.html

>>696
10年前も同じこと言ってる奴がいたし、20年前も同じこと言ってる奴がいたわ
Officeは.NetじゃなくC++だの、OSはCで書かれているだの、Cなんか使っていないアセンブラで組んでるだの

702 ：デフォルトの名無しさん：2011/01/19(水) 21:20:24

良く分からないんだけど
DOSをC++で書くなんてジョークなかったっけ？

703 ：デフォルトの名無しさん：2011/01/19(水) 23:38:50

>>697
>>695がブラウザがCで書かれていると言うから、間違いを指摘しただけ。
FirefoxもWebKitも主にC++で書かれてるよ。

>>701
それ、元レスとの繋がりが分からないんだけど、君は誰と戦ってるのかな?

704 ：デフォルトの名無しさん：2011/01/19(水) 23:59:34

スプレッドシートって何であんな複雑なの？

705 ：デフォルトの名無しさん：2011/01/20(木) 02:58:21

どこが複雑なのかわからんが。使える機能だけ使ってればいいのでは？

706 ：デフォルトの名無しさん：2011/01/20(木) 03:26:12

moremosouomou

707 ：デフォルトの名無しさん：2011/01/21(金) 20:00:30

>>703
695じゃないけど、w3mもLynxも、Epiphany,midoriも風博士も、Cで実装されているよ
gnumericみたいなスプレッドシートもね(webkitやgeckoが何で書かれてるかなんて知らね)
Cで書いてもうまくいくんだから、C++なんて単に覚えることが増えるだけの気がする

708 ：デフォルトの名無しさん：2011/01/21(金) 22:05:26

GTK+やkhtml派生のwebkitをなんでCだと思ったのか問いただしたい

709 ：デフォルトの名無しさん：2011/01/21(金) 23:58:08

表示させるだけなら簡単なんだけど
中にボタンとか入れたりしてイベント処理とかあると
まあ大変

710 ：デフォルトの名無しさん：2011/01/22(土) 01:12:40

イベントハンドラは一個だけでもいい
型にこだわって細分化するから大変なんだ

711 ：デフォルトの名無しさん：2011/01/22(土) 02:30:44

Python最高

712 ：デフォルトの名無しさん：2011/01/22(土) 09:38:42

CでもＣ++でも同じものを作れる、結果は同じだから
どちらも同じとかいうのは頭が悪すぎる。

日本からアメリカにいくのに、どの乗り物を使っても
同じと言っているような物。

たしかに結果は同じだ。
だが、そこに至る道のりが大きく違うだろ。
それが重要なんだ。

713 ：デフォルトの名無しさん：2011/01/22(土) 09:39:44

つまりどういうことです？

714 ：デフォルトの名無しさん：2011/01/22(土) 11:21:27

>>707
>webkitやgeckoが何で書かれてるかなんて知らね

C++だよ。
ある程度経験を積んだプログラマなら、常識に近い話だと思うけど。

715 ：デフォルトの名無しさん：2011/01/22(土) 11:26:24

>>707
>Cで書いてもうまくいく

名前空間やオブジェクト指向がデフォルトで備わっていないCで
Firefox級の規模のプログラムを作り上げるのはしんどいだろうね。
自分ならやりたくないわ。

どんな根拠で上手く行くと思ってるのかな。

716 ：デフォルトの名無しさん：2011/01/22(土) 11:41:54

>>715
横レス失礼する。

その昔UNIXと呼ばれたオペレーティングシステム(OS)があり、
これはコードの大半はCという手続き型言語で記述されていた。
これは非OOPな手続き型言語であっても、開発者の力量しだいで
大規模ソフト開発が可能である(=うまくいく)という事を実証している。

まぁ今時の若人達にすれば、目が開いた時にはすでにOOPが存在していた訳だから、
OOP無しの大規模開発プロジェクトのイメージが想像しづらい、というのは理解できるがね。

717 ：デフォルトの名無しさん：2011/01/22(土) 12:14:08

いまどきＣでＧＵＩってアホですか

718 ：デフォルトの名無しさん：2011/01/22(土) 12:28:00

仮想関数やクラス無しで似たような処理書きまくるのは大変だな
コーディングルール縛って構造体でがんばって同じ事ができても
設計者のルールと一般的なC++プログラマが持ってる共通理解とどちらが
他人に理解されやすいかだよね
特にGUIはイベントやGUI部品で似たような処理多いからどれも似てるし

719 ：デフォルトの名無しさん：2011/01/22(土) 12:33:42

その人に合った言語でプログラミングすればいいのではないかと....。

たとえば関数型言語(HaskellやML)に慣れてしまったプログラマからすれば、

　いまどきＣ＋＋でＧＵＩってアホですか？

になる訳で。

720 ：デフォルトの名無しさん：2011/01/22(土) 12:37:42

>>716
確かにCで大規模プログラムを作成する事は可能だと思います。
UNIX以外でも、ApacheやMySQLなんかもCですしね。

ただ、ウェブブラウザみたいなGUIアプリの場合は、規模が
大きくなると、Cで作るのはちょっとしんどいんじゃないかと
思います。

OSでも、IOKitみたいに、ドライバをC++で書きたいという
欲求はそれなりにありそうですし。

721 ：デフォルトの名無しさん：2011/01/22(土) 12:42:07

>>719
関数型言語でもGUIはOpenGLやGtk+の関数を呼び出してるだけでしょ。
結局、手続き的なコードになっちゃうんじゃないの?

722 ：デフォルトの名無しさん：2011/01/22(土) 12:56:12

>>718
>一般的なC++プログラマが持ってる共通理解

例外を使うなとか多重継承を使うなとか誰かが言えば
C++の共通理解の範囲はどんどん狭くなるんだろ
そこで、共通ではない機能を潔く捨てるのと捨てないのと
どちらが他人に理解されやすいか

723 ：デフォルトの名無しさん：2011/01/22(土) 14:11:55

C++だな。

724 ：719：2011/01/22(土) 14:11:58

>>721
ML(Standard ML)という関数型言語の場合、(expr1 ; expr2 ; expr3) という構文が「標準」で定義されている。
これは、expr1/expr2/expr3を順番に評価し、最後の評価値(この場合はexpr3)を全体の評価値とするもの。
いわば、exprN を手続き的にコールするための構文であり、ごく普通に利用されている。

広く蔓延している関数型言語に関する誤解の一つが、関数型言語では「自然な」手続き型プログラミングが不可能、
という間違った常識。関数型言語を分類する基準の一つに「評価法」という概念があり、
この視点でよれば、関数型言語は作用順評価(=非遅延評価)言語と正格順評価(=遅延評価)言語の２つに分類される。
自然な手続き型プログラミングが不可能という常識が通用するのは、Haskellに代表される正格順評価言語の場合のみ。
Haskellの場合、手続き型プログラミングにはIOモナドのような難解で冗長な仕掛けを使わなければならない。

最初の段落でMLの (expr1 ; expr2 ; expr3) という構文を紹介したように、(HaskellやScalaといった例外を除いた)
大半の関数型言語は作用順評価言語であり、自然な手続き型プログラミングが可能である、というのが正しい常識だよ。
これはML系言語族であるStandard ML/OCaml/F#だけじゃない、Lisp/Scheme、さらにはSmalltalk/Rubyにも通用する。

725 ：デフォルトの名無しさん：2011/01/22(土) 14:30:39

721　手続き的なコードになっちゃうんじゃないの?
724　関数型言語では「自然な」手続き型プログラミングが不可能、という間違った常識。
　　自然な手続き型プログラミングが可能である

狂ってるｗ

726 ：デフォルトの名無しさん：2011/01/22(土) 14:38:02

タモリの嘘です♪
のコピペを思い出したｗ
うんちくを語りたくて仕方なかったんだろうな

727 ：719：2011/01/22(土) 14:42:54

>>725
>721の「手続き的なコードになっちゃうんじゃないの?」という問いに対して、

　関数型言語(ML)でGUI操作の箇所は普通に手続き的なコーディングしてますよ。何か問題でも？

という答えは、あえて書かなくても(暗黙の内に)理解してもらえると思ったけど、>>725には難しかったかな....

728 ：デフォルトの名無しさん：2011/01/22(土) 14:45:44

Lisp で言う所の progn の説明をしているだけだから、
うんちくと言って良いのかすらも怪しいなw

729 ：デフォルトの名無しさん：2011/01/22(土) 14:48:51

>>727
>>721 が『手続き的になっちゃうなら、関数型言語の旨味は
少ないんじゃないの?』と言う問いかけであるとは考えなかったの?

730 ：デフォルトの名無しさん：2011/01/22(土) 14:48:58

721　毎日そんなに食べ続けてたら太っちゃうんじゃないの？
724　「自然」に太ることが不可能、という間違った常識。
　　自然に太ることが可能である

ガ板向きだな

731 ：デフォルトの名無しさん：2011/01/22(土) 14:55:25

ム板にたむろしている暇人（含む俺）は関数型言語の一つや二つ履修済みでしょ
そこへ大上段に構えて説法するとはチャレンジャーだなw

732 ：デフォルトの名無しさん：2011/01/22(土) 15:26:47

話を元に戻すと、
ＧＵＩはオブジェクト指向と相性がいいのに、
わざわざＣや関数型を使うことないだろ。と

733 ：デフォルトの名無しさん：2011/01/22(土) 15:41:23

UIにオブジェクト指向もあうがReactiveもあう。
要は組み合わせだろ。

734 ：719：2011/01/22(土) 15:41:35

>>729
「関数型言語の旨味」とは何か？という話であれば、
これはGUIに限らないけどMLのような型推論を備えた型付き関数型言語の場合、
実行時エラーの多くがコンパイル時に検出できるというのが、自分にとっての最大の旨味だね。
このエラー検出機能はGUI処理が手続き的であっても別にかまわない訳で。

これが可能なのは、関数型言語の持つ参照透明性を前提にしたプログラミングスタイル。具体的には、
デフォは不変(imutable)オブジェクトで、必要な場合に限って可変(mutable)オブジェクトを使う。

このスタイルに慣れると、C++の難解かつ不完全である為にヌルポ発生を当然とする考え方がアホに見えてくる。

735 ：デフォルトの名無しさん：2011/01/22(土) 15:52:43

もう滅茶苦茶だなｗ

736 ：デフォルトの名無しさん：2011/01/22(土) 16:12:46

>>734
参照透明を真面目に守ってるのって Haskell くらいじゃないの?
GUI なんて状態の固まりなんだから、参照透明を守りつつなんて
言っていたらプログラムが複雑になるだけじゃない?

737 ：719：2011/01/22(土) 16:14:02

>>732
>ＧＵＩはオブジェクト指向と相性がいいのに、

これは「GUIとオブジェクト指向パラダイムの相性は良い」という意味で正しい思う。でも、

>わざわざＣや関数型を使うことないだろ。と

これは？？？だな。手続き型(命令型)や関数型(作用型)というのは計算モデルの分類であって、
計算モデルと(パラダイムである)オブジェクト指向を同列に比較すること自体が無意味だから。

手続き型言語であるCにオブジェクト指向パラダイムを取り込んだC++/Objective-Cがあるように、
関数型言語にも、MLにオブジェクト指向パラダイムを取り込んだOCaml(Objective Caml)やF#がある訳で。
C++がGUIと相性が良いのであれば、同様にOCaml/F#もGUIと相性が良いと言えるのではないかと。

あるいは手続き型言語であるCであってもGTKのGObjectのように擬似的なOOPが可能であるように、
関数型言語であるStandard MLであっても擬似的なOOPは可能だ。("OO Programming styles in ML" でググレ）
この場合、OCaml/F#よりコードは冗長になるけど、>>734で書いたコンパイル時の型検査機能は生きるから、
GTK by Cで多発する型不一致による実行時エラーは絶滅し、参照誤りによる実行時エラー(=ヌルポ)も激減する。

738 ：デフォルトの名無しさん：2011/01/22(土) 16:15:48

>>734は動的型付けか静的型付けかの問題で、関数型言語・参照透明性・型推論は
一切関係ないだろ

そもそも「GUIにおいての関数型言語の旨みとは何か」という話なのに、
GUIに限らないけどなどと前置きすること自体がおかしいし

739 ：デフォルトの名無しさん：2011/01/22(土) 16:29:55

OOP ってシンタックスシュガーでもあるから、擬似的な OOP って使い勝手が悪いのよね。
C で GObject をチマチマ弄るのが嫌だから Vala が作られたんでしょう。

740 ：デフォルトの名無しさん：2011/01/22(土) 16:35:04

>>738
>>734 は静的型付けだけでなく、強い型付けかどうかも意識してるんじゃないかな。
それでも関数型言語である必然性は無いし、GUI とも関係無いですけど。

741 ：デフォルトの名無しさん：2011/01/22(土) 16:52:25

>>737
これは OCaml の GUI のサンプルコードだけど、これを見て
関数型言語の旨味を感じられる人は居るのかな?

http://plus.kaist.ac.kr/~shoh/ocaml/lablgtk2/lablgtk2-tutorial/a2692.html

ref を使って破壊的代入をしているから参照透明性も無いし、
C で書くのに比べて簡潔と言う訳でもないし。

742 ：719：2011/01/22(土) 16:57:56

>>736
>参照透明を真面目に守ってるのって Haskell くらいじゃないの?

その生真面目さが実用的なプログラミングにおけるHaskellの2番目の欠点だね。(1番目は>>724に書いた評価法)

MLの場合、(>>734でも書いたけど)デフォは不変オブジェクトであって参照透明性が保証される。
ただし、明示的に(ref型を)宣言することで可変オブジェクトも生成できる。ただしこの場合、参照透明性は失われる。
言い換えると、不変オブジェクトが推奨だけどプログラマの判断で(=自己責任で)可変オブジェクトも許容する、という思想。

手続き型の場合は、どうせ参照透明性なんて保証できないんだから、すべて可変でいいじゃん、という思想。

まとめると、Haskellは参照透明性をプログラマに強制し、手続き型言語は参照透明性を放棄し、MLは参照透明性を
尊重しつつ例外も許容するという大人の考え方。つまり世の中は0と1だけじゃない事を理解している。
参照透明性が100%保証されなくても、90%だけでもプログラミングは大いに楽になる。
プログラマは、残る10%の部分に集中して慎重にプログラミングを進めればいい、という考え方。だから、

>GUI なんて状態の固まりなんだから、参照透明を守りつつなんて言っていたらプログラムが複雑になるだけじゃない?

に関しては、まったくもってその通りだと思うよ。(仮に「守りつつ」=「保証」という意味であるならば....)

また、「Haskellが参照透明性を強制するからすべての関数型言語もそうに違いない」という常識も、
広く蔓延している関数型言語に関する誤解の一つだね。Haskellなんて例外的な言語なのになぁ。
（こんなこと書くと、また狂ってるwとか滅茶苦茶だなwという反応が大半なんだろね....www）

743 ：デフォルトの名無しさん：2011/01/22(土) 17:18:47

>>742
で、>>738に対する反論は無いのか？
>>724もそうだけど明らかに論理性を欠いているから、狂ってるだの滅茶苦茶だの
言われるんだろ

744 ：デフォルトの名無しさん：2011/01/22(土) 17:20:38

>>742
スレタイ読めてる？

745 ：デフォルトの名無しさん：2011/01/22(土) 17:29:04

> また、「Haskellが参照透明性を強制するからすべての関数型言語もそうに違いない」という常識も、
> 広く蔓延している関数型言語に関する誤解の一つだね。
こんな話初めて聞いたけど、本当にこんな間違った常識が広く蔓延してるの？
少なくともこのスレには広まっていないようだけど

746 ：719：2011/01/22(土) 18:08:51

>>740
サポありがと。

>>738,743
>>734のカキコ内容は、動的型付けと静的型付けという「いつ型検査をするか？」の違いとは一切無関係だよ。
動的型付けや静的型付けといった話題は、たとえばLisp/Scheme(動的) vs. Haskell/ML(静的)みたいな文脈で用いる。
>>734で話題にしているC++ vs. ML はどちらも静的型付け言語だから、動的/静的の論じる事自体が無意味だね。
>>734,743は、動的型付け/静的型付けという用語の意味を間違って理解しているのではないかと。

>>734では、(>>740がサポしてくれたように)型付けの「強さ」について書いている。
C++は型付けの「弱い」言語だから、静的型付けであるけど型検査を通過したプログラムであっても実行時エラーが多発する。
それに対して、(同じ静的型付けであっても)型付けの「強い」MLは、型検査を通過したプログラムであれば(C++と比較して)
実行時エラーが劇的に減少する。(0除算エラーやベクタ等での範囲外エラーはあるから、ゼロとまではいかないが....)

その「強い型付け」の背景にあるのがMLの型システム/参照透明性であり、そういった強力な型システムを実現できているのは
(今のところ)関数型言語しかない。型推論については、その型システムを前提とした機能であり、冗長な型宣言を
(まるで動的型付き言語のように)省略可能にしつつ型検査を保証するという、C++と比較した場合の優位性を示している。
>>734,743は、MLに代表されるモダンな関数型言語の型システムについて勉強し直したほうがよいと思う。

747 ：デフォルトの名無しさん：2011/01/22(土) 18:14:05

強い型付けの言語がいいなら Java でも良いな。
型推論は記述を省略する為の物だから、型エラーの検知とは無関係。

748 ：719：2011/01/22(土) 18:19:18

>>738,740,743

あと「そもそもの話(>>719)」について、「GUIにおいての関数型言語の旨みとは何か」なんて何も触れていませんけど何か？
自分の考え方は、
・GUIとオブジェクト指向パラダイムの相性は良い(>>737)
・GUIにおいて手続き型言語と関数型言語とを比較してプログラミングスタイルの優位性に大差は無い(>>737)
・そうであれば、(1) 強力な型検査機能があり、(2) 作用順評価(=非遅延評価)であり(>>724)、
　(3) 可変オブジェクトも許容する(>>742)のだから、

　　==> GUIでもプログラミング言語としてML系を選ぶのが現実的に適切ではないのだろうか

というもの。

749 ：719：2011/01/22(土) 18:34:09

>>747
では、ナゼJavaでは、チョット難しい事をしようとしただけでNullPointerException(ヌルポインタ例外)が
頻発するんでしょうかねえ。こんなのコンパイラが検査してくれてもいい、いやするのが当然だろ、なんて思いませんか？

率直に言って、Haskell/MLのような静的型付き関数型言語と比較すると、C++もJavaも大差なく
弱い静的型付けの言語でしかありません。C++とJavaの比較はドングリの背比べに見えます。

>>734,743と一緒に、MLに代表されるモダンな関数型言語について勉強されることをお勧めします。
たとえば以下のWeb記事は、入門として良いかもしれません。

・ITpro - 数理科学的バグ撲滅方法論のすすめ
　http://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248230/

750 ：デフォルトの名無しさん：2011/01/22(土) 18:39:27

NullPointerException の原因は型エラーだけじゃないだろw

751 ：デフォルトの名無しさん：2011/01/22(土) 18:39:38

>>746
>>746も挙げてるけどJavaは型推論も関数型言語も参照透明性もすべて当てはまらないが（>>734の）
> 実行時エラーの多くがコンパイル時に検出できる
という目的は実現できている。（nullを許容するかどうかは全く別の話）
なぜならこれは静的型付け言語の特徴だから。
>>734がおかしいことは明らか。

752 ：デフォルトの名無しさん：2011/01/22(土) 18:40:28

C/C++は分かる、でもC/C++&Gtkは分からない
Haskell&Gtkを薦められました

C/C++は分かる、でもC/C++&wxWidgetsは分からない
Haskell&wxWidgetsを薦められました

C/C++は分かる、でもC/C++&SDLは分からない
Haskell&SDLを薦められました

狂ってる！

753 ：デフォルトの名無しさん：2011/01/22(土) 18:44:55

昔、Java は関数型言語であるっていうネタがあった様な・・・

曰く、Java では変数には全て final を付ける必要がありますが、
final を省く事で可変オブジェクトも許容します、とかナントカw

754 ：719：2011/01/22(土) 18:50:29

>>741
遅くなったが、リンク先のコードを自分なりに読んでみた。
OCamlについてはサンプル程度のプログラミングレベルでしかないから間違ってるかもしれないけど、
少なくともこのサンプルプログラムだと、refを使うのはデータ型pixmapに限定されているよね。
ref型の宣言は3ヶ所で破壊的代入(:=)も1ヶ所でしか使われていない。

>>742でも書いたけど、参照透明性が100%保証されなくても、90%だけでもプログラミングは大いに楽になるのでは？
たとえば今回の例では、データ型pixmapを扱う部分(=10%)についてだけ慎重にコーディング＆レビューする。
他の大半の部分(=90%)はデータ型に誤りが無い事はOCamlコンパイラが保証してくれる。
これだけでも、C/C++/Javaのような手続き型言語と比較すれば、自分にとっては旨味に感じられるよ。

あと、記述の冗長性がCと大差が無いことは認める。でも、それはGUIライブラリの設計に依存すると思う。
必要であれば、GTKの上にOCamlらしい(=関数型言語らしい)宣言的な独自ライブラリを被せればいいんじゃないかと。

755 ：デフォルトの名無しさん：2011/01/22(土) 18:55:30

>>748
それって OCaml がマルチパラダイムな言語だから成立している話であって、
純粋関数型的なコーディングは捨てている訳だよね。
それなら別に OCaml である必要は無い訳で、言語ネイティブな GUI ライブラリを
多数持っている C++ や Java を選ぶのが現実的に適切だと思うわ。

型推論とクロージャがちょっと羨ましいかなといった程度。

756 ：デフォルトの名無しさん：2011/01/22(土) 19:02:29

>>754
一カ所なら良いと言うのは MLer 特有の解釈だと思われ

757 ：719：2011/01/22(土) 19:06:41

>>751
>> 実行時エラーの多くがコンパイル時に検出できるという目的は実現できている。

NullPointerExceptionは極端な例だとしても、Javaコンパイラの型検査なんて、
Haskell/MLと比較すると、不完全な代物にしか見えないよ。
関数型言語の型システムを知らない人であれば、比較対象はC/C++コンパイラだろうから
Javaコンパイラの型検査は優秀に見えるかもしれないけど、
(>>749で書いたように)ドングリの背比べにしか見えない。

もしJavaが得意なお人なら、JVM上で動く Scala なんていう関数型言語もあるよ。
まあ、無理に関数型言語を勉強汁とは言わないけどね....。でも>>751のカキコはチョット恥ずかしいYo

758 ：デフォルトの名無しさん：2011/01/22(土) 19:24:30

>>752
> あと、記述の冗長性がCと大差が無いことは認める。でも、それはGUIライブラリの設計に依存すると思う。
> 必要であれば、GTKの上にOCamlらしい(=関数型言語らしい)宣言的な独自ライブラリを被せればいいんじゃないかと。
GTKを扱えない人にHaskellらしいGTKラッパが書けるとでも思ってるの？
GUIアプリを書くのにHaskellが向くというなら
Haskellらしく扱えるGUIライブラリをまず提示してくれよ
妄想振りまく場違いな人としか見てもらえませんよ

759 ：デフォルトの名無しさん：2011/01/22(土) 19:27:31

かじり始めの盲信期だな

760 ：719：2011/01/22(土) 19:45:21

>>755
まず、>>748の話はマルチパラダイムではないStandard MLにも適用できます。
というか、(ライブラリの充実度全般に弱点がある)Standard MLにもTkやGTKくらいなら
GUIライブラリは存在していますから。

次に本論。あるプロジェクトにおいて言語ネイティブなライブラリの充実度が
言語選択の最重要判断基準であるのなら、素直に手続き型言語(C++/Java)を薦めることに同意しますよ。
ただし、しょうもないコーディングミスに起因するデバッグには辟易していて、
自分は(あるいは自分達は)アーキテクチャ設計に専念できる事が重要なんだ！！と考えるのであるなら、
言い換えるとソフトウェア品質保証も含めて判断材料にできるのなら、MLも比較対象になると思います。
現実世界での言語選択はケースバイケースで考えた方が良いのではないかと。
（>>748で書いたのは、あくまで個人的な意見(理想論)ですので、誤解しないでくださいませ）

最後にやっぱり気になる点。>>755はナゼ「純粋でなければ関数型言語を選ぶ価値が無い」と考えたのでしょうか？
(OCamlを含む)MLという言語は、(>>742で書いたように)純粋性を尊重しつつ例外も許容するという大人の考え方で
設計された言語です。この「完全な純粋性こそが全ての関数型言語に共通する特徴である」というのも、
広く蔓延している関数型言語に関する誤解の一つだと思います。(気が付けば３つ目になってしまいますた)

761 ：719：2011/01/22(土) 19:47:13

>>756
あらゆる不純性を決して認めない、というのは Haskeller 特有の解釈だと思われ

762 ：719：2011/01/22(土) 20:15:44

>>758
すまんが、漏れはGUIプログラミングに Haskell なんて薦めてなんかいないよ。(薦めているのはMLだ。勘違いしないでね。)

それどころか、(>>724で書いたように)自然な手続き型プログラミングが不可能なHaskellは
GUIプログラミングに不適切だと主張しているくらいだし。というか、HaskellでGUIモナドを記述するなんて、
相当の達人Haskellerでなければ無理じゃないかと思う。(少なくとも自分のHaskell理解度では無理デス)

あと、Haskell以外の関数型言語でもいいのなら、Standard MLでGTK向けのMVCラッパライブラリを開発中だ。
着手したばかりで、まだ動くコードは見せられないけどね。
代わりに、その元ネタになったRubyによる関数型プログラミング風の宣言的なGUI記述コードを次カキコで紹介する。
今はRuby-GTK向けの骨格プロトタイプを開発している段階で、最終的にMLに落とす予定。

紹介するのは、この板の「LLバトルロワイヤル13(dat落ち)」にカキコしたコードのコピペ。
話の発端は「LLで宣言的なGUIはできねえのか？」というもので、それに対する一連のレスの一部になる。
(というわけで、次レスに続く)

763 ：719：2011/01/22(土) 20:17:09

(>>762の続き)

>656 名前: 631 Mail: sage 投稿日: 2010/11/10(水) 18:38:17
>>>652
>ウィジェットの階層構造をメソッドの列で表現するのではなく、データ構造で表現するということですね。
>とても良い発想だと思います。自分はまだRuby1.9へ移行していないので、Ruby1.8で実装してみました。
>ただし、Ruby1.8は連想リストが使えないので、代わりにモジュール関数を使っています。
>これは実際に動くコードです。モジュールMTKを実装したmodern_tk.rbは、114stepほどの規模でした。
>
>require 'modern_tk'
>text_data = Struct.new(:output, :input).new(MTK.variable, MTK.variable)
>MTK.mainloop(
>　　MTK.root(
>　　　　:title => 'Ruby/Tk!',
>　　　　:vpack => [
>　　　　　　MTK.label(
>　　　　　　　　:textvariable => text_data.output,
>　　　　　　　　:font => [:serif, 18, [:bold]]
>　　　　　　), MTK.entry(
>　　　　　　　　:textvariable => text_data.input,
>　　　　　　　　:font => [:serif, 12, [:normal]]
>　　　　　　), MTK.button(
>　　　　　　　　:text => 'OK',
>　　　　　　　　:command => proc {
>　　　　　　　　　　text_data.output.value =
>　　　　　　　　　　　　"You typed #{text_data.input.value} !"
>　　　　　　　　}
>　　　　　　)
>　　　　]
>　　)
>)

764 ：デフォルトの名無しさん：2011/01/22(土) 20:30:35

>>760
SML はオブジェクト指向言語じゃないので、>>748 と矛盾する。

OCaml のオブジェクト指向な部分も後付けなんだっけ。
Python や Objective-C もそうだけど、オブジェクトシステムを
建て増しすると言語がいびつになるよね。

765 ：デフォルトの名無しさん：2011/01/22(土) 20:37:47

OCamlって実行時型情報無し、ダウンキャスト無しってほんと？
それだと動的な要素が薄すぎてOOPLとして使うのはかなり無理がありそうだけど

766 ：デフォルトの名無しさん：2011/01/22(土) 20:44:48

>>760
ML が例外を許容する事で大人な言語なら Java はもっと大人な言語だと思われ。
副作用を全て受け入れて、不変性を表明したい時だけ final と書けば良いんだからね。
しかも配列の要素は可変という裏口まで用意してくれている。

単に変数のデフォルトの挙動が違うだけで、取り立てて騒ぐ事じゃないと思うわ。
Haskell くらい副作用を隔離出来るなら別だけどね。

767 ：デフォルトの名無しさん：2011/01/22(土) 20:48:13

>>760
プログラムを作るのに毎回ラッパーライブラリを用意するのが
面倒でなければ、関数型言語を薦めることに同意しますよ。

768 ：719：2011/01/22(土) 20:54:05

>>752
お気の毒な話だねw（ネタだとは思うけど....）

自分なら「C/C++は分かる、でもC/C++&Hogeは分からない」という人になら、
Python/Rubyのようなスクリプト言語を薦めるけどね。
GUIプログラミングが初めてであるなら、まずは「書いてみる＆動かしてみる＆じっくり考える」が
楽なスクリプト言語が向いていると思う。（あくまで個人的な意見だけど....）
スクリブト言語を学ぶ事自体が回り道になるけど、それも長いPG/SE人生からすれば一瞬ではないかと。

初心者には、まずお気軽に動くことができる事が最も重要。
その後、「動けばいい」から「正しく動く」というレベルに移行する時に、MLのような作用順評価(=非遅延評価)の
型付き関数型言語を学べばいい。ML系の言語(Standard ML/OCaml/F#..etc)であれば、(>>741が紹介してくれたように)
冗長ではあるけれど、Cのコードと対応付けの容易なコーディングができるから、移行も(比較的に)容易だ。
特にサンプルプログラムから卒業して、ある程度の規模のGUIプログラミングを始めようとするレベルに達したのならね。

それなのに初心者へいきなりHaskellを強要するというのは、....... 狂っているとしか言いようがないwww
GUIが初めての人に、最初にまずGUIモナドとは...モナドとは....遅延評価とは.....とか講義(=自慢)したいんだろね。
でも多くのHaskellerには、そんな頑な(かたくなな)一面があるというのも、これまた事実だったりする訳で。(例:>>756)

769 ：デフォルトの名無しさん：2011/01/22(土) 21:32:01

次スレ作っといた
http://hibari.2ch.net/test/read.cgi/tech/1269609576/

770 ：デフォルトの名無しさん：2011/01/22(土) 21:41:58

>>768
> 自分なら「C/C++は分かる、でもC/C++&Hogeは分からない」という人になら、
> Python/Rubyのようなスクリプト言語を薦めるけどね。
アホでしょ
前者はHogeを理解するだけだが
後者はHogeラッパに加えPython/Rubyまで理解する必要があるぞ

GUIが難しいという人は言語の問題ではなく
イベントが発生したら
OSはそのイベントをスレッドごとに用意されたメッセージキューにプッシュする
という基本的な流れが分かってないんじゃないかな
それが分かってたらアプリ側でやる事はCUIと同じなわけだし。

771 ：デフォルトの名無しさん：2011/01/22(土) 22:04:34

マイナー言語を弄るのが趣味でなければ ML 系は止めておいた方が良いと思うわ。
処理系のバグ出しをしたり、古くなって動かないライブラリを改修したりするのが
楽しい人には良いけどね。

772 ：デフォルトの名無しさん：2011/01/22(土) 22:25:27

> それなのに初心者へいきなりHaskellを強要するというのは、....... 狂っているとしか言いようがないwww
> GUIが初めての人に、最初にまずGUIモナドとは...モナドとは....遅延評価とは.....とか講義(=自慢)したいんだろね。

そういえば講義(=自慢)を繰り返してる奴が一人いるな
狂ってるのかな？

773 ：デフォルトの名無しさん：2011/01/22(土) 22:43:27

> それなのに初心者へいきなりHaskellを強要するというのは、....... 狂っているとしか言いようがないwww
> GUIが初めての人に、最初にまずGUIモナドとは...モナドとは....遅延評価とは.....とか講義(=自慢)したいんだろね。
本人自ら719の擦り付けｗ

774 ：デフォルトの名無しさん：2011/01/23(日) 01:24:54

>>762
>自然な手続き型プログラミングが不可能なHaskell

do

775 ：デフォルトの名無しさん：2011/01/24(月) 00:29:13

>770 ：デフォルトの名無しさん：2011/01/22(土) 21:41:58
>前者はHogeを理解するだけだが
>後者はHogeラッパに加えPython/Rubyまで理解する必要があるぞ

LLで書いた方がREPLとか備わってて、
コンパイルする言語よか開発サイクルはやそうに見えるんだけど。
そして、齧り出しのgtkmmにあるmem_funが何それ状態。STLまで覚えなあかんの？
GUIについて覚えるなら、C++なんて忘れてLLからの方が習得はやい気がする。
ああ、隣の芝が青い...。

776 ：デフォルトの名無しさん：2011/01/24(月) 00:44:06

>>775
GUI みたいにイベントループが処理を乗っ取る様なプログラムだと REPL は意味が無い。
それと、GUI ライブラリの実装言語 (C++ とか) の知識はデバッグ時にも必要になるから、
LL しか知らないと厳しい。

777 ：デフォルトの名無しさん：2011/01/24(月) 00:55:07

>>776
地道にC++で覚えまつ
(ん？GUIライブラリもC++で書かれてんだっけ)

778 ：デフォルトの名無しさん：2011/01/24(月) 00:56:45

>>775
君は何も気にせず好きなようにしたらいいよ。
>mem_funが何それ状態。STLまで覚えなあかんの？
な人は「C/C++は分かる」と言えないからね。

779 ：デフォルトの名無しさん：2011/01/24(月) 01:20:13

流石にprivateな関数のポインタを参照してるぐらいは分かるけど、C++は覚えること多すぎ
簡単なものを作るだけでも、すごい遠回りなことしてる気がする
専門馬鹿が素人のこと考えてないってのが、よぉ分かるわ

780 ：デフォルトの名無しさん：2011/01/24(月) 01:56:49

>>718
lisp系のスクリプトで、Cのコードを生成するもんを見たことある気がする

781 ：デフォルトの名無しさん：2011/01/24(月) 04:21:59

>>779
VBやDelphiでどうすか？

782 ：デフォルトの名無しさん：2011/01/24(月) 04:35:29

そこはJavaでいいんじゃないか

783 ：デフォルトの名無しさん：2011/01/24(月) 04:55:08

C#だろ常考

784 ：デフォルトの名無しさん：2011/01/24(月) 21:23:26

>779
アセンブラ→C→C++→C#→F#ときたのでC++でなにが覚えるの大変なんだか良く解らん。
Boostとかのことか？

785 ：デフォルトの名無しさん：2011/01/24(月) 21:47:33

最近関数型言語とか憶えたてだけど、C++のどこが難しいのかマジわかんねーわー
最近関数型言語とか憶えたてだけど、C++のどこが難しいのかマジわかんねーわー

786 ：779：2011/01/24(月) 22:32:33

>>784
多重継承やRTTI、菱形継承の問題。RAIIイディオム
一時オブジェクトの生存期間
関数の継承をprivateにするかprotectedにするか
ヘッダファイルに書くかプロトタイプ宣言のみにするか
グローバル変数のスコープ、enumの通用範囲
インライン関数にテンプレート使ったときに、どこに定義されてんのか
vectorのイテレータと生のポインタの違い
STLのallocatorってなんだ？
static_castの４つの違い
コピーコンストラクタ作ったときに自己参照に気をつけろとか
初期化子リストの初期化される順番
展開されたテンプレートの定義箇所
スマートポインタを参照でわたしたらどうなるか
expressionテンプレート
ムーブセマンティクス、右辺値参照←new!!

>>785
CSP問題でも解いてろ

787 ：デフォルトの名無しさん：2011/01/24(月) 22:54:01

>>786
君はGUIが分からないのではなくてC++が分からないんでしょ？
それはスレ違いだよ。
C++が分からないなら分からないで
CでXlibやWin32のAPIを直接叩けばいいじゃん
メンドクサイならHSPでも使って分かったつもりで悦に入ればいいじゃん
自分が理解できないからって場違いなスレで騒いでもしょうがないでしょ

788 ：デフォルトの名無しさん：2011/01/24(月) 22:59:43

>786
菱形継承すんな
スコープ外れたとき
必要ならprotectedにしろ
好きにしろ
グローバルなんか使うな
忘れた
イテレータはラップしたオブジェクト
自前allocatorを使える
無理くりとか出来ますよね？とか
事故参照するのが悪い
そういうのに依存しないように書くべき
IDE使え
何も起こらん
知らん
知らん

あーたしかにそのへん気にしようとすると色いろあるかも。でも基本そんなにこだわらなくても良かったりそもそもそんなの絡めるべきじゃないってのが多くねーか

789 ：デフォルトの名無しさん：2011/01/24(月) 23:44:07

C++は自由すぎるから
他人のオナニーコードや
ライブラリ読むと発狂できる

790 ：デフォルトの名無しさん：2011/01/24(月) 23:55:19

作法が確立してるメジャーどころは
慣れりゃ読めるし、慣れるだけの見返りはあるけど
オレオレなオナニー劣化車輪がキツイんだよな
それはC++に限ったことじゃないけども

791 ：デフォルトの名無しさん：2011/01/24(月) 23:56:59

ズリネタあったらオナニーやめられない猿野郎が大量にいるぞ
どいつもこいつもしこってばっかで開発すすまねぇ

Java 去性しちまえば作業効率あがるぜ
C++ オナニーは時と場所選ぼうぜ

792 ：デフォルトの名無しさん：2011/01/26(水) 00:31:06

>>765
RTTIとかダウンキャストって、そんなに必要なものかな

793 ：デフォルトの名無しさん：2011/01/26(水) 16:34:20

無理して使う必要ないけど、知ってれば知ってたでデバッグの時とか役に立つ

794 ：デフォルトの名無しさん：2011/01/26(水) 21:37:54

デバッグの時は便利か

型を見て分岐するなら、polymorphism 使うべきだろうなと思った

795 ：デフォルトの名無しさん：2011/01/26(水) 21:51:31

型を見て分岐してるのはRubyくらいだろ

796 ：デフォルトの名無しさん：2011/01/26(水) 22:27:08

実行時型情報といってもC++のRTTIぐらいだと大して役にたたんけど
MOPまで行けばとても便利で有用
Javaや.NETのイントロスペクションとか

797 ：デフォルトの名無しさん：2011/01/27(木) 00:02:22

>>795
http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/mac_typecasec_cm_etypecase.html

798 ：デフォルトの名無しさん：2011/01/29(土) 00:06:46

cocoaってどーなの？

799 ：デフォルトの名無しさん：2011/01/29(土) 03:08:39

いいトコもある、だけど悪いトコもある

800 ：デフォルトの名無しさん：2011/01/29(土) 13:02:01

とりあえずIBは糞

801 ：デフォルトの名無しさん：2011/01/29(土) 13:07:21

そうかな?

802 ：デフォルトの名無しさん：2011/01/29(土) 21:42:36

いいコトもある、だけど悪いコトもある
人生を楽しんでいたい
井上怜奈

803 ：デフォルトの名無しさん：2011/01/30(日) 03:45:40

人生、楽ありゃ苦もあるさ
くじけりゃ誰かが先に行く
里見浩太朗

804 ：デフォルトの名無しさん：2011/01/30(日) 07:01:51

先に行くと何かいいことあるのか？　何にもなさそうな気がするんだが。

805 ：デフォルトの名無しさん：2011/01/30(日) 07:06:59

病院逝け

806 ：デフォルトの名無しさん：2011/01/30(日) 09:57:34

ここは天国じゃないんだ、かといって地獄でもない
いい奴ばかりじゃないけど、悪い奴ばかりでもない
ロマンチックな星空にあなたを抱きしめていたい
南風に吹かれながらシュールな夢を見ていたい
THE BLUE HARTS

807 ：デフォルトの名無しさん：2011/01/30(日) 10:06:06

笑っていても
泣いて過ごしても平等に時は流れる
未来が僕らを呼んでる
その声は今　君にも聞こえていますか?

808 ：デフォルトの名無しさん：2011/01/30(日) 21:41:59

なんにも聞こえないなあ。聞こえたら危ない精神状態なんじゃないだろうか。

809 ：デフォルトの名無しさん：2011/02/11(金) 00:26:46

Nokia さんはどこへ向かっているのだろう
Qt が盛り上がる方向で舵取りしてもらいたい物だけど...

810 ：デフォルトの名無しさん：2011/02/11(金) 16:42:09

Qtってなんて読むの？

811 ：デフォルトの名無しさん：2011/02/11(金) 17:58:06

キューティー、でつ

812 ：デフォルトの名無しさん：2011/02/11(金) 21:23:53

でつ(笑)

813 ：デフォルトの名無しさん：2011/02/14(月) 05:49:50

age

814 ：デフォルトの名無しさん：2011/02/22(火) 13:44:29.37

キュートだろ

815 ：デフォルトの名無しさん：2011/02/23(水) 11:12:53.10

Qちゃん

816 ：デフォルトの名無しさん：2011/02/23(水) 11:47:18.93

206 デフォルトの名無しさん [sage] 2011/02/23(水) 00:30:05.97 ID: Be:
    かってに、google に甘い期待をしているんだけど、

    ttp://sourceforge.jp/magazine/11/02/22/104206

    これとかを見ると、google 的には、
    C++ は Web アプリみたいにして、
    Android に持っていくつもりなのかな。

    プログラマのヘマでセキュリティーホール作られるよりは、
    制限あっても、sandbox 内で…って感じで。

    Javaが選ばれた理由も、そんなんじゃなかったっけ？

817 ：デフォルトの名無しさん：2011/02/24(木) 02:23:09.35

何で方々にコピペしまくってるんだ?
NaCl に興味があるなら、インストールして試してみると良いよ

Google が開発しているプログラム実行環境（Native Client :
C/C++, Native Activity : C/C++, Dalvik : Java, V8 : JavaScript、
Go : Go、Unladen Swallow : Python）の中でどれが一番長生き
するか調べて、ブログにでも載せておいてくれると助かるわ

818 ：デフォルトの名無しさん：2011/05/04(水) 00:27:59.93

コマンドラインでグラフィック弄る方がもっとムズいだろ
ＧＵＩで簡単になったっていうのに何がむずかしいのか

819 ：デフォルトの名無しさん：2011/05/04(水) 10:19:21.20

慣れない人向けへのわかりやすさと
慣れた人向けの効率性の両立
両方作れってのは工数増えるから簡単じゃないよ

820 ：デフォルトの名無しさん：2011/05/08(日) 02:31:56.70

マウスイベントの処理を実装するのに、状態遷移図を書いて、switch / case を使って
実装しているんだけど、激しく面倒くさいな。

状態のリストアップも面倒くさいし、各状態に名前を付けるのも面倒くさいし、
フラグやデータの更新漏れが無いかチェックするのも面倒くさいし、用意したフラグが
最適なのかを考えるのも面倒くさいし、テストケースを作るのも面倒くさい。

マウスハンドリングのガイドラインみたいなのがあったら良いのに。

821 ：デフォルトの名無しさん：2011/05/08(日) 10:51:19.04

転職しろよｗ

822 ：デフォルトの名無しさん：2011/05/08(日) 13:51:43.66

うん。自分でも適正無いなとは思うわ。
でも、幸いな事にマじゃないので転職の心配はしなくて大丈夫なんだ。

イベントの状態遷移をうまく定義する方法論は無いかな?

823 ：デフォルトの名無しさん：2011/05/08(日) 21:25:14.17

Stateパターンくらいは知っていても損はしませんぜ

824 ：デフォルトの名無しさん：2011/05/08(日) 21:46:33.00

メソッドディスパッチを使って状態を切り替える方法は部分的には使っているんですけど、
状態の数が増えると、似た様なクラスとメソッドを大量に作らないといけないですよね。

結局クラスの名前を考えるのが頭が痛いです。。。

825 ：デフォルトの名無しさん：2011/05/16(月) 06:12:14.43

使えん奴だなw状態そのものをクラス化して状況に応じて必要なだけつくればいいjk
作るときにコールバック渡してyo

826 ：デフォルトの名無しさん：2011/05/16(月) 08:24:00.66

使える人はもう少しレスの中身をきちんと読んだら良いと思うの

827 ：デフォルトの名無しさん：2011/05/17(火) 02:01:11.20

分かりにくいレス(これすなわちUI)はお前の得意分野だろｗ

理解してもらう努力もせずにGUI作るなんてオナニー以外の何物でもないと思うよ。

828 ：デフォルトの名無しさん：2011/05/17(火) 07:25:04.60

いきなりどうした？

829 ：デフォルトの名無しさん：2011/05/18(水) 14:37:30.45

これを逆切れと言う

830 ：デフォルトの名無しさん：2011/05/18(水) 19:23:05.23

ソウダッタノカ

831 ：デフォルトの名無しさん：2011/06/01(水) 02:46:10.73

double click されたら GUI で起動して
command line から実行されたら CUI で起動する
こういう風に造っておくのがよさげ

832 ：デフォルトの名無しさん：2011/06/01(水) 09:48:46.68

そんなことできるの？

833 ：デフォルトの名無しさん：2011/06/01(水) 19:31:01.89

Mac OS X だと bundle をダブルクリックすると GUI で起動して
コマンドラインから実行ファイルを直接指定すると CLI で実行出来るね

834 ：デフォルトの名無しさん：2011/06/01(水) 22:01:28.09

>832
不可能ではないかも。
自身の親プロセスやその祖先にexplorer.exeがいたらGUI起動、それ以外だったらCUIとか。

まあ俺なら引数で分けるけど。

835 ：デフォルトの名無しさん：2011/06/02(木) 00:27:46.95

>>831
そんな方法あるの？

836 ：デフォルトの名無しさん：2011/06/02(木) 00:33:40.86

Argに入ってたっけ?

837 ：デフォルトの名無しさん：2011/06/02(木) 17:49:58.00

Windowsの実行ファイルでGUIと標準入出力の機能両用できたっけ？

838 ：デフォルトの名無しさん：2011/06/02(木) 17:52:51.58

yes

839 ：デフォルトの名無しさん：2011/06/20(月) 10:50:00.34

画像処理ソフトにあるようなレイヤーの作り方って
どこかに書いてない？

840 ：デフォルトの名無しさん：2011/06/20(月) 12:03:53.35

んーそれぐらいわからん奴は(ryときそうだが、
ざっくりいえば、単に描画するものをレイヤーオブジェクト的なものに分けて持たせておいて、今の操作対象のレイヤーに描画オブジェクトを追加するとか非表示のレイヤーは表示対象にしないとかだけだと思われ。

841 ：デフォルトの名無しさん：2011/06/23(木) 07:17:10.84

基本的には下の階層から順々に描画するだけだわな

842 ：デフォルトの名無しさん：2011/06/23(木) 21:38:58.40

駅の表示とかで、上下の配置と、自分に近い・遠いの対応は、
関東と関西じゃ逆なんだっけ？

843 ：デフォルトの名無しさん：2011/07/07(木) 18:27:27.92

AとBは二者択一だけど両方選ばないこともできる
って場合、どんなコントロールがわかりやすいですか？
（「□」はチェックボックス、「○」はラジオボタン）

□　カレーを作る（選択肢A）
□　自転車に乗る（選択肢B）

こうして
Aにチェックを入れるとBのチェックがはずれ
Bのチェックを入れるとAのチェックがはずれる
にするとわかりにくいですよね？勝手にチェックがはずれるとか

○　カレーを作る（選択肢A）
○　自転車に乗る（選択肢B）

こうして
チェックしているものをもう一度選択するとチェックが外れるというのも
普通のラジオボタンにはない動作なのでわかりにくすぎますよね？

○　カレーを作る（選択肢A）
○　自転車に乗る（選択肢B）
○　何もしない

こうですか？これはこれで「何もしない」がわかりにくいというか無駄というか

わかりやすいいい方法はありますか？

選択肢が「カレーを食べる」「うどんを食べる」なら
「何も食べない」が並んでいてもそんなに違和感はありませんが
「カレーを作る」「自転車に乗る」くらいぜんぜん違うもので
それでいて同時には選べない排他的なもので

844 ：デフォルトの名無しさん：2011/07/07(木) 18:33:17.33

○　何もしない
○　何かする
　○　カレーを作る（選択肢A）
　○　自転車に乗る（選択肢B）

とか

□　何かする
　○　カレーを作る（選択肢A）
　○　自転車に乗る（選択肢B）

とかして
「何かする」が選ばれていないときは選択肢をグレーアウトさせると
選択肢を選ぶのにワンステップ増えてしまうし

845 ：デフォルトの名無しさん：2011/07/07(木) 18:46:32.94

普通の人は
○　カレーを作る（選択肢A）
○　自転車に乗る（選択肢B）
○　何もしない
が分かりやすいでしょう。

846 ：デフォルトの名無しさん：2011/07/07(木) 18:55:55.17

ちょっと補足
内容云々はどうでもよくて、結局3択なのだから
それが一目瞭然な方がいいと思う。

847 ：843：2011/07/07(木) 19:04:11.91

>>845
どうもありがとうございます
わかりやすさならこうかなとか思ったりもしました
□　追加動作を選択する
　○　カレーを作る（選択肢A）
　○　自転車に乗る（選択肢B）

「何かする」とか「何もしない」とかは間が抜けているというか
項目として並べるものでもないような気がして
三択にするとどちらも選ばなかった場合の表現が「何もしない」以外に言いようがないっぽいし
でも言われてみれば確かに三択ですよね

848 ：デフォルトの名無しさん：2011/07/09(土) 19:13:47.27

やっぱり HyperCard みたいな、GUI 部品に直接コードを書いていく様な
開発環境が最強な気がするなあ...

849 ：デフォルトの名無しさん：2011/07/10(日) 02:30:59.71

GUIが難しい・・・か。
まあどこまでGUIに含めるかだよね。

CUIだと
コマンド名オプションオプションオプション
でいいから簡単。

もしGUIでも、[コンボボックス] [コンボボックス] [コンボボックス] でコマンドを
選んでいくだけでいいようなものなら、作るのは簡単だろう。

だけどGUIだとCUIとは違って優れたユーザーインターフェースを作る必要がある
まあ、必須ではないけれど、現実問題そうなるよね。

優れたユーザーインターフェースを持ったGUIを作るというのなら
難しいというのは事実。

850 ：デフォルトの名無しさん：2011/07/10(日) 02:31:32.37

ActionScript最強ってかw

851 ：デフォルトの名無しさん：2011/07/12(火) 21:11:52.33

CUIはほぼプロしか使わないけど
GUIは素人が使うことも考慮しなければならない

852 ：デフォルトの名無しさん：2011/07/17(日) 00:52:41.45

GUI の配置は XML で定義出来るのが一番良いなあ

853 ：デフォルトの名無しさん：2011/08/12(金) 21:05:28.09

確かに大変だね。ワンチップマイコンでTFT液晶に基本Widgetから描画するとなるとイベントバインディングやメッセージルーターやら！
リストボックス描画の参考になるサイト無いかな？

854 ：デフォルトの名無しさん：2011/08/15(月) 00:03:06.96

Active BASIC最強

855 ：デフォルトの名無しさん：2011/08/18(木) 18:19:40.02

ｸﾞｲって言う人ってなんなの＞＜

856 ：デフォルトの名無しさん：2011/08/19(金) 10:21:25.26

http://dictionary.reference.com/browse/GUI
グーイーだよねー

857 ：デフォルトの名無しさん：2011/08/19(金) 18:58:06.89

http://dictionary.reference.com/browse/CUI

858 ：デフォルトの名無しさん：2011/08/19(金) 19:45:32.95

ｸﾞﾗﾌｨｺｫｩ　ﾕｰｻﾞｰ　ｲﾝﾀﾌｪｨｽ

859 ：デフォルトの名無しさん：2011/08/19(金) 21:19:28.78

WindowsでCUIのフロントエンド作りたいんだけど
簡単に作るには何がおすすめ？

860 ：デフォルトの名無しさん：2011/08/19(金) 22:27:37.78

Cygwin

861 ：デフォルトの名無しさん：2011/08/19(金) 23:00:22.47

hta

862 ：デフォルトの名無しさん：2011/08/19(金) 23:01:56.71

hta
vc#
vb.net
qt

863 ：デフォルトの名無しさん：2011/08/22(月) 01:03:21.48

GUIなんて部品としてあるものをこねこねいぢくり繰り回すだけだから初心者のとっつきやすさという部分以外は一番簡単な部類だよね

864 ：デフォルトの名無しさん：2011/08/22(月) 01:17:44.72

そういやまだ夏休みか( ´ー｀)ﾌｩｰ．．．

865 ：デフォルトの名無しさん：2011/08/22(月) 02:38:15.23

>>863,864
夏房共乙

866 ：デフォルトの名無しさん：2011/08/22(月) 03:01:20.44

> GUIなんて部品としてあるものをこねこねいぢくり繰り回すだけだから初心者のとっつきやすさという部分以外は一番簡単な部類だよね

GUIはCUIに比べるとはるかに難しいぞ。

CUなんて、文字の入力と出力しか
機能がないからな。

867 ：デフォルトの名無しさん：2011/08/22(月) 19:35:16.97

面倒くさいのを難しいことだと勘違いしている馬鹿がいるな

868 ：デフォルトの名無しさん：2011/08/22(月) 21:22:23.13

現状のままX11とかTkとか使い続けるのは難しくない
面倒臭さや古臭さを改善しようとするから難しい

869 ：デフォルトの名無しさん：2011/08/22(月) 23:01:17.41

>>867
昔RPGとかクリアできなかったような人種だろうね
職業プログラマじゃない事を祈るけど

870 ：デフォルトの名無しさん：2011/08/23(火) 00:07:03.50

GUIが簡単ってより
元あるライブラリに素直に載せてやるのが簡単なんじゃね
へっぽこなCUIつくってるのに雑魚がカス設計すると
むずかしいからいやになっちゃうよ

そんないたたなCUIが増えてきたから
GUIはかんたんーって馬鹿にしてるんだね

871 ：デフォルトの名無しさん：2011/08/23(火) 07:50:42.08

単純な入力フォームからPhotoshopのような複雑なアプリ、スレッド使ったものや、マルチタッチ使ったものまで色々あってだな。
それら全てに対してGUI簡単ですと言ってくれる人がいるなら是非うちで雇いたいわ。

872 ：デフォルトの名無しさん：2011/08/23(火) 08:37:50.42

GUIとしての使いやすさなどを考慮せずに、
ただのCUIのラッパーとしか考えてない奴にとっては
簡単だろうさ。

873 ：デフォルトの名無しさん：2011/08/23(火) 11:40:09.25

イベント
スレッド

874 ：デフォルトの名無しさん：2011/08/23(火) 12:17:50.41

用意されているものを使ってるだけで
アルゴリズム開発とか高速化にしのぎを削るような事を考えてない奴らにとっては
難しいだろうさ
全ての層のユーザーに対応したエラー処理をしなければとかいう言い訳ばっかりして仕様という名の不具合しか生まないんだ
って先輩が言ってました

875 ：デフォルトの名無しさん：2011/08/23(火) 21:17:21.14

GUIが簡単っつうか
優秀な人間が用意したレールの上に作るのが簡単ってだけじゃね
CUIよりGUIのほうがずっと入力データも出力データも複雑で
負荷も高い場合が多いよね

タコが設計したソースいじってみろよ
ちょう簡単に作れるはずが無駄にむずかしいからねぇ
しかも崇高な設計理論語りだすからとめられんし

876 ：デフォルトの名無しさん：2011/08/23(火) 23:51:12.44

消極的GUIと積極的GUI
http://ja.wikipedia.org/wiki/%E6%B6%88%E6%A5%B5%E7%9A%84%E8%87%AA%E7%94%B1
消極的GUIは、崇高()な設計理論に従わない状態を意味する
一方、積極的GUIは、優秀な人間によって規定される概念である

877 ：デフォルトの名無しさん：2011/08/24(水) 02:35:47.07

おせっかいで頭悪いって最悪だよね

878 ：デフォルトの名無しさん：2011/08/24(水) 03:11:21.55

> CUIよりGUIのほうがずっと入力データも出力データも複雑で

え？入力データも出力データも
GUIとかCUIは関係ないじゃん。

GUIになると、CUIだったら複雑なデータが
シンプルになるの？すごいなGUI。
ユーザーインターフェースだけじゃなくて
データまで操作してくれるのか（爆笑）

お前はアホ

879 ：デフォルトの名無しさん：2011/08/24(水) 04:42:48.09

>> CUIよりGUIのほうがずっと入力データも出力データも複雑で
>GUIになると、CUIだったら複雑なデータがシンプルになるの？

逆じゃんか
アホはお前だ

880 ：デフォルトの名無しさん：2011/08/24(水) 08:13:34.96

書いてある文章の表現力をみれば、GUI作る能力も予想出来るね。

881 ：デフォルトの名無しさん：2011/08/24(水) 10:25:48.15

GUIが単純とか言ってる奴はGUIのフレームワーク作ってからほざけ。

882 ：デフォルトの名無しさん：2011/08/24(水) 11:05:33.39

GUIは単純

883 ：デフォルトの名無しさん：2011/08/24(水) 11:25:48.28

馬鹿乙

884 ：デフォルトの名無しさん：2011/08/24(水) 12:37:47.61

自己紹介乙

885 ：デフォルトの名無しさん：2011/08/24(水) 23:18:07.47

マジレスすると結局与えられたGUIフレームワークとやらを使うしかないのが一番むずかしい

886 ：デフォルトの名無しさん：2011/08/25(木) 03:00:36.46

自分で作ればいい。

ただ、GUIを作るのは難しいｗ

887 ：デフォルトの名無しさん：2011/08/25(木) 03:19:28.79

項目の有効・無効の切替操作をまとめておけるような
問い合わせイベントが用意されていないとイライラする
操作自体は単純でも
あちこちの処理にばら撒きたくないんだよホント

888 ：デフォルトの名無しさん：2011/08/25(木) 10:30:12.37

［ﾚ］大文字小文字を区別しない
［ .］自動的に保存

889 ：デフォルトの名無しさん：2011/08/27(土) 08:33:59.83

CUI の場合、プログラムのほぼすべてを自分で開発するが、
GUI ではそういうわけにはいかないので、どちらかというと
必要になってくるのは検索能力ではないかと思ったりする。
悩みに悩んだ処理がフレームワークで用意されてたりするし。
単純なデリゲートの名前を散々悩んだ挙句、MethodInvoker なんてのが
あると知った日には吹いたわ。

890 ：デフォルトの名無しさん：2011/08/28(日) 08:09:45.25

>>889
違うと思う。
GUIは非同期処理なのと、何がどの順番で走るかユーザの気分次第だから難しいんだと思う。
入力と状態が組み合わせ爆発する。

891 ：デフォルトの名無しさん：2011/08/28(日) 11:46:30.87

CUIにインタラクティブな要素がないと思い込んでいるなら、その通りだね。

892 ：デフォルトの名無しさん：2011/08/28(日) 11:50:19.41

お前らこの10年(20年？)来同じ事ばっかり言ってるなｗ

893 ：デフォルトの名無しさん：2011/08/28(日) 11:56:28.40

>>890
文字でも順列組み合わせは普通に爆発してるんだが、
制御文字とかを特別扱いせずに同じ変数に代入するから状態が少なく感じる。
もし文字の種類ごとに異なるデータ型を定義したら、GUIと同じ問題が起きる。

MethodInvokerは、型で悩むのが馬鹿馬鹿しいという良い例だ。

894 ：デフォルトの名無しさん：2011/08/28(日) 12:05:52.77

>>892
Windows支配が崩れてだいぶ状況が変わってきたぞ。iOS,Android,WinPhoneとかわらわら沸いてきたし、
やたら滑らかなUIってやつが重視されるし、プラットフォームごとにまったく手法が違うし。
WebはjQueryだのなんだのでお花畑だし。

895 ：デフォルトの名無しさん：2011/08/28(日) 14:29:44.89

>やたら滑らかなUIってやつが重視されるし

重視するのはいいけど作る奴は必ずオフれるオプションつけといて欲しいよ…
イライラしてしょうがない

896 ：デフォルトの名無しさん：2011/08/28(日) 15:38:31.88

油断してるとイベントハンドラのオンパレードになる。
見た目・使い勝手共に満足のいくレベルまで持っていくのがとてもしんどい。
WPFが一番融通効きそうで、しかもドキュメントも多めだけど、それでも難しい。凹む

897 ：デフォルトの名無しさん：2011/08/28(日) 15:46:49.13

ハンドラ地獄はリアクティブプログラミングで解決したらいいなと思ってる

898 ：デフォルトの名無しさん：2011/08/28(日) 17:34:41.05

イベント起きまくり、マルチスレッドで同期取りまくりなプログラミングって結構楽しいよね

899 ：デフォルトの名無しさん：2011/08/28(日) 17:44:54.81

弩マゾ乙

900 ：デフォルトの名無しさん：2011/08/28(日) 19:05:18.65

わざわざ必要ないスレッド入れだしたり
同期がんばんなきゃいけないようにするのやめてくれませんか

901 ：デフォルトの名無しさん：2011/08/28(日) 19:35:57.27

>>900
それはお前の低い技術力自慢か？ｗ

902 ：デフォルトの名無しさん：2011/08/28(日) 19:40:31.29

パンダのすり替えワロス

903 ：デフォルトの名無しさん：2011/08/28(日) 21:11:08.87

>>893
とはいってもGUIのそれに比べれば。

904 ：デフォルトの名無しさん：2011/09/08(木) 09:54:06.08

>>901　俺スゲーっていってわかりづらいコードを書いてる馬鹿ﾊヶ━m9( ﾟдﾟ)っ━ﾝ!!

905 ：デフォルトの名無しさん：2011/09/09(金) 03:00:34.84

>>904
読みやすいコードと、馬鹿にでも理解できるコードは別物だから

906 ：デフォルトの名無しさん：2011/09/09(金) 08:56:14.84

そんなオナニー自慢されても(´・ω・｀)

907 ：デフォルトの名無しさん：2011/09/09(金) 17:39:37.47

能書きたれる前にコード見せろ、コード

908 ：デフォルトの名無しさん：2011/09/09(金) 23:42:34.90

マルチスレッドごときで技術力自慢って
格闘ゲームへったくそなのに
玄人向けのキャラ使ってぼこぼこにされてるようなやつじゃね

プロマネになってデスマ繰り返すまでわかんないんですかね
なれねーだろうけどなぁ

909 ：デフォルトの名無しさん：2011/09/10(土) 01:16:23.55

まぁそのマルチスレッドをまともにできる奴がほんと少ないよね・・・

910 ：デフォルトの名無しさん：2011/09/10(土) 02:09:55.62

並行プログラミングはπ計算とかアクターみたいな何らかのモデルで扱いやすいようにしないと高確率で特異なバグが発生して死ねる
多分ある程度の規模に達したら人間には扱えない代物になる

911 ：デフォルトの名無しさん：2011/09/10(土) 09:23:19.66

アクターモデルと一部状態共有モデル使ってReactiveで流れをつなげるのがまっとうだと思う。

912 ：uy：2011/09/19(月) 07:39:09.13

>>909
>>910
その理由は、「使わなくていい」からだよ

よく、2P対戦のゲームをマルチスレッドで作ろうとするバカいるけど
ゲームなんだからタスクシステムは最低1個はすでに作ってあるはずだろうに

完璧なソースコードではそのひとつのタスクシステムを木構造にするから
マルチスレッドで悩むことはまずはない　マルチスレッドを作る事もまずない

2CPU以上の環境で
速度が必要な場面でのみ、マルチスレッドにすればいい

ようはひとつのマルチスレッド　＝　ひとつの木構造のタスクシステム

マルチスレッドの別タスクのほうも、木構造になっていて、スレッド内にさらに内部にいくつものタスクを動かす

基本的にそこまでシビアな同期のいらない処理だけをマルチスレッドにするんだよｗｗｗ　同期必要になるようなマルチスレッド作ってる奴は
技術力の足りないバカだ
エフェクトや、メニュー開く、閉じるや、サウンド関係

もしプレイヤーキャラと、敵キャラをマルチスレッドで別スレッドにしてるなら、専門学校からやり直したほうがいい　わかったか？ゴミ

913 ：デフォルトの名無しさん：2011/09/19(月) 09:50:05.71

専門学校で教えてくれる方法が全てだと思っているなら、とんだ井蛙の愚だ。

914 ：デフォルトの名無しさん：2011/09/19(月) 09:58:07.30

金ためて大学で真面目にCS学びたい

915 ：デフォルトの名無しさん：2011/09/19(月) 10:01:19.68

YouTubeで公開されている海外の大学の講座でも見ておけよ

916 ：デフォルトの名無しさん：2011/09/19(月) 10:08:54.41

Notes for なんとかでpdfを検索するのもいいね
なんか講義のまとめみたいなのが簡単に引っかかる

917 ：デフォルトの名無しさん：2011/09/22(木) 22:38:48.97

専門はCすらまともに使えない奴が多すぎて
使える奴を見つけるのが非常に大変だった

918 ：デフォルトの名無しさん：2011/09/22(木) 23:16:48.06

ここも高齢化が進んでるな

919 ：デフォルトの名無しさん：2011/10/03(月) 08:09:45.92

結構古い本でGUIと状態遷移のことを説明してた本があった気がするが思い出せない。
だれか知りませんか？
後、新しい本でもいいです。

920 ：デフォルトの名無しさん：2011/10/09(日) 10:16:53.05

>>919
それだけじゃいくら何でも分かんねーだろｗ

921 ：デフォルトの名無しさん：2011/12/12(月) 03:10:25.45

ＧＵＩはテストを自動化するのも難しいよね

922 ：デフォルトの名無しさん：2011/12/12(月) 23:52:18.53

なんでそう思った？

923 ：デフォルトの名無しさん：2011/12/12(月) 23:57:38.63

テストツールは貧乏人には買えない

924 ：デフォルトの名無しさん：2011/12/13(火) 00:57:39.69

無料の使えよ

925 ：デフォルトの名無しさん：2011/12/17(土) 23:57:09.35

【ウェブアプリケーションという不幸】

現在、多くのプログラマ（素人）がウェブアプリケーションというものがベストな正しい方向だと勘違いしている。
ソフトウェアの作るにおいてそのアプリケーションに応じた状態遷移を実装するというのは基本中の基本である。
その点においてウエブブラウザというある状態遷移が実装されているアプリケーションの上に
また別のアプリケーションを実装するのは論外である。
そこまでするなら普通にアプリケーションを実装してダウンロードして使ってもらえばいいのである。
ウェブアプリケーションとは虚構にしか他ならない。
ウェブアプリケーションを作ろうとしているあなた。
今すぐ普通のアプリケーションとし設計し始めてはいかがだろう。
そうすればきっと後悔しないですむ。

HTMLやHTTPを悪者にはしていない。
TCP/IPができあがり、その応用として、ファイルを送ったりするようになった。
ファイルの中身のテキストにデータ構造をもたせ、それはつまりツリー構造なわけだが
その実装としてのハイパーテキスト、つまりHTMLという送る側と送られる側で決め事（プロトコル）
をつくり、画像や音楽など表現の幅を広げることは当然の成り行きだっただろう。
そして、その送る側としてのHTMLファイルサーバ、つまりWebサーバ、送られる側としてのプロトコルの解釈・表示系としての
ブラウザというアプリケーション。
ここまではいい。
だが、そこから先が素人の発想というか、いそがばまわれを忘れた者の愚かな発想。
つまりブラウザ上で、アプリケーションを動かすという発想なのである。
ブラウザというのは、おくられてきたステートレスな通信内容の一瞬の表示手段でしかない。
つまりアプリケーションのためのひとつのパーツなのである。
Windowsでいえば、コントロールのひとつ。（実際WebBrowserというコントロールがある。）
JavaならWebClietnだ（これは、ブラウザではないが。）。
包含関係が逆なのである。
ブラウザ上にアプリケーションを作るのは愚かなブームである。

926 ：デフォルトの名無しさん：2011/12/19(月) 18:48:28.52

まあ、ウェブアプリで文書作成中に保存のショートカット押して
ウェブページの保存ダイアログが出るのはよくある。

927 ：デフォルトの名無しさん：2011/12/19(月) 21:11:00.18

戻るボタンで戻らないでください
とか悪い冗談としか思えない

928 ：【12.7m】【東電 89.0 %】：2011/12/20(火) 20:01:13.45 BE:3923187078-2BP(108)

web application connective protocolみたいなの創ればいいのにね

929 ：デフォルトの名無しさん：2011/12/26(月) 07:29:02.35

>>925
Chromeで見れるんでよろしく状態のほうが、ランタイムやら.NETやらJAVAのしかるべきバージョン入れてパッチもちゃんと当てといてねとか客に言うより単純

930 ：デフォルトの名無しさん：2011/12/29(木) 21:57:14.80

スタート/ストップのボタンってどうやればいいですか？

A）スタートボタン、ストップボタンをそれぞれ用意する、押したボタンをへこませる
B）ボタンをひとつだけ用意してラベルや色を差し替える
C）その他

931 ：デフォルトの名無しさん：2011/12/30(金) 01:25:12.78

>>930
スタートさせる処理の内容による。

932 ：デフォルトの名無しさん：2011/12/31(土) 08:45:21.73

そうなんですか
どうもありがとうございますm(_ _)m

933 ：デフォルトの名無しさん：2011/12/31(土) 13:15:33.87

基本中の基本的な質問をするんだが

MVC アーキテクチャでアプリを構築したい
Doc-View でもいいが、要はモデル部分とその他をしっかり分けたい

しかし、例えばテキストエディタを作ろうとして
Win32APIやその他のライブラリにある一般的なテキストコントロールを使うと、
View 側に既にテキスト（ドキュメント）が全て記録されてしまっている
（テキストコントロールのプロパティや Get 何たら関数で取得できる）

一般的じゃなくても、リッチテキストコントロールとか、
スタイルテキストコントロールとか呼ばれるものでも状況は同じ
スタイルを決定するタグと一緒に生のテキストも全て View 側に記録されている

それら View 側に記録されているテキストを
Model 側にコピーして持つのも冗長でメモリの無駄に感じる
かといって、他のドキュメント（例えばファイル名など）はModel側で持ち、
一方でテキストそのものはView側で持つというのも MVC から外れている

こういう場合、どうするのが良いの？

934 ：デフォルトの名無しさん：2011/12/31(土) 13:49:02.63

>>933
>それら View 側に記録されているテキストを
>Model 側にコピーして持つのも冗長でメモリの無駄に感じる

まず冗長さやメモリ効率については、(今時なら)富豪主義で考えていいんじゃないかと思う
次にコピーの方向性については、古典的なMVCパラダイムでは逆じゃないのかな？

[Modelの役目]
　数百数千行に及ぶかもしれないテキストの実体を持つ
[Viewの役目]
　Modelが持つ実体の一部分を表示可能領域で切り取って(コピーして)表示する
[Controllerの役目]
　キー/マウス等の入力を扱い、入力イベントに応じてModelの値(=テキスト実体)を更新する
　結果としてModelに依存したViewの表示内容が更新される(GoF本で言うObserverパターン)

以下を参照
・使わないと損をするModel-View-Controller
　　http://aokilab.kyoto-su.ac.jp/documents/MVC/page1.html

935 ：デフォルトの名無しさん：2011/12/31(土) 14:12:25.65

(>>934の続き)
>>934で書いたのは、(Smalltalkによる)古典的なMVCパラダイムの話だった
今時のGUIツールキットは、(>>933でも書かれているように)ViewとControllerが一体化した
M-VCパラダイム(あるいはDocument-Viewパラダイム)が主流

この場合、Viewが持つ(更新された)部分テキスト実体をModelへ逆コピーすることになる
ここでの考えどころは「(1) 逆コピーのタイミング」および「(2) 逆コピーの範囲」の二点

単純な実装であれば、(1) については全てのイベントで逆コピーを実行し、
(2) については部分テキスト実体の全体を逆コピーすることになる
これを改良するなら、(1a) 部分テキスト実体が更新されたタイミング、あるいは
(1b) タイマーによる定期的なタイミング、(1c) (1a)と(1b)の組合せ、等が考えられるだろう
そして(2)についても、(2a) 変更された部分テキスト実体の断片のみを逆コピー、等が考えられる

936 ：デフォルトの名無しさん：2011/12/31(土) 14:23:33.15

テキストコントロールがドキュメントの一部の文字列などの編集などに使われるんだったら、値の双方向への丸コピとか気にしないでしょ？
全文がテキストコントロールでいじられてるってのはその特殊な場合というだけであって、無駄だということを考えない限りはいいんだと思う。

あくまでもModelはModel的な位置づけで扱って、ViewControllerはそのビューに閉じたことだけを考慮するようにすると。

937 ：デフォルトの名無しさん：2011/12/31(土) 14:43:58.71

>>934,935
> まず冗長さやメモリ効率については、(今時なら)富豪主義で考えていいんじゃないかと思う

メモリ効率については富豪主義で考えるとして、
冗長さは同期という余計な手間が入るから、ちょっと気持ち悪かったが、
もう少し楽観的に考えても良いんだね

> 次にコピーの方向性については、古典的なMVCパラダイムでは逆じゃないのかな？

おっしゃる通り

言い方が悪かった
コピーする方向云々の前に、そもそも情報がダブってしまう事を気にしていた

しかしなるほど、情報がダブることにはもう目をつむって、
View（Control）側から Model 側へコピーする（同期を取る）事を前提に
「いつ」「なにを」コピーするのかを考えるのか

>>936
テキストコントロールが、カーソルがある周辺や
表示されている領域だけのテキストをバッファとして持っているなら分かるが、
何百行もあるテキストの全てをバッファに持っている事が気になっていたんだ

お二人ともありがと、参考になった

ところで、この辺りの今時な GUI フレームワークを作るのに
参考になりそうな書籍やサイトは無いだろうか
（自分で今時のをググって探すと、どうも Web アプリにしかぶち当たらない）

938 ：デフォルトの名無しさん：2011/12/31(土) 16:35:50.71

周回遅れ

939 ：デフォルトの名無しさん：2011/12/31(土) 19:35:25.16

>>938
おっさんが趣味でやってんのに周回遅れもクソもあるか

例えばゲームをちょっとした趣味にしている人が
今ドラクエ２を初めてプレイして、周回遅れって言うのか？

まぁ皆が遙か昔に通り過ぎた所であることは承知している

940 ：デフォルトの名無しさん：2011/12/31(土) 22:58:00.53

判ってるなら良いです

941 ：デフォルトの名無しさん：2012/01/02(月) 08:38:06.24

>>936
>テキストコントロールがドキュメントの一部の文字列などの編集などに使われるんだったら、

静岡県人？

942 ：デフォルトの名無しさん：2012/01/02(月) 13:56:01.92

半島人は地域差別が酷いらしいねぇ

943 ：デフォルトの名無しさん：2012/04/20(金) 16:03:05.74

pythonでGUIプログラムを作ろうと思って情報収集していたのですが
http://code.google.com/p/pysta/
このようなものを見つけました
そもそもプログラミング初心者の上英語もちんぷんかんぷんで何がなんだかなのですが
これはpythonのGUIをvistaっぽくする何かってことでいいんでしょうか？
もしそうであった場合、こういったデータの使い方は学習サイトのどういう項目で勉強すれば良いのかまでご教示して下されば幸いです

944 ：デフォルトの名無しさん：2012/04/20(金) 17:07:00.02

これはGUIライブラリじゃなくて、pytonでVistaライクなlook&feelを持った仮想デスクトップシェルを作ってみたぜ！って感じのアプリじゃないかな。

pytonはよく知らんけど、フリーでマルチプラットフォームなGUIライブラリはgtk、tk、wxWedgetとかあって、
この3つは大抵の言語に移植されるから、この辺を調べるといいと思う。
pytonのライブラリ名だと、PyGTK、Tkinter、wxPythonかな。
まぁ、python特有の話はpythonスレで聞いた方が早いと思うよ。

945 ：デフォルトの名無しさん：2012/07/31(火) 15:27:33.16

つ ttp://sourceforge.net/projects/bestgui/#screenshots

946 ：デフォルトの名無しさん：2012/08/05(日) 18:05:03.18

馬鹿には無理

947 ：デフォルトの名無しさん：2012/09/27(木) 21:37:02.98

どのライブラリを使うか選択するのが一番難しい

948 ：デフォルトの名無しさん：2012/09/27(木) 21:43:55.48

意味が分からん
なぜ選択するのが難しいのだ？

適当に（サイコロでも転がして）決めて、
そのライブラリを使えばよくないか？

使ってて気に入らなければ別のものに変えればいい

949 ：デフォルトの名無しさん：2012/09/28(金) 00:54:54.25

GLUIって今でも利用価値ある？

950 ：デフォルトの名無しさん：2012/09/28(金) 07:04:25.63

価値は自分で判断しなさい

951 ：デフォルトの名無しさん：2012/09/28(金) 08:16:10.98

wxWidgets + wxGLCanvas の方が良いよ

952 ：デフォルトの名無しさん：2012/10/06(土) 17:58:14.59

qt使え

953 ：デフォルトの名無しさん：2012/10/06(土) 18:15:21.20

>>948
終わり良ければ全て良し

954 ：デフォルトの名無しさん：2012/10/06(土) 19:26:22.52

ＭＦＣ一択

955 ：デフォルトの名無しさん：2012/10/06(土) 19:53:15.46

c++使うんなら、qt5でQMLからスマホ弄れるようになるからqt一択だよ。

956 ：デフォルトの名無しさん：2012/10/06(土) 19:54:10.71

MFCとかいう恐竜のウンコの化石って、windows8からもサポートされるの？

957 ：デフォルトの名無しさん：2012/10/06(土) 19:55:52.12

今の時代にwxWidgetsなんてつかうなら、native client使う方がマシ

958 ：デフォルトの名無しさん：2012/10/06(土) 20:52:38.62

>>947
商業用途でならトレンドにあったクロスプラットフォームなもの
多分、qt5かhtml5かnative clientのドレかが正解。
牧歌的に枯れたものが使いたいならxlib,wxWidgets,SDL,gtkあたり

959 ：デフォルトの名無しさん：2012/10/07(日) 06:48:04.65

gtkは糞

960 ：デフォルトの名無しさん：2012/10/08(月) 15:40:03.67

>1 は Gay

961 ：デフォルトの名無しさん：2012/10/12(金) 00:40:17.58

>>958
ｻﾝｸｽｺ

962 ：デフォルトの名無しさん：2012/10/23(火) 23:50:43.55

Qtで決まりだな。

963 ：デフォルトの名無しさん：2012/10/24(水) 10:42:02.27

Qt はバッドノウハウ多すぎる

964 ：デフォルトの名無しさん：2012/10/24(水) 13:21:27.11

>>963
逆から読むとウハウノドッバになるんだけどな。
お前どう思うんだよコレ？

というわけでMotif一択だろ。

965 ：デフォルトの名無しさん：2012/10/24(水) 19:07:25.26

Qtマヨネーズ

966 ：デフォルトの名無しさん：2012/10/24(水) 20:19:06.05

馬鹿には無理

967 ：デフォルトの名無しさん：2012/10/24(水) 20:24:43.67

gtkは糞
qtはバッドノウハウ一杯

一体どうすれば

968 ：デフォルトの名無しさん：2012/10/24(水) 20:35:40.30

969 ：デフォルトの名無しさん：2012/10/24(水) 20:37:56.33

Qtに対するwxの利点は何かね？

970 ：デフォルトの名無しさん：2012/10/24(水) 21:16:20.02

バッドノウハウが圧倒的に少ない

ユーザーも圧倒的に少ないが

971 ：デフォルトの名無しさん：2012/10/24(水) 21:36:41.79

バッドノウハウが多いのは致命的だなぁ･･･
Qtは企業とかで使われるくらい実績がある、って謳われてるけど、
逆に企業くらいエネルギーを注がないと使えないってことかｗ

972 ：デフォルトの名無しさん：2012/10/24(水) 22:48:11.94

ごもっとも

973 ：デフォルトの名無しさん：2012/10/25(木) 12:34:59.19

GUIがむなしすぎる
にみえた

974 ：デフォルトの名無しさん：2012/10/25(木) 12:36:20.60

wxWidgets

975 ：デフォルトの名無しさん：2012/10/25(木) 16:35:39.50

wxWidgetsはC++はどう？
Qtに対抗できる？

976 ：デフォルトの名無しさん：2012/10/25(木) 16:48:52.23

QtってWindows版はフリーじゃなかった気がする

977 ：デフォルトの名無しさん：2012/10/25(木) 19:31:39.00

>>975
どういう状態になってたら「対抗できてる」と言ってもいいの？

978 ：デフォルトの名無しさん：2012/10/25(木) 21:15:14.60

メジャーどころでは

Qt vs wxWidgets

だな。

C#を許容するならWPF一択か。

979 ：デフォルトの名無しさん：2012/10/25(木) 22:35:22.41

>>977
異なるプラットフォームへの移植性とか、普及率とかじゃね？
あるいはライブラリの充実度とか。

980 ：デフォルトの名無しさん：2012/10/25(木) 22:46:23.75

マルチプラットフォームは気にせず、
対象OSはWindowsだけ考えればいい場合は
QtとwxWidgetsのどっちがイイの？？

981 ：デフォルトの名無しさん：2012/10/25(木) 23:50:43.28

wxWidgets

982 ：デフォルトの名無しさん：2012/10/26(金) 00:02:50.59

マルチプラットフォームしないんだったら日本語環境に不安のある海外製ライブラリなんかあえて使いたくない。

983 ：デフォルトの名無しさん：2012/10/26(金) 00:10:30.52

Qtは日本語環境が不安

984 ：デフォルトの名無しさん：2012/10/26(金) 07:11:52.14

今のwxWidgetsのエディットボックスってATOKまともに使える？
なんか昔のは、ATOKの変換中のパネルなんかがうまく表示されなかった記憶があるが

985 ：デフォルトの名無しさん：2012/10/26(金) 09:27:35.89

ATOK は DOS のしか使ったことないから知らん

986 ：デフォルトの名無しさん：2012/10/26(金) 13:04:59.35

64bitやるならQtじゃね？

987 ：デフォルトの名無しさん：2012/10/26(金) 18:41:28.45

wxは64bit対応しておらんのか

988 ：デフォルトの名無しさん：2012/10/27(土) 05:01:29.55

>>982
国産だけど、Wide Studioって実績あるの？gtkの方が枯れてねぇ？

てか、クロスプラットフォームなGUIライブラリって、
実際のところ選択肢がawt/swingぐらいしかなくね？

989 ：デフォルトの名無しさん：2012/10/27(土) 14:34:14.47

GTKはクソ

990 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/10/27(土) 14:50:33.93

>>988
「平成15年度未踏開発ソフトウェア創造事業」で採択された。
http://www.ipa.go.jp/jinzai/esp/15mito/gaiyo/15-1.html
T-Engineで動作することと、GUIで開発できることがメリット。
でもレイアウトグリッドがないとか、OOPじゃないことなど、多少不便。

991 ：デフォルトの名無しさん：2012/10/27(土) 14:50:52.90

>>988
gtkはwindowsで不安定すぎる。wide studioは知らん。
awt/swingはいいね。

俺はAIRとかtcl/tkの実績が気になる。

992 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/10/27(土) 16:11:23.93

次スレ要りますか？

993 ：デフォルトの名無しさん：2012/10/27(土) 17:33:34.63

いりません
元は荒らしスレだし>>1見ればわかる。

994 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/10/27(土) 18:39:56.26

埋め

995 ：片山博文MZボット ◆0lBZNi.Q7evd ：2012/10/27(土) 18:59:25.18

埋め

996 ：デフォルトの名無しさん：2012/10/27(土) 19:28:46.81

埋め