5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

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

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システムでは、以下の3つの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に比べて、格段に制約の緩いライセンスとなっています。
制約となる条件がたった2点しかありません。
1つ目は「再配布時には著作権表示を残す」という事。
もうひとつは「無保証である」という事。
この2点を守りさえすれば、どのように利用しても構いません。
ライセンスを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
実際に自分でプログラムしなきゃ
理解したことにはならんだろw

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
論文にざっと目を通してみた。

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

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

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

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

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でシコシコやっていたけど、今じゃあ簡単にできるようになったよね。
むしろ、今の方がどういう経緯というか仕組みで動作しているのか分からなくなった感じだな。
クラスライブラリ便利すぎ( ・ω・)y─┛〜〜

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の場合は、それが当てはまらないw
初級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
VBなら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 開発ライセンス

買えませんw

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
GUIは、サンプル読んでイベントハンドラのとこ重点にソース読んでれば理解が早いと思うよ。
サンプルに処理を追加して、既存のイベントから呼ばせてみると仕組みが分かるかと。
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
>>1
がんばれ〜

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
VS2008の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は簡単だろ?

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

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の無機質なソフトが多いけど
そのうちフェードとか、自作メニューバーとか、3D化してるアプリが当たり前になってきたら
敷居あがりまくりなんだけど

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
4年間もあるのに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
そりゃすまんかったw
俺は今初めてこのスレちょっと見ただけだから

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検索する」という処理と「表示」という処理を
一括りに処理しようとしていないか?
処理の単位を2つ分けて、スレッドなりでそれぞれ処理すれば良くないか?

この場合、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
言葉尻捕まえるくらいしか、突っ込めないのかw

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
いや俺は本当にただの凡人だよw
以前職業的な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
上向き構文解析固有でもないしな
なにも話せないw

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特有の知識も必要だし
理解しなくては出来ない事も多々あるけど
排他で悩むってなんだよとw
それ以前の会話でしょとね。

>>414
包括関係にあるからその論理は成り立たん。

416 :デフォルトの名無しさん:2010/05/02(日) 08:57:57
>排他で悩むってなんだよとw
排他で悩む機会が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編 第1部] と [Windows SDK編 第2部] を
自分でプログラムしながらざっと追えばいい。
1ヶ月くらいでこなせるだろ。
そうすると、高級GUIライブラリや Java のライブラリが
内部で何をやっているのか、だいたい想像できるようになって、
勉強がはかどる。

428 :デフォルトの名無しさん:2010/05/03(月) 10:47:18
>>427
激しく同意
同じこと書こうとしたら先を越されたw

429 :デフォルトの名無しさん:2010/05/03(月) 11:18:42
>>427
うっしゃ! おおきに。意味はよくわからんが、やるきになた。

430 :デフォルトの名無しさん:2010/05/03(月) 12:54:02
>>426
何年もJAVAやってる奴が、C++で仮想関数をようやく理解できたっておかしくね?

JAVAで何をやってたんだw

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の頃から10年以上やって、アプリやアプレットを
数えきれんぐらい作ったけど、
仮想関数なんて見た事も聞いた事もなかったよ。ポインタはうわさぐらいは
聞いたけど。

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
お前は10年間何をやってたんだ?
そんなんじゃ、ろくなものつれないだろ?

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
ということはなんだ、インターフェースの事じゃねぇか。
アプリつくる時にゃ1つや2つは作ってるけど。。。
これで仮想関数なるものがやっとわかったぜおおきに。

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
の4種類あって、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をよく10年もやれたなw

455 :デフォルトの名無しさん:2010/05/03(月) 21:24:47
あえて踏み込まなければなんでもいけるっしょ
ExcelやWordと同じ

456 :デフォルトの名無しさん:2010/05/03(月) 23:09:56
その場限りを続けてるとどうなるのか、身をもって知ったわけだ。
10年は無駄じゃなかった・・・と思うよ

457 :デフォルトの名無しさん:2010/05/03(月) 23:19:55
10年つっても7歳〜17歳だからな

458 :デフォルトの名無しさん:2010/05/03(月) 23:26:41
>>457
っあ、なんだ趣味でやってるような、ヲタでしたかw
だったら、何の問題もないんじゃねw

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
そんなあなたにUML

464 :デフォルトの名無しさん:2010/05/04(火) 17:52:02
>>462
GUIが難しすぎる という以前に自分の読解力、知識のなさを棚に上げるのはどうかと思う

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 時代みたいに
上から下へと処理が流れる時代ではないのよ

色々なプログラムがあって、メッセージを受け取り、どのプログラムに
送信するかOSが決める
そして、そのプログラムを実行するタイミングもOSが管理する
これを理解できない限り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
もしくは、GUIの何が難しいのか原因を探る、考える
自分は、この処理の流れがわかrない
なぜ、こう処理されるのか、
原因と結果を自分で確かめる、実行する 人のせいにしない

時には人に相談するもよし
ここまでくると、自分は、どこのどういう処理、形式が分からないという内容の
発言で自分はここまでは理解できます
という自己表現が必要
自分ができないことを紙にかいてみる
したいことも書いてみる
そこから、何が原因でできないかを考える

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
暇を見つけてやるから
3カ月ほど待ちなされ

502 :デフォルトの名無しさん:2010/05/08(土) 08:21:39
わかった
たとえ3ヶ月後にバージョンアップしてて
つかいものにならなくてても待つ

503 :デフォルトの名無しさん:2010/05/09(日) 08:22:46
俺が大好きなハンゲで麻雀が弟に回線切られてできなくなった
このクソキチガイ弟が

504 :デフォルトの名無しさん:2010/05/09(日) 08:24:40
プロセスとかスレッドとかって何だよ
俺は海外留学できたくらい英語ができる人間様だ
ハンゲじゃ貴族で誰もがおれをしたってる
麻雀もできやしねぇ弟なんかクソゴミ

そんなクソゴミが俺様に逆らうってのは殺されたいのか?あ?

505 :デフォルトの名無しさん:2010/05/09(日) 08:30:54
弟がクソのように何が「ハンゲの麻雀は牌操作してる」だ
お前の理屈なんかききたくものねー
麻雀は通にしかわからない選ばれた者だけの一流のゲームだ

相手の捨て牌さえ見てれば、相手の役なんかわかるんだよクソボケ
麻雀のDVDでも不正はできねぇって言ってるんだ
リアルでも不正できねぇのに ネトゲで不正できるわけねぇだろ

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
麻雀は頭の悪い人がやる遊びだからw

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
>>1の気持ちがよくわかる…

528 :デフォルトの名無しさん:2010/06/02(水) 21:10:52
今SwingでGUIアプリ作ってるんだけど、プログラムより配置とかの設計で悩むのだが何かいい読み物ない?

529 :デフォルトの名無しさん:2010/06/02(水) 21:58:13
>>528
配置だけならデスクトップのアイコンの自動配列をマネれば・・・
どこらへんで悩んでいるのかkwsk

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を選ぶべきでしょう。

でも、(上に挙げた2例のように)プラットフォーム固有サービスの利用が大前提(必須)となる開発の場合、
アプリ内に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やIEでも表示崩れたりihone_demoとか動作しないんだが。
あとは環境によるのだろうけど重すぎて快適なGUIとは言いがたいかも。

595 :593:2010/07/28(水) 21:58:50
>>594
実際に触ってみてくれたんだね。嬉しい。(アクセス規制でレスが遅れた、スマン。代行をお願いしています。)

>FxやIEでも表示崩れたり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

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

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)