08/10/07 06:34:26
.NET嫌いのエンドユーザーって、実際的なことではなく、
「こう言っとけば"わかってる奴"みたいに響くらしいぞ、うひひ」
的な動機で文句言うからなぁ。
毎度文句を言うくらいならランタイムをインストールしたほうが早いのに、
意地でもそれをせずに「.NET対応だと困る自分」を死守してるだろ、彼らｗ
149:デフォルトの名無しさん
08/10/07 08:28:52
>>148
そのインストールが面倒だから文句言ってるんだよ、分かれよそのくらい
インストールだけで時間かかるし
バージョンアップが必要になることも多いし
別PCで動かそうとしたときに面倒だし
150:デフォルトの名無しさん
08/10/07 09:06:41
>>149
インストールより「.NET対応だと困る状態」を維持して
毎度毎度困り続けるほうが面倒だろって言ってるんだよ、分かれよそれくらい。
151:デフォルトの名無しさん
08/10/07 09:10:22
初回起動が遅いのが.NETの最大の難点だと認識している
二番が移植性、インストールの問題は三番目
152:デフォルトの名無しさん
08/10/07 09:10:57
.NETの要る要らないでソフトの作者を叩いたり
ネットで喧嘩したりする時間とやる気はたっぷりありますが、
インストールする時間とやる気はまったくありません、それくらい分かってください。
とか言われても、「分かりません」としか言い様がないんだよね。
153:デフォルトの名無しさん
08/10/07 09:13:23
>>151
初回起動の問題が圧倒的だよね。
そういう「実際的な問題」なら話はわかるし、俺もそれは好きじゃないから、
.NETは趣味の開発では避けてるよ。
154:デフォルトの名無しさん
08/10/07 09:23:03
>>150
仮にWindowsユーザー全員がインストールしたところで、.NETの方がバージョン上がるから同じ事だ
155:デフォルトの名無しさん
08/10/07 09:38:57
それが同じじゃないことに気付かないのは>>148の内容の人ですね、キミは
156:デフォルトの名無しさん
08/10/07 10:14:45
もう既に、この会話のほうが、インストール作業より時間的にも長く
キーボードを叩く量＝人間側の労働コストも多くなってるからね。
これは自発的にやれるけど、インストールはやれません、は通用しないよ。
157:デフォルトの名無しさん
08/10/07 10:15:14
>>152
何でマイクロソフトは Windows Update で強制的に .Net をインストールさせないんだろう？そしたらこういう文句もでなくなるはずだよね。
158:デフォルトの名無しさん
08/10/07 10:27:25
ヒント：M$は製品にﾄﾞﾄﾈﾄを使わない、MFCを使わない、VBを使わない
159:デフォルトの名無しさん
08/10/07 10:28:50
>>157
Vistaでプリインストールされているので自然に普及するという計算だった
しかしそのVistaがあんまり・・・
160:デフォルトの名無しさん
08/10/07 10:46:09
ヲイヲィ、変な門すすめんじゃねーよｗ
ﾁﾞｬｳﾞｧ以下じゃねーか（怒
＞ｽﾚﾘﾝｸ(prog板:863番)
＞VB.netがしょぼすぎるんでC#.netを始めた。
＞Javaと同じ割りに選択肢が乏しくてメリットがないように感じる。
＞俺、間違ってるかな？
161:デフォルトの名無しさん
08/10/07 11:01:39
先ずはM$に製品にﾄﾞﾄﾈﾄを使うように説得してみてはどうだろうか？
話はそれからだ。
162:デフォルトの名無しさん
08/10/07 12:33:54
誰も勧めちゃいないと思うんだが
163:デフォルトの名無しさん
08/10/07 13:01:55
たしかにﾄﾞﾄﾈﾄを勧めるなんてﾃﾗ悲惨すぐる。
そんな痛い香具師いねーかｗ
164:デフォルトの名無しさん
08/10/07 19:48:04
なんか本題からずれてきてるぞ
問題はWxWidget使った実行ファイルのサイズだろ
165:デフォルトの名無しさん
08/10/07 20:33:30
wxTNGがリリースされれば、ファイルサイズはWTLなみに小さくなるはず。
URLﾘﾝｸ(wiki.wxwidgets.org)
166:デフォルトの名無しさん
08/10/08 22:46:13
なんでこんなに盛り上がってるんだｗ
167:デフォルトの名無しさん
08/10/09 19:02:42
>>143
NetBeansで出来た。他のIDEでもいけると思う。コンパイラとリンカのオプションに
wx-config --cflags と wx-config --libs で出力される文字列コピーしてウマー
NetBeansの場合、Runで実行するときにはLD_LIBRARY_PATHに共用ライブラリしていしないといかんけど
168:デフォルトの名無しさん
08/10/10 03:02:54
>>165
wxTNGの完成予定時期ってどっかに書いてる？
169:165
08/10/10 07:52:16
>>168
本来はwxWidgets3.0で対応する予定が、3.0では却下されたみたい。
URLﾘﾝｸ(garrys-brain.blogspot.com)
次々メジャーバージョンの4.0では対応してくれると信じたいけど…。
あと、ちゃんと読んでないけど、wx-discussでの関連すると思しき記述。
URLﾘﾝｸ(lists.wxwidgets.org)
170:デフォルトの名無しさん
08/10/11 01:38:46
>>169
しばらくは現状の仕様のままということですか。
3年後くらいには出てるかもしれないね。
まあ、今のままでも若干MFC臭がするくらいで、そう不便でもないとも思うが。
171:デフォルトの名無しさん
08/10/11 12:56:58
>>167
すいません。wxのコンパイルから、NetBeansの環境設定まで
初心者に分かり易く書いてもらえないでしょうか。
実行ファイルのサイズが大きくなるのは全然平気。使う側も意識しないだろうし。
172:167
08/10/11 17:41:22
>>171
どこら辺が分からない？
全部書いてもいいけど、長文になるだろうから質問に答えていく感じの方が
173:171
08/10/13 01:11:57
NetBeans wxwidgets でぐぐったら良い記事見つけたので
良いや。それ見て、eclipse+CDT+MinGW+msys+WxWidgetsで
環境できたし。
174:デフォルトの名無しさん
08/10/13 08:34:47
NetBeansじゃねぇw NetBeansはMakefile書かなくていいから楽だけどなぁ
175:デフォルトの名無しさん
08/10/14 09:14:31
>>173
結局、お前には
「ググレカス」
って返事しとけば良かったってことだな
176:デフォルトの名無しさん
08/10/19 14:13:35
wxglade使って、骨組みだけパパッと作りたいんですけど、
ボタンなどの部品をフレーム一杯に配置するにはどうすれば
いいですか?サイズに-1,-1を設定するとOS毎のデフォルトサイズが
適用されるみたいですけど、パネル・フレーム一杯に配置する
特定のパラメータってないんでしょうか？
177:デフォルトの名無しさん
08/10/19 15:23:26
>>176
サイザー内の部品について
proportionを1以上にすると、サイザーの方向に伸びる
（サイザー内に複数の部品があれば、proportionの値が大きいほど幅を取る）
Alignment - wxEXPANDをオンにすると、サイザーの方向と垂直に伸びる
178:デフォルトの名無しさん
08/10/19 16:03:11
>>177
出来ました。ありがとうございます。
wxGladeって書いてましたが、よく見たらwxFormBuilderでしたw。
ubuntuで適当に入れたから、wxgladeと思い込んでたけど、
今はwxFormBuilderの方がメジャーなんかなぁ
179:デフォルトの名無しさん
08/10/19 17:15:05
自分はDialogBlocksが一番好き
180:デフォルトの名無しさん
08/10/22 12:55:03
wxWidgetsアプリのファイルサイズはまあ許容できるけど、
minimalサンプル実行時のメモリ使用量が40MB近くってどういうことだ？
$ wx-config --list
Default config is gtk2-unicode-debug-2.8
だけど、debugビルドだから？
181:デフォルトの名無しさん
08/10/22 22:43:01
DialogBlocksいいよな
軽いしコメント消せば余計な補完しないし
最初はテキストエディタで直接弄った箇所を
消されたりしてその良さがわからんかったけどな
182:デフォルトの名無しさん
08/10/23 00:16:17
DialogBlocksの宣伝するのなら、環境構築のやり方教えてちょ。
183:デフォルトの名無しさん
08/10/23 10:12:52
>>182
今、試してみた。
環境がwindows+visual C++なら、dialogblocksインスコすれば
勝手にコンパイラとかの検知はしてくれるみたい。あと手動で、
Settings->Path->WXWINに、公式サイトから落としてきたwxMSWを
解凍したフォルダを設定すればいけたよ。ただ、ビルドオプションが
ReleaseとDebugしかないってのは…。Unicodeを設定する方法とかあったら
補足よろしく
184:デフォルトの名無しさん
08/10/23 14:15:51
>>182
おう、興味をもってくれる人が出てくるのを待ってたぜ
URLﾘﾝｸ(www.anthemion.co.uk)
で、
DialogBlocks 4.27 Developer Bundle for Windows NT/W2K/XP/Vista (Unicode).
を落としてインストールだ。
DialogBlocks、wxWidgets、MinGWがいっぺんにインストールできる
wxwidgetsとMinGWは共にデフォルトのパスにインストールを推奨
MinGWはG++とMinGW-Makeを選択すること。
Webインストールで、たまにファイルが落ちてこないことがあるが
何度かリトライすればインストールできるのでキャンセルはしないこと。
DialogBlocksからwxWidgetsをコンパイルできるのでMSYSはいらない。
すでにwxWidgetsとMinGWをインストールしている場合は
DialogBlocks初回起動時にウィザードがでてくるのでそれに従って
それらのパスを指定するだけ
Bundleをインストールした場合は自動的にパスが検知されてる
細かい選択肢がインストールの間にいくつか出てくるのでダレないこと。
知ってるかもしれないがwxWidgetsのコンパイルもえらい時間がかかるので
やっぱりダレない事。
あとDialogBlocksは言語が選べるけど英語かドイツ語しかない
だけど基本的なことは他のIDE(Visual Stadioとか)とほぼ似通っているので
なんとなくで判るはず。
これでProjectを作れるところまでいける。正味2時間ぐらい。
>>183
View→Settings→Configration→Add でいけない？
185:デフォルトの名無しさん
08/10/23 17:45:16
>>184
unicode設定できたサンクス。
にしても、高機能過ぎない？コンパイル出来ることにビビッたんだけどw
186:デフォルトの名無しさん
08/10/23 19:46:17
結局簡単な設定とかだけで日本語が通るwxWidgets向けIDE/RADはないってことでFA？
187:デフォルトの名無しさん
08/10/23 20:56:39
ないんじゃね
意味が二つ取れるけどとりあえずないんじゃね
188:デフォルトの名無しさん
08/10/23 21:54:57
gccは--input-charsetと--exec-charsetで、
windresは--languageでASCII以外が通るってことみたいだから
あとはIDE/RADがSJIS or UNICODEで編集・出力できるか、
にかかってるんじゃないかと思ったのよ
189:デフォルトの名無しさん
08/10/24 01:05:42
＞＞１８４
一回、インストールしてみるわ。
190:デフォルトの名無しさん
08/10/24 09:14:50
>>184
超乙！
191:デフォルトの名無しさん
08/10/31 23:38:41
誰か、DialogBlocksを日本語化してくれ。
192:デフォルトの名無しさん
08/11/01 10:20:10
>>191
がんばれよ
URLﾘﾝｸ(www.poedit.net)
193:デフォルトの名無しさん
08/11/01 10:24:44
つかさ、クレクレばっかじゃなくてもっと話題が広がる振り方ないの？
まあバリバリのwxプログラマはwxcomunityで英語で意見交換してんだろうなぁ
194:デフォルトの名無しさん
08/11/01 16:51:08
してる人いるのかなぁ。
個人的にマルチバイト周りの強化して欲しいと思ってるが英語でメールするのが億劫でいまだしていない。
195:デフォルトの名無しさん
08/11/01 23:27:23
>>194
「して欲しい」というのがまず間違ってるんでないの。オープンソースなのに。
196:デフォルトの名無しさん
08/11/02 00:25:42
べつに間違ってはいないと思うけど
オープンソースだからパッチ書かずに要望出すな、ってことはないでしょ
パッチ出した方が早いってだけで
197:194
08/11/02 01:40:50
今んとこそこまでやれるレベルのプログラマではないので^^:
198:デフォルトの名無しさん
08/11/02 01:45:24
具体的にマルチバイトのどのあたりを強化して欲しいの? >>197
ユニコードでやっとけばとりあえず問題ないとおもうんだけど。
199:デフォルトの名無しさん
08/11/02 02:51:18
ユニコードが使えない環境で今更作りたくないな
200:デフォルトの名無しさん
08/11/02 03:05:30
話題が広がらないのは、もうwxWidgetsが枯れてるからじゃない？
MFCからの蓄積があるから、基本的なデザインで悩むとこなんてほとんどないし、
個々のクラスの使い方もドキュメントを見れば一発だから。
wxTNGは熱くなれそうだけど、一部でしか盛り上がってないからどうしようもない。
MFC上がりのおっさんが、クロスプラットフォームな何かを
経験を生かしてさくっと作るライブラリってことでいいじゃない。
201:デフォルトの名無しさん
08/11/02 03:54:45
ML読んでればわかるけど、文字を表すのに1バイトで足りない文化圏の人は素直にUnicodeビルド使ってねというのがVZたちの基本的スタンスよ。
202:デフォルトの名無しさん
08/11/02 22:51:35
VZってVadim Zeitlinのことだよね
Samplesでよく見かける
関係ないけどこの人たちが8年前に書いたソースで勉強してるんだなあと思うと
先駆者との距離の開きに焦りを覚えるよ
203:デフォルトの名無しさん
08/11/02 23:42:27
まあUnicode使用は妥当だろうな。
ShiftJISはダメ文字問題が面倒臭すぎる。
204:デフォルトの名無しさん
08/11/04 02:27:04
Unicode問題、よく言われてるけど、
正直、いまのままでもあまり困ってない。
(wxString て言ったって、setup0.hを変更すれば std::stringになるのだし・・・。)
具体的に、何に困ってるの？
205:デフォルトの名無しさん
08/11/17 06:50:39
ライブラリのビルドで--disable-threadsをつけるのが常みたいですが
スレッド作らなきゃいけない場合どうしてますか？
206:デフォルトの名無しさん
08/11/25 13:59:57
結局Mac OS X でwxする場合、どの開発環境が良いんだろうね？
207:デフォルトの名無しさん
08/11/26 17:03:52
正直ほかの環境で wx で書いて出来たものを持ってきてからコンパイルして
微妙にいじるのが正しい気がする。
OS X 専用なら wx で書く必然性が全くない。
wxPerl と wxPython は標準の OS X にインストールされているのでそれを使うのが正解かもしれない。
208:デフォルトの名無しさん
08/12/07 03:36:00
パソコン変えたので新しくwxWidgetsインストールしようとしたら./configureで失敗します・・。
windows xp professional
msys 1.0.10
mingw 5.1.3
wxMSW 2.8.8
で、MSYSから
./configure --disable-threads --enable-monolithic --enable-unicode
を実行すると
please set CFLAGS to contain the location of windows.h
というエラーが出て止まってしまいます。。
どなたかお助けください。。ｍ(_ _)ｍ
209:208
08/12/07 03:38:10
MinGWはc:/msys/1.0/mingw にインストールしています。
CFLAGS=c:/msys/1.0/mingw/include
とかやってみてから./configure してみても変わりませんでした。
210:デフォルトの名無しさん
08/12/07 04:28:28
w32apiは正しくインストールされてるのか
#それに CFLAGS はコンパイラオプションで直接ディレクトリを代入しても認識しないと思うがたぶん
211:デフォルトの名無しさん
08/12/07 05:55:09
mingwを後から入れたってことだからmsysから/mingwへのパスが通ってないとか？
c:/msys/1.0/etc/fstabに
c:/msys/1.0/mingw /mingw
って入れとけば間違いないかも
mingwはインストーラーで全部チェック入ってれば問題ないと思う
あとビルドするときはビルド用のディレクトリ作って、その中から../configureした方がいいよ
212:208
08/12/07 13:45:21
ありがとうございます。
いろいろ試してみているのでがまだ解決しません。
msysからgccとかでコンパイルはできるので、mingwのパスは大丈夫そうです。
./configure 途中の出力見てると、どうもSegmentation fault がでまくっている感じのようです。
これのせいかなと思うのですが、Segmentation fault ってのは要は他のプログラムと競合しているということなのでしょうか？？
バックグラウンドで動いてるプログラムを停止したりしてみながらいろいろ試しているのですが・・
213:208
08/12/07 14:18:59
./configureを走らせるタイミングによってエラーの結果が変わります。
一回 segment fault 吐きながらも最後まで./configure が終わったのですが、案の定make でエラー終了しました。
どうしたものか・・
214:デフォルトの名無しさん
08/12/07 14:55:01
そのエラーメッセージを書かないことには・・・。
215:208
08/12/07 15:31:27
エラーの内容毎回変わります・・
216:215
08/12/07 23:47:45
エラー吐きまくりつつもなんとか簡単なプログラムはビルドできるようになりました。
ありがとうございました。
しかしMSYSがなんかおかしいのか・・
217:デフォルトの名無しさん
08/12/08 00:06:23
>>216
それはビルドできるようになったとは言わない
218:デフォルトの名無しさん
08/12/08 10:47:15
>>216
ハードディスクがいかれているんじゃない？
chkdsk してみた？
Segmentation fault ってのは例外が発生しているんだけど
普通は起きないようなエラーだから、ハードウェア的なトラブルなんじゃない？
219:デフォルトの名無しさん
08/12/08 11:57:47
configureを使用しないという選択はないのか…
220:215
08/12/08 16:40:27
ご親切にありがとうございます。
>それはビルドできるようになったとは言わない
wxWidgetsのインストール時にエラー吐きまくっているが、簡単なプロジェクトのビルドはできるようになったということです。
たぶんコンパイルできなかったスタティックリンクライブラリがかなりたくさんあるのでもちろんどうにかしなければと思ってはいるのですが・・
>>chkdsk してみた？
chdsk 知らなかったのでやってみたところ、破損ファイルを回復しています・・みたいのが一つでたのですが、
その後./configureしてみてもやはりSegmentation fault は出ました。
ハード的になんかおかしいってことなんでしょうか？
そもそもMSYSのインストール時点で
Couldn't reserve space for cygwin's heap
という変なエラーが出てるんですよね。
この症状は報告例があって、調べてなんとかMSYSは動くようになったんですが、
もしかしたらそのせいでMSYSが完全に正常には動かないような状態になっていて、それでwxWidgetsの./configureでSegmentation fault が出まくるのかなと思ってたのですが・・関係ないでしょうか？
>configureを使用しないという選択はないのか…
そんなことできるんですか？？
221:デフォルトの名無しさん
08/12/08 23:57:59
>>220
一旦、すべてアンインストールして、一からやり直したほうが早いんでないかい？
MinGW、msys、環境設定、wxWidgetsのインストール全て。
以下で親切に解説されてますよ。
URLﾘﾝｸ(labs.unoh.net)
222:デフォルトの名無しさん
08/12/09 03:18:56
ドキュメントにmakefileを直接使う方法ってのが載ってるじゃん
俺はむしろMinGW環境ではこっちが標準だと思ってたんだけど
MSYSからじゃなくてコマンドプロンプトからになるけど
mingw\binに環境変数でPATH通してから
> cd c:\wx\build\msw
> mingw32-make -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1 UNICODE=1 USE_THREADS=0
みたいにビルドできるよ
つか、install-msw.txtくらい読むものじゃないの…？
223:デフォルトの名無しさん
08/12/12 00:42:03
結局どうなったんだ…？
つかmakefileを直接使う俺は異端なのか…？
224:デフォルトの名無しさん
08/12/15 07:49:17
wxHtmlWindowに日本語を含むHTMLを読み込ませて、
マウスドラッグで日本語を選択するときに場所によって文字が化けるんですが、化けないようにする方法はありますか？
225:デフォルトの名無しさん
08/12/15 08:04:50
ユニコードビルドにしたら改善しない？
それで駄目なら wx のソースをいじらないとどうしようもない気がする。
というか wx で日本語がきめ細かく動くことを期待してはいけない。
226:デフォルトの名無しさん
08/12/16 03:15:54
DialogBlocks固有の問題だと思うんだけれども、
wxTextCtrlの初期値に"_"が含まれてると、"%"になっちゃう。
使わなければ良いだけなので回避してるんだけど、ちょびっと気持ち悪い。
227:デフォルトの名無しさん
08/12/25 05:08:59
こんなに至れりつくせりなライブラリなのに
日本では全然盛り上がらないな。
228:デフォルトの名無しさん
08/12/25 09:46:19
＞こんなに至れりつくせりなライブラリ
どこが？
＞日本では全然盛り上がらないな
海外では流行ってるのか？
229:デフォルトの名無しさん
08/12/25 09:53:38
Ubuntu 8.10 で、 wxGTK ダイアログ中のテキストボックス上で Atok X で変換すると、
確定するときに Enter キーを押すと OK ボタンが押されてしまう。
GTKアプリではこんなことが起こらないから、 wxGTK の input method あたりが
何かおかしいんだろうけど、何が悪いのかさっぱり判らない。
230:デフォルトの名無しさん
08/12/25 14:28:58
>>228
C++
オープン
クロプラ
日本語可
GUIウィジェット網羅
非GUI系ラッパも豊富
豊富なドキュメント
RADの充実
スタティックリンク可
多ビルド
これだけのものは他にないな。
>海外では流行ってるのか？
はい。
231:デフォルトの名無しさん
08/12/25 23:04:51
>これだけのものは他にないな。
Qt ...
232:デフォルトの名無しさん
08/12/25 23:13:21
流行らないのは、「クロスプラットフォームなGUIアプリ」のニーズが
少ないから
ポータブリティがタダで（犠牲なしに）手に入るのならいいが、残念ながら
そうではないしな
233:デフォルトの名無しさん
08/12/26 00:34:10
宣伝してないのと日本語資料が無きに等しいからだろう
234:デフォルトの名無しさん
08/12/26 08:55:58
>>231
やっぱ、Qtってメチャクチャ良いの？
クロスプラットフォームの開発にwxDev-C++でやってるんだけど、
C++ Builderには遠く及ばない感じがして。。。
235:デフォルトの名無しさん
08/12/26 14:03:04
230に
ライセンスがうざくない
OSネイティブのTKで動く
も入れるとQtは却下だな。
236:デフォルトの名無しさん
08/12/26 14:41:05
>>235
Mac OS X 上では ネイティブ度？は Qt のほうがマシだベ。
まあ誰も wxMac をつかってなさそうでメンテされてないからだろうけど。
237:デフォルトの名無しさん
08/12/26 19:47:15
VCL
○C++（少しDel臭いがMFCよりはマシ）
×オープンソース
×クロスプラットフォーム
◎GUIウィジェット
◎非GUIラッパ
○ドキュメント
◎RAD
○スタティックリンク可
MFC
○C++（かなりインチキ臭いマクロとか多いが）
×オープンソース
×クロスプラットフォーム
×GUIウィジェット
○非GUIラッパ
○ドキュメント
×RAD
○スタティックリンク可
WTL
◎C++
◎オープンソース
×クロスプラットフォーム
×GUIウィジェット
○非GUIラッパ
×ドキュメント
×RAD
○スタティックリンク可
238:デフォルトの名無しさん
08/12/26 19:47:55
誤爆った
239:デフォルトの名無しさん
08/12/26 21:23:30
なんでスタティックリンク可不可って問題なの？
Windows でもインストーラ書けばいいのでは？
Linux だったら .rpm とか .deb でいいし、
OS X なら .app パッケージに全部つっこめばいいよね...
240:デフォルトの名無しさん
08/12/27 00:28:37
ある時見つけた便利そうなソフトがインストーラしかないと知ってスルーした経験ない？
241:デフォルトの名無しさん
08/12/27 01:14:27
できないよりはできたほうがいいな。
242:デフォルトの名無しさん
08/12/27 10:54:50
>>240
ないけど...
ていうかインストーラ無いやつは Program Files 内に入らなくて
自分でフォルダ管理しないといけないからウザイ
243:デフォルトの名無しさん
08/12/27 15:19:17
会社とかで、さっくりと作ったアプリを
もらった時とかに、インストーラーがあると逆にうざくて
しょうがないときとかない？
何で、わざわざインストールが必要なんだ？とか
244:デフォルトの名無しさん
08/12/27 15:57:20
そんなことより Windows Update がうざい
245:デフォルトの名無しさん
08/12/27 16:13:48
ちょっと試してみるだけだったり、気に入らなければすぐアンインストールする
つもりのことが多いから、インストーラ無しのほうがいいな
フリーウエアでインストーラ付きだと、インストールするのをやめることもある
いやな予感がするときとか
246:デフォルトの名無しさん
08/12/27 16:23:45
インストーラが本当に必要なレベルの大型ソフトなんて個人では作らんよ
247:デフォルトの名無しさん
08/12/27 17:01:06
あとスタティックリンクできないと
なんのライブラリつかってるかもろばれじゃん。
有用なライブラリは同業者に教えたくないし。
248:デフォルトの名無しさん
08/12/27 17:33:01
>>247
その発想はなかったわｗｗｗ
249:デフォルトの名無しさん
08/12/27 19:53:37
そうか、インストーラ拒否症のひとって多いんだな。
自分がそうでないからわかってなかったが、
今後はスタティックリンクするようにしよう...
250:デフォルトの名無しさん
08/12/27 21:50:07
それにしたって、実行ファイルと同じフォルダにdll詰めてzipで配布すりゃ良いんじゃないの？わざわざスタティックリンクしなくても。
>>247
さすがにそれはねーよwどんだけ情報弱者の同業者想定してんのｗ
そのしょぼい独占欲で守られる利益なんて大してねーよw
251:デフォルトの名無しさん
08/12/27 23:52:23
やたら巨大なライブラリの一部の機能しか使わない時なんかは、
サイズ的にスタティックリンクの方が効率いいかもしれん。
まあ、そんなにサイズを気にするご時世じゃないけどね
252:デフォルトの名無しさん
08/12/28 01:48:53
スタティックリンク最大の利点は精神衛生上
ちょっと一端のプログラムを一人で作りあげた感を得られることだろう。
Windows慣れしてると、なんか変なdll置いてあるだけで
どことなく「ライブラリ頼りのトーシロ」感がかもしだされてしまう。
それよりはやっぱり実行ファイル一つ、のほうが気持ちいい。
253:デフォルトの名無しさん
08/12/28 03:12:08
Windows自身がライブラリの塊じゃん
254:デフォルトの名無しさん
08/12/28 04:11:19
実行ファイル一個で済む方が気分が良い
255:デフォルトの名無しさん
08/12/28 06:44:07
動的リンクなら、ライブラリに脆弱性が見つかったときに
そのアプリがメンテされて無くても対応できる可能性が！
いや、まずないけどね
256:デフォルトの名無しさん
08/12/28 11:10:28
>>252
ひとによって考え方が違うのは承知の上で聞くが、
全然わからん。プログラム書いた本人は
何のライブラリ使ったか覚えてるわけでしょ？
見た目だけちがうだけでなんで気持ち良かったり気持ち悪かったりするの？
257:デフォルトの名無しさん
08/12/28 13:32:06
windowsユーザーの意見だけど……
dll使用が嫌われるのは「俺のPCのシステムに変なの仕込むな」つうことだけでしょ？
dll hellとかも嫌だし、アンインストールするときにキレイになるか判らんし。
exeと同じフォルダに仕込んどけばシステムにインストールする必要は無くなるけど、
dllのメリット無くなるしね。
258:デフォルトの名無しさん
08/12/28 13:37:21
動的リンクで後から脆弱性が直せる可能性があるなら
同じように後から脆弱性を作り出せる可能性もあるのかな？
259:デフォルトの名無しさん
08/12/28 14:46:08
最近はサイドバイサイドとかマニフェストとか色々めんどくさい
260:デフォルトの名無しさん
08/12/29 22:37:21
>>250
いやあ、それが気になるのですよ。
うちの場合、
「ダイナミックでいれたランタイムを他のアプリが勝手に入れ替えた場合の保証がとれない。」
という理由で、お試しに作ったソフト・出荷ソフトの区別なく
一切ダイナミックリンク禁止になってます。
ちなみに、うちでは工場系のソフト（VC6 MFC製）を扱ってます。
工場のマシンに勝手にアプリを入れる馬鹿がいるとは思えないので、
ダイナミックだろうがスタティックだろうが、関係ないはずなのですけど・・・。
もしかして、OSのサービスパックが勝手に更新する、Cランタイム／MFCライブラリ
に対しての評価のことを気にしてるのか？
261:デフォルトの名無しさん
08/12/29 22:54:58
全然素人なんだけど、工場って WIndows つかってるの？
でかい機械をコントロールしてるときに Windows がブルースクリーンになったら
どうするんでしょう？危険でない？
Windows ベースのタッチパネル端末で良く異常終了して
エラー画面になって止まってるのをみるんだけど...
262:デフォルトの名無しさん
08/12/29 23:36:26
監視端末(Windows)と機械のファームは別だろう。
端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず
263:デフォルトの名無しさん
08/12/30 00:23:35
>>261 >>262
もちろん、機械のファームはWindowsではないですが、
監視端末はWindows2000です。XpやLinuxにするだけのメリットがないので。
枯れた技術(STLですら新技術扱い)・枯れたコンパイラーしか(いまだに、VC6だぜ)使わせてくれないから、ブルースクリーンになることは、まずないよ。
>端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず
のように設計指示はしてるのだけど、実際に作ってるのがFSIの新人だから、
評価だけはしっかりやらせてる。
264:デフォルトの名無しさん
08/12/30 00:43:11
なるほど！安心しました。まあ従業員の命がかかってるからそりゃ対処してるでしょうね。
265:２６３補足
08/12/30 01:05:15
EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、
同じDLL（Version違い）がWindowsディレクトリにあった場合に、
動作してしまう可能性がある。
DLLのVersionチェックとかできればいいのだけど、
Versionチェックそのものがバグってた場合や、Cランタイム／MFCランタイム
に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。
Version差分によって修正されたDLLの場所に、
競合とかリークとか実装上のミスがたまたま引っかかって、
１％の確率で落ちたりしたら、だれが責任とるんじゃ？という問題があるのよ。
１００万個作る場合、１万個の不良が出てしまう。。。
だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。
リスク軽減。その辺ってかんがえてる？
266:デフォルトの名無しさん
08/12/30 04:29:07
ダイナミックリンカのバージョンが変われば問題も起こるからなぁ。
プロトコルが決まっていればいいんだが、
プロトコルが一定でない関数呼び出しみたいなものは出荷検査みたいなのに対応できない。
267:デフォルトの名無しさん
08/12/30 18:15:34
>>265
まず言っとくけど、安全側に倒すってのもわかるし、DLLを強制するわけでもないぞ。
>EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、
>同じDLL（Version違い）がWindowsディレクトリにあった場合に、
>動作してしまう可能性がある。
これはそういう風に依存するDLLを自動検索するよう作ってるからであって
.localファイルなりDLLを絶対パスで指定するなりすればいいんでないの？
>DLLのVersionチェックとかできればいいのだけど、
>Versionチェックそのものがバグってた場合や、Cランタイム／MFCランタイム
>に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。
バージョンチェックがバグってたら、てそれはバージョンチェックするのはDLLホスト側なんだし
そんなバグ出るかもなんてレベルでホスト側のテスト通してるんならスタティックリンクしようがダイナミックリンクしようが
バグ埋め込みそうなものだけどなぁ。
Cランタイム／MFCランタイム側まで問題があった場合なんて言ったらそれこそスタティックリンクしようがダイナミックリンクしようがどうしようもないじゃないの。
ちなみにDllGetVersion()とかCOMとかCOM相当の自前でインターフェイスベースでコンポーネント作るとかやれば
バージョン違いでのDLLを使用することはそれなりに避けられるんじゃない？
>だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。
>リスク軽減。その辺ってかんがえてる？
その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。
全てのフローを網羅するとなったら個々のモジュール間が全て統合された場合の状態を全部網羅しなきゃならないし、
一部だけテストするとなったらなったでカバーしなきゃならない状態のテスト漏れとか起こりそうだし、
DLLでモジュールを細かく分割統治するより別側面でのリスクが増大しそうな気がする。
268:267
08/12/30 18:17:14
今気づいたがぜんぜんwxWidgetsと関係ない話に脱線してるな。ｺﾞﾒﾝﾅｻｲ。
269:デフォルトの名無しさん
08/12/31 16:23:30
いや、おもしろいよ。どうせ閑古鳥スレだし。
270:デフォルトの名無しさん
08/12/31 16:39:20
wxWidgets の場合、公式バイナリのような dll が無いので、 dll をほかの wxWidgets アプリと
共有しようとしたら違うconfigやコンパイラでビルドされた dll を使ってしまう可能性があって危険。
(C言語の場合ABIが決まってるけど、C++だとコンパイラのバージョンそろえないと怖い)
だから、wxWidgets の dll を system32 とかにぶち込む気にはなれない。
dllを共用できないのであれば、スタティックリンクにした方がいらない関数をリンクから外すとか
できるのでサイズが縮む。起動時間もダイナミックリンクがいらない分早くなるはず。
271:デフォルトの名無しさん
08/12/31 16:54:07
>>267
単純に疑問なんだけど、リンク形態によってテスト工数が変わる理由がわからないんだが
単純に配布のファイルフォーマットの話じゃないの？
どっちにしろテストは全部しなきゃならんわけで
272:263
08/12/31 17:17:47
>>267
たしかに、評価工数とかを考えると、フツーにモジュールを別にしますね。
>その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。
ええおかげさまで、ひどい目に遭いましたよ。帰れない日々が・・・。
COM形式なら、最悪IFクラスそのものを切り替えてしまえばいいので
それもありですね。
やっぱ、状況しだいなのかな。
273:デフォルトの名無しさん
08/12/31 17:40:14
>>271
前に、 モジュール（DLL←→EXE）間の、
「構造体メンバのアライメント指定」が不一致が原因でメモリ壊してる
バグがあったです。と言うのは関係ないか。
どっちかというと、バイナリとしてのモジュールが違うから、
別の担当者に作業を割り当てることができるから、というのも違うな。
LIBにするのだから、IFでわけるわな。
納品される側から考えたら、DLLでもLIBでも対して違いはないですな。
作る側から考えたら、DLLの概要仕様から作らなきゃならんわけで、
めんどくさいてのはあるかも。
外注に、「DLLの要求仕様を出してないんかい」てのは、なしの方向で。
274:デフォルトの名無しさん
08/12/31 17:48:18
DLLは基本的に「そうせざるを得ない」場合にしか使わないなぁ
275:デフォルトの名無しさん
08/12/31 18:09:06
お前ら完全にスレ違いだが
いいぞもっとやれ
276:デフォルトの名無しさん
08/12/31 18:40:32
そもそも、ネタがない・・・。
無理矢理作るか？
「wxwidgets乗ってたはずのC++Builder X ってどうなったんだ」とか？
これからやろうとしてるのだけど、
MFC製Dialogベースアプリを、
wxWidgetsのMDIの一画面にしてまともに動くのかとか？
277:デフォルトの名無しさん
08/12/31 19:11:49
mfcのdllとか危険過ぎる。
278:デフォルトの名無しさん
08/12/31 23:10:02
ちょっと気になった＆連絡。
あけましておめでとうございます。
SVNのVCプロジェクトファイルなんだけど、
今までマルチバイトのはずだった(Debugと、ユニバーサルじゃない方)設定
が全部、Unicodeビルドになってる。。。
2.9に更新する場合は、wxString → char*変換周り、全部直さないとだめぽ。
279:デフォルトの名無しさん
09/01/01 04:24:51
>>278
それ以前に、ASCIIで事足りる文化圏の人間じゃないなら、最初からUnicode使っておけよ。
280:デフォルトの名無しさん
09/01/01 13:30:08
>>278
前スレとかにあったような気がするんだけど、wxWidgetsの3.0からUnicodeに統一されるよ。
詳細は以下のサイトとかが参考になると思う。
URLﾘﾝｸ(wxwidgets.blogspot.com)
281:デフォルトの名無しさん
09/01/01 20:38:42
wxとboostがあればもう何もいらない。
これでSOHO GUIアプリ請負で25歳月収60-70万だぜ。
282:デフォルトの名無しさん
09/01/02 21:05:10
>>281
すごい。SOHOって仕事は自分で営業して取ってくるの？
283:デフォルトの名無しさん
09/01/02 23:21:46
発注元の慈悲に過ぎん。あと有能な営業なら同じ仕事でも100万で取ってくる。
284:デフォルトの名無しさん
09/01/03 01:49:01
マ板ネタになりそうだからこれで最後にするが
>>282
もちろんそうよ。ただ、特定の取引先と運良く良いコネが生まれたってのもある。
283のいうとおり、相手の良心に依存してるのはたしかだ。
まだwx自体が知られてなくて、それなりのGUIを作れるわりに
オープンでクロスプラットフォームということもあって
ある程度安心してガンガン技術習得に時間投資できるから
技術的精度が良かったり小回りが効いたりで客の評価は概ね高い。
285:デフォルトの名無しさん
09/01/03 02:17:40
webやDB込みだよね？
スタンドアロンなアプリで60ならすごいな
286:デフォルトの名無しさん
09/01/03 02:52:57
たしかにスキルがあって良いコネがあれば，そんぐらいもらえるかもなあ…
羨しすぎる
287:デフォルトの名無しさん
09/01/03 09:25:49
個人は浮き沈みが激しいから最高値だけで語れないし
将来が不安すぐる
俺も学生の時に某大手商社から個人契約でやらないかって言われたけど
２年後くらいにその商社の社員の賞与が全額カットとかで
行ってたら余裕で切られてたはず
で、今はニートな訳ですが何か？
288:282
09/01/03 14:16:16
>>287
自分も今は無職だよ。
ハローワークとかでも、ちょこちょこMFC使った案件の募集をやってる(自分は面接で落ちてしまうけど)んで、
そのままクロスプラットフォーム対応にしたwxWidgetsもそれなりに需要はあると思う。
ただ、wxWidgetsはAUIとかが今後メンテ・拡張されてくのかちょっと不安。
VS2008SP1のMFCみたいな強力なGUIとか、今後開発されるのかな？
289:デフォルトの名無しさん
09/01/03 15:28:01
無職ならOSSで名を売る作業に戻るんだ
けど、OSSから職に繋がったのなんてほとんど聞いたことない
290:デフォルトの名無しさん
09/01/03 16:49:55
AUIってドッキングインターフェース？
一般的なアプリでそれほど必須の機能とは思えないけど…
ドッキングできる場所が限定されれば自分で書くのもそれほど大変じゃなさそうだし
市販アプリならスキン的にやたらエキセントリックなUIにしたがるからそっちの方をなんとかしたほうが
wxWidgetsは何処ぞの組み込み系描画ライブラリ企業からバックアップ受けてるから
wxUniversalだのの、コンポーネントを自己描画する方向性ばかりが強まりそう
でもSwingでさえLook&Feelはそれほど発展しなかったのに
wxUniversalにどれほどの需要と将来性があるか個人的には非常に不明だわ
ハロワでMFC案件なんてあるんだ、行ってみようかなぁ
291:デフォルトの名無しさん
09/01/03 18:55:11
こんなスレまでハロワとかの話題が出てきて
悲しい気分になってきた．．
292:デフォルトの名無しさん
09/01/03 21:09:04
ハロウは楽しかったなあ。俺はあんまり仮装には参加できなかったけどね。
293:282
09/01/03 21:22:39
>>289
OSSが仕事で出来れば、それに勝る幸せはないかも。
>>290
wxMac(wxCocoa?)はMac持ってないんで良く分からないんだけど、
wxGTKではMDIがノート(タブ)形式になってしまうんで、LinuxでもMDIっぽいことを
やろうとすると何だかんだでAUI頼みになりそうな気がする。
wxUniversalは個人的には黒歴史として闇に葬り去られて欲しいんだけど、
wxPythonとかではむしろ積極的に活用されてるのかな？
>>291
ごめん、ハロワとかの暗い話題はこの辺でやめときます。
294:デフォルトの名無しさん
09/01/12 12:28:27
290みたいな御託だけで何もしなさそうな奴が、無職なのはすごく納得する。
295:デフォルトの名無しさん
09/01/12 15:59:53
wxBlogの方で以下の記事を見かけたんだけど、
日本語に翻訳されたものって何処かにあるのかな？
[wxBlog: Another Year of WX]
URLﾘﾝｸ(wxwidgets.blogspot.com)
[The Wonderful World of wxWidgets 3.0]
URLﾘﾝｸ(svn.wxwidgets.org)
296:デフォルトの名無しさん
09/01/12 17:45:04
>>294
御託だけで何もしないか、そうか、悪かったな。
>>295
概要だけで許せ
[wxBlog: Another Year of WX]
●2008年のwxの大きな動き
・コード書きより環境の改善が大きかった。
・sourceforgeのバグトラッカーをやめてTracを使うようにした。
・BuildBotを導入してビルドエラーを自動検出するようにした。
・Doxygenを使ってドキュメントを自動生成できるようにした。
●2008年に決定した戦略
・wxMacについてCarbonベースからαレベルではあるがwxCocoa(wxOSX)に移行を開始した。
これにより32/64bitの両環境に対応しUnixスタイルのdynamic libraryからframeworkに移行できる。
・ライブラリの品質向上。
これにより（長くメンテされておらず、バグが多く非互換性が強くなった）ODBCのサポートがドロップする。
同様にかなり酷い状況だったwxSocketとwxURLがクリーンアップされた。
全てではないがいくつかのwxGridの問題が修正された。
297:デフォルトの名無しさん
09/01/12 17:45:28
（続き）
●機能追加
・wxPorpertyGridがwxWidgetsに含まれた。
・wxDataViewCtrlと関連クラスが結構良くなった。
・wxRichTextCtrlが多くの小さな修正で重要な改善を果たした。
・wxGrid/wxListCtrlのカラム表示サポートの一部としてwxHeaderCtrl、
wxRearrangeListと関連クラスが追加され、カラムの順序変更が実装された。
・wxWrapSizerが追加された。
・wxCalendarCtrlがネイティブ実装になった。
・wxMessageDialogが改良され、特にボタンにカスタムラベルが使用可能になった。
・wxStaticTextがいくつか改良され、内容の省略をサポートした。
・wxGLCanvasがアンチエイリアスをサポート。
・AUIの主要な変更はwxAUIToolBarの追加。
・ついにwxBaseにイベントのサポートが追加された。
・忘れてるだけで他にもあるかも。
●他
・2.9.0の開発ブランチをプレビューリリースできなかった。
Unicode関連のフィードバックを取り込むため可及的に早くしたい。
・wxButtonで画像をサポートして欲しいという要望が多い。簡単なのですぐやる。
・今年はwxOSXを完成させて3.0をリリースしたい。
298:デフォルトの名無しさん
09/01/12 17:46:52
[The Wonderful World of wxWidgets 3.0]
Documentation in Doxygen
・3.0までにカスタムLaTexでドキュメントを整備する。
・ドキュメントの質を上げるためDoxygen形式を採用するが、手作業がかなり必要。
・これで3.0までに内容が見やすく正確になり、
ビルトインサーチや多くのコントロールのスクリーンショットが含まれる。
C++ features and template support
・STLはバギーな環境・コンパイラが多かったので避けてきた。
・が、大分良くなったので以下のようなSTLが有効な部分で使用する。
コンテナwxVector<T>、スマートポインタwxSharedPtr<T>、弱参照wxWeakRef<T>等々。
・Visual C++ 6.0のような古いシステムではwxが使えないか、機能制限される。
Platform features and backwards compatibility
・プラットフォームの新機能を取り込む一方、
最新のシステム向けの開発を阻害しない範囲で互換性もサポートしてきた。
・特にOSXとGTK+2が問題で、10.4Tiger未満のOSXと2.4未満のGTK+2は非サポートに。
・クロスプラットフォームなDB APIは本来範囲外だろということでwxODBCはドロップ。
299:デフォルトの名無しさん
09/01/12 17:48:24
Unicode: A Single Build for Everyone
・3.0までは歴史的経緯によりUnicodeビルドとANSIビルドの2つが存在する。
・WindowsやJavaはUTF-16を使いGTK+やOSXがUTF-8を使う時代になった。
・ANSIモードは削除。WindowsではUTF-16、それ以外ではUTF-8を使うことを決定。
UnixとGTK+での呼び出しで異なるUnicode表現間の変換は不要になる。
wxString、wxPrintf()等はUnicodeと8bit-stringの両方を必要に応じ受ける。
・wxアプリのユーザには見えないが、基礎的な変更で、3.0の主要な動機だった。
New 2D Drawing Code
・2D描画API(wxDC, wxPen等)は常にwxの一部だったが、初期からほぼ変わらず、
単一のフロントエンドに対し多数のバックエンドが分岐して
バイナリ互換性を気にすることなく簡単にプラットフォームの差違を吸収してきた。
・古い描画APIは多くのタスクと1990年代の描画能力に対し十分であったが、
WindowsのGDI+やLinuxのCairo、OSXのCoreGraphics等、
透過やアンチエイリアス、マトリックス変換といった現代的2Dシステムの
先進的機能を使用できなかった。
・このため新描画API(wxGraphicsContextとか)が追加される。
ビットマップでのαチャネルのサポート
ビットマップのRAWデータへのアクセスをサポート
定数を変更、wxMODERN→wxFONTFAMILY_MODERN、wxSOLID→wxBRUSHSTYLE_SOLID等。
・参照カウントが合理化されプラットフォームで共通になる。
なんかバカバカしくなったのでここまでで終了。
しょせん気まぐれだ、許せ。
300:295
09/01/12 19:19:24
>>296-299
翻訳超乙。Unicode化の理由と、Graphicsの改善のあたりが良く分かった。
とりあえず、3.0は期待して損はなさそうだね。
301:デフォルトの名無しさん
09/01/12 21:10:20
一服して若干気を取り直したので続きを投下。
Changes to wxBase
（訳注：wxBase自体の紹介は省略）
・wxStringとコンテナクラスには多くの変更がある。
・wxBaseの一番大きな変更はwx3.0でイベントベースのプログラムを書くための
イベントループ、タイマー、ソケット等の追加。
・ソケットのコードは重複部分を削除、C/C++で分かれていたコードをドロップ。
302:デフォルトの名無しさん
09/01/12 21:10:54
New controls and other major GUI additions for all ports
全ての修正とマイナーチェンジを羅列できないので、GUIの変更の概要のみ。
・柔軟な表現が可能なwxDataViewCtrl/wxDataViewTreeCtrlを実装。wxListCtrl/wxTreeCtrlを一部代替。
・wxGridの表形式はwxHeaderCtrlに分離したネイティブなヘッダを実装。
・wxPropertyGridの追加。
名前-値のペアを表現する一般的クラス。
wxDataViewCtrlと同様、数値、テキスト、リスト、フォントなどの
組み込みのエディタ（in-place, ポップアップ、コンボボックス等）を提供する。
・wxHyperlinkCtrlをGTKでネイティブに、他では一般的方法で実装。
・ファイルダイアログのカスタマイズのためwxFileCtrlを実装。
・wxRichTextCtrlに親・子スクリプトのサポートを始め高速化など色々改良。
・wxTreeCtrlに状態アイコン表示機能追加。チェックボックス的にも使える。
・wxCalendarCtrlを刷新しMSWとGTK+でネイティブに。その他改良。
・wxTextCtrlとwxComboBoxでオートコンプリート機能を実装。
・wxAUIのクラス群にwxAUIToolBarを追加。より柔軟で自然に。
・wxBitmapComboBoxを再実装、MSWとGTKではネイティブに。
・wxBitmapToggleButtonを全プラットフォームに。
・wxStaticTextは全プラットフォームで省略表現をサポート、GTK+でマークアップ書式をサポート。
・全プラットフォームでwxListBoxの選択イベントの発起方法を書き直し精確にした。
・GTKとOSXでwxCollapsiblePaneをネイティブ実装。
・複数行に渡ってwrap可能な新しいsizer、wxWrapSizerを追加。
・OpenGlキャンバスにマルチサンプル、アンチエイリアスサポート追加。
wxGLCanvasとwxGLContext分離。
・wxTopLevelWindowをネイティブウィンドウハンドルから構築するため
MSWとGTK+にwxNativeContainerWindowを追加。
303:デフォルトの名無しさん
09/01/12 21:11:29
wxMac specific changes (now called wxOSX)
・wxMacという呼称は廃止、wxOSXと呼称、iPhoneとiPodを一部サポート。
・Carbon, Cocoa, CocoaTouchの3つの一般コードに整理。
・OSXのCoreFoundationへのラッパでったり一般的なクラスへのラッパだったり。
・CarbonがwxMacのコアで安定していたが、iPhone対応にCocoa(Touch)が必要で、
64bitのOSXでは非推奨となるため、現在はCarbonでも今後はCocoaにフォーカス。
・リストラクチャリングの一貫としてQuickDraw APIを使ったコードは削除。
今後はCoreGraphicsを使用する。
・同様にOSX10.4にないCarbonの関数を使用したコードは削除。
OSX10.4が最低動作環境になる。
・IconRefのサポート拡充。
・英語以外のロケールでのメニュー項目の重複を修正。
・ボタンにアクセラレータが使用可能に。
・CFLocaleを使用したwxLocal::GetInfo()の実装。
wxGTK specific changes
・GTK+のAPIが後方互換性がなくなって来たためGTK+2.4を最低環境とする。
・wxToolbarは新しいGTK+のツールバーAPIを使用。
・wxChoiceはGtkOptionMenuでなくGtkComboBoxを使用。
・wxComboBoxは非推奨のGtkCombでなく常にGtkComboBoxを使用。
・URLのドラッグはwxURLDataObjectで"text/x-moz-url"を使用。
・GtkPrintとCairoのダイアログを使用した新しいプリントバックエンド。
・アイドルイベントの生成コードを書き直し。
・タブの走査はGTK+でネイティブに。
・wxFrameのメニューバー、ツールバー、クライアントウィンドウとステータスバーは
GtkVBoxを使用したレイアウトに書き直し。
・ウィンドウマネージャに帰属するウィンドウの装飾に係わらず
トップレベルウィンドウSetSize()/GetSize()を正しく実装。
・wxYield()の呼び出しを避ける（リエントラント問題回避）ため
wxClipboardの非同期APIを追加。
・Nokiaのタブレットで使われるMaemoプラットフォームの
Hildonコントロールをいくつかサポート。
304:デフォルトの名無しさん
09/01/12 21:13:12
wxMSW specific changes
・後方互換性が確保されており、ユーザ数が多いため最も安定しており、
他のプラットフォームに比べ大きな変更はない。
・wxCheckListBoxがよりネイティブな感じに。
・長いツールチップが可能に。
・wxCheckBoxとwxToggleButtonで複数行ラベルをサポート。
・より正確なプリントプレビュー。
・サイズ変更可能なダイアログでリサイズグリップを表示。
以上、>>294曰く「御託だけで何もしない無職」の大雑把な訳でした。
305:300
09/01/12 23:38:51
>>301-304
引き続きサンクス。wxOSXが結構面白そうに思えたんで、Mac Miniの中古でも
買ってみようかな。
あと、御託云々はあんまし気にしなくても良いと思うよ。
それよか、スタティックリンクでソース公開しなくてもいいwxWidgetsを使って
金儲けできると良いんだけど、クロスプラットフォームでお金になりそうなアプリって
どんなのだろ？どうにもイメージが沸かない。
306:デフォルトの名無しさん
09/01/13 07:22:12
２ちゃんでちょっと煽られたくらいでむきになるようだと
実社会で辛くないか
307:デフォルトの名無しさん
09/01/13 07:46:14
翻訳しただけでムキになってるとか決めつけるようだと
実社会ですぐ口論にならないか
308:デフォルトの名無しさん
09/01/13 18:05:10
まぁ、どう見ても煽られたのが原動力にはなってるがな
309:デフォルトの名無しさん
09/01/13 18:18:57
翻訳人は無能ではないことを証明したし
英語読めない人は3.0の改善項目がわかったし
みんな幸せってことでいいんじゃなかろか
310:デフォルトの名無しさん
09/01/14 00:58:01
英語読めるようになりたいな
311:デフォルトの名無しさん
09/01/14 01:40:22
これからはアラビア語の時代だけれどもね。
312:デフォルトの名無しさん
09/01/14 13:11:27
つまらん、次
313:デフォルトの名無しさん
09/01/14 13:56:31
これからはアラビアゴムの時代だけれどもね。