08/06/28 21:49:20
クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)についてのスレ。
本家
URLﾘﾝｸ(www.wxwidgets.org)
wxWindows日本語プロジェクト
URLﾘﾝｸ(wxwindowsjp.sourceforge.jp)
Let's wxWidgets
URLﾘﾝｸ(dot-gray.s33.xrea.com)
wxWindowsで始めるC++ GUIプログラミング
URLﾘﾝｸ(www.h3.dion.ne.jp)
wxWidgets でクロスプラットフォーム GUIアプリを作ろう
URLﾘﾝｸ(0xcc.net)
2:デフォルトの名無しさん
08/06/28 21:51:28
wxWidgets 2.8.8 is out !!!
URLﾘﾝｸ(wxwidgets.info)
3:デフォルトの名無しさん
08/06/28 23:44:21
退かぬ！！ 媚びぬ 省みぬ！！
4:デフォルトの名無しさん
08/06/28 23:46:50
>3
省みるからバグフィクスが出るんじゃまいか
とマジレスしてみる
そして>1乙
5:デフォルトの名無しさん
08/06/29 09:11:25
昔、ソース覗いたけど、今ってどうなってんだ
6:デフォルトの名無しさん
08/06/29 15:45:28
今でも、ソース覗いたよ
7:デフォルトの名無しさん
08/06/29 19:48:18
wxMSW2.8.7 のwxTE_RICH を指定したwxTextCtrlのインターフェースで、
縦スクロールバーが出るぐらい文字を入力して、適当な位置にキャレットを動かしてEnterを押すと、改行される毎にキャレットがある行がインターフェースの先頭に行ってしまうというバグがあったんだけど、2.8.8でも直ってない・・・ですね。。
wxRichTextCtrlもなんか変なままだし・・泣
8:デフォルトの名無しさん
08/06/30 10:54:27
どんどんでかくなってくよぅ
もっと小さくして下さい
9:デフォルトの名無しさん
08/06/30 11:33:17
>>7
>>改行される毎にキャレットがある行がインターフェースの先頭に行ってしまうというバグ
sample の wxMSW widget を実行してみたけど、現象がよくわかりません。
普通に動いている気がするのですが…
10:デフォルトの名無しさん
08/06/30 23:31:47
>2.8.8でも直ってない
報告した？
11:7
08/07/01 22:07:46
>>9
>>10
すいません自分の勘違いかも？？
もうちょっと調べてみます。。
12:デフォルトの名無しさん
08/07/02 00:37:56
最近になって本格的にWxWidget触り始めたんだけど
サイザーって理解するのに時間かかるな。特にStaticBoxSizer
addで追加するオブジェクトを間違えると、即座にレイアウトが崩れて……
13:デフォルトの名無しさん
08/07/07 11:06:47
>>12
wxGlade あたりでレイアウトしてみて
確認してコーディングしてみるのも
いいかもしれませんよ。
14:7
08/07/07 12:40:49
>>7
なんか、EVT_TEXTイベントのタイミングでwxTextCtrl::SetDefaultStyle()を使うとキャレットの位置がおかしくなる、ということのようです。
また、別件になるのですが、EVT_TEXTのタイミングで入力されたマルチバイト文字列をwxTextCtrl::SetStyle()を使ってスタイル変更しようとすると、なぜかfalseが返ってきてしまうのです・・。(ASCII文字なら成功する)
仕方がないので、テキストコントロールの中の文字列が変更される時のイベントで、EVT_TEXTよりあとに発生するイベントのタイミングでSetStyle()を使いたいのですが・・EVT_TEXTより後に発生するイベントって何かあるでしょうか？？探しても見つかりませんでした。
Timer使うとまた色々不都合があるんですよね・・
15:7
08/07/07 12:47:02
>>キャレットの位置がおかしくなる、ということのようです。
おかしくなることがある、ですね。縦スクロールバーが出ている時に改行すると自分のところではおかしくなりました。
Windows XPです。
16:デフォルトの名無しさん
08/07/07 15:31:56
バグレポート
17:7
08/07/07 18:33:04
英語自信ないっす。。
18:デフォルトの名無しさん
08/07/07 21:56:39
>>14
使っているライブラリオプションは UNICODE でしょうか？
19:7
08/07/08 00:24:01
>>18
そうです！
20:18
08/07/08 13:23:29
>>19
調べてみるけど、ちと時間くださいな。
あと、そういう時は再現できる簡単なソースを書いておくと
調べる人が多いかもしれません。
21:18
08/07/09 15:51:13
>>19
調べてみました。
結論から言いますと Windows の問題で wxWidgets 側でなんとかできる
問題ではないですね。(同じようなコードを MFC で書いてもエラーになる)
Microsoft あたりに文句を言えば、いつかは直るかもしれません？
22:7
08/07/09 23:24:43
>>20 >>21
(多分前スレからお世話になりまくっていると思うのですが・・）本当に何度もご親切にありがとうございます。
もしかしてwxWidgetsの開発に関わっている方だったり・・？違うか。
Windows自体の問題とのことなのですが、すいません、>>14 では質問していることが2つあったのですが、どちらがWindows自体の問題だったのでしょうか？
23:7
08/07/09 23:45:39
あとすいません、また追加で質問で恐縮なのですが・・IMEの変換状態が変化したときにricheditが送出するEN_IMECHANGEというイベントマスクをwxWidgets側で捕まえたいのですが、
Win32APIが送るイベントマスクをwxWidgets側で拾いたい時はどうすればよいのでしょうか？？
IMEの変換状態が変化した時のイベントのようなものは既存のwxWidgetsにはなさそうなので、自分で書き足さなければいけないと思うのですが・・。
24:18
08/07/10 10:49:04
>>22
残念ながら違います。
こういったライブラリで遊ぶのが好きなだけです:-)
で、>>14 の質問の
>また、別件になるのですが、EVT_TEXTのタイミングで入力された
>マルチバイト文字列をwxTextCtrl::SetStyle()を使ってスタイル変更
>しようとすると、なぜかfalseが返ってきてしまうのです
この件は Windows の仕様のようです。(MFC でも同じことが起きます)
EVT_TEXT(Windows の EN_CHANGE)で、SetStyle(MFC の
CRichEditCtrl::SetSelectionCharFormat 等)でも同じエラーになります。
ですので、現状では Windows の仕様なのでいかんともしがたいかと。
EVT_TEXT(EN_CHANGE)の後に飛んでくるメッセージは特にないようです。
25:18
08/07/10 11:53:44
>>23
独自のメッセージを持ってくる方法があった気がしたけど
きれいさっぱり忘れましたorz
一番手っ取り早い方法は wxTextCtrl::MSWCommand の
継承メンバを作っちゃう方法かな？
26:デフォルトの名無しさん
08/07/10 12:18:56
ていうか 7 さんはそこまで Windows べったりのことをするのなら wxWidgets である必要がない気が...
27:デフォルトの名無しさん
08/07/11 01:45:57
>>24 >>25
毎回ありがとうございます。
URLﾘﾝｸ(docs.wxwidgets.org)
この辺りよんでるんですが・・なかなか書いてあることが理解できません。難しいですね・・
>>26
最近ようやくそう思い始めました汗 しかし、一回手を出してしまった以上他のに乗り換えるのはいやだなと・・
また不具合の話になるんですが、どうも wxTextCtrl::SetStyle() とか GetStyle() を使うと、該当箇所の文字列が一瞬青く反転してしまうようです・・(一瞬選択状態になっている？)
これもけっこう痛いです・・
28:デフォルトの名無しさん
08/07/11 07:16:25
>>27
>しかし、一回手を出してしまった以上他のに乗り換えるのはいやだなと・・
世の中見切りの付け所ですよ。
29:デフォルトの名無しさん
08/07/11 08:56:57
今の時代の見切りは、Winﾓﾝﾘｰ開発を見切るんであって、
クロスのWxWidgetsに手を出すのは正しい。
他に乗り換える場合でもクロスGUI。
30:18
08/07/11 10:53:29
>>27
何か理由(納期とか…)が無い限り、楽しみながらやるのがいいかと。
>どうも wxTextCtrl::SetStyle() とか GetStyle() を使うと、
>該当箇所の文字列が一瞬青く反転してしまうようです・・
>(一瞬選択状態になっている？)
wxTextCtrl::SetStyle() 内部では、
1 指定範囲を選択
2 EM_SETCHARFORMAT を SCF_SELECTION で SendMessage
3 指定範囲を戻す
という動作をしているからです。
EM_HIDESELECTION を SendMessage してやればいいだけなので
がんばって本家にレポートしてみるとか。
31:18
08/07/11 10:59:25
>>27
順番が逆になってしまった。
>URLﾘﾝｸ(docs.wxwidgets.org)
>この辺りよんでるんですが・・なかなか書いてあることが理解できません。難しいですね・・
wxEvent 関連を使った方法は私もよくわかりません:-p
そっちではなくて、wxTextCtrl を継承したクラスを作って、MSWCommand を
継承しちゃえばいいかな？ってことです。
class myTextCtrl : public wxTextCtrl
{
public:
virtual bool MSWCommand(WXUINT param, WXWORD id) {
if ( !wxTextCtrl::MSWCommand( param, id ) ) {
switch (param) {
case EN_IMECHANGE:
～
break;
default:
return false;
}
}
return true;
}
こんな感じ？
やってみたことないからあっているかどうかの自信はないけど。
32:デフォルトの名無しさん
08/07/11 20:02:36
wxMSW以外でもコンパイル通るのかそれ?
33:デフォルトの名無しさん
08/07/11 23:12:43
>>32
そりゃ当然 #ifdef とかで囲むんだろう
34:18
08/07/12 18:50:28
>>32
EN_IMECHANGE をキャッチしたいとのことだったので
Windows 専用で大丈夫かと思いました。
X や MacOS だと IME 系の処理ってどうやるんでしょうね。
35:27
08/07/14 02:20:06
毎度ありがとうございます。。。
>>何か理由(納期とか…)が無い限り、楽しみながらやるのがいいかと
特に納期などはないんですが、なんとしても作りたいものがあってやってるんですがはかどらなくて悶絶してます泣
IMEに入力された文字列のフォントを毎回設定するために渋々win32apiをいじっているのですが、ウィンドウのハンドルを取得するFindWindowW()関数でウィンドウのハンドルがうまく取得できたなくてはまっています。。
(このハンドルがないとIMEにアクセスできないようなのです。)
FindWindowW()の第一引数に該当ウィンドウを生成する時に使っているクラスを指定しなければいけないみたいなんですが、
wxTextCtrlとかではだめで、もっと深い階層にあるwin32apiウィンドウ生成クラス？を指定しなければいけないみたいなんですが、それが何なのか分からなくて止まってます。。
>> 2 EM_SETCHARFORMAT を SCF_SELECTION で SendMessage
>> がんばって本家にレポートしてみるとか。
これはライブラリがそういう仕様になっているということなんですよね。
これを直すのもまた大変そうですし、直してもちゃんと本家でパッチあててもらって公開してもらわないと使えないんですよね。。
なんかもう作りたいプログラムの完成が果てしなく遠いような気がしてきました。
そもそも楽するためにwxWidgetsっていうフレームワークを使っているのにいつのまにかwin32apiをいじる羽目になっているし・・
なんのためにラッパーを使っているのか分からなくなってきました。
悲鳴に近い書き込みすいません。
Visual C++ に呼ばれている気がします。。。
36:デフォルトの名無しさん
08/07/14 07:45:51
> なんのためにラッパーを使っているのか分からなくなってきました。
そりゃ根本的に使うものが間違ってるからだろ。
WindowsべったりでWindowsでできることは全部できなきゃダメとか思いながら使
うもんじゃねーよ。
37:デフォルトの名無しさん
08/07/14 08:37:19
こういうクロスプラットホームので日本語入力周りが細かく操作出来ると思うのが甘いんじゃないかと思います ... 開発者の大多数が英語環境なわけでね。
とにかくあなたのやりたい用途には日本語周りのサポートの厚いフレームワークをつかわないとだめそう。べつに急に Win 32 API までおりる必要はないわけで。
Windows なら .Net とかつかったほうがいいんじゃない？
Delphi とかも昔はよかったのかも。
38:デフォルトの名無しさん
08/07/14 10:26:13
Lazarusもなんか微妙なんだよねぇ。
BorlandがKylixを見捨ててなければ、クロスプラットフォームアプリの
大本命になれたかもしれないのに。
39:デフォルトの名無しさん
08/07/14 10:37:25
＞Windows なら .Net
そ・れ・は・ない
40:18
08/07/14 10:56:40
>>35
wxWidgets の話題から外れるので、軽くだけ。
何をやりたいかよくわからなくて想像だけど、
そういうことをやりたいときは WM_IME_COMPOSITION をとらえて
ImmGetContext から HIMC を取得し、Imm* 系の API を使うんじゃ
ないかな？
wxTextCtrl のようなコントロールを駆使してやるのは難しいと思いますよ。
41:デフォルトの名無しさん
08/07/14 12:18:53
>>39
37 ですが、見当外れだったらすいません、日曜 Cocoa 屋さんなもので ...
42:35
08/07/14 13:16:44
レスありがとうございます。
>wxWidgets の話題から外れるので、軽くだけ。
すいません、そうですよね。。ありがとうございます。
>wxTextCtrl のようなコントロールを駆使してやるのは難しいと思いますよ。
やはり・・
>> Windows なら .Net
> そ・れ・は・ない
いまさらVisual C++ とかはあんま賢くない選択肢なんでしょうか。
> こういうクロスプラットホームので日本語入力周りが細かく操作出来ると思うのが甘いんじゃないかと思います ... 開発者の大多数が英語環境なわけでね。
それに気づくのが遅すぎました泣
QTなんかはどうなんですかね・・日本での実績もあるのでwxWidgetsよりはマルチバイト文字周りも大丈夫そうですが。
結局開発環境で何を採用すればいいのかという導入部での問題にまたぶつかってしまいました。
最初は、これからはマルチプラットフォーム対応じゃないとと思ってwxWidgetsを選んでみたんですが、結局まだほとんどの日本人はWindowsを使っているわけで、まだしばらくはWindowsをほとんどの人が使っていくんじゃないかとも最近思うので、
素直にVisual C++ から入ればよかったのかなとか思い始めてるんですが・・
こういう話題NGだったらスルーしてくださひ。
43:デフォルトの名無しさん
08/07/14 13:19:24
>素直にVisual C++ から入ればよかったのかなとか思い始めてるんですが・・
Windowsソフトを作るにしてもVC++はやめといた方が良い。
M$社内でも使われなかった該吉設計MFCを使うか、
ドトネトとC++を混ぜるというそれだけでウンザリ、
といった環境しかない。
44:デフォルトの名無しさん
08/07/14 13:55:31
>>42
>最初は、これからはマルチプラットフォーム対応じゃないとと思ってwxWidgetsを選んでみたんですが、結局まだほとんどの日本人はWindowsを使っているわけで、まだしばらくはWindowsをほとんどの人が使っていくんじゃないかとも最近思うので、
会社の仕事でソフトを書いてるなら他の人が何を使ってるかは重要だけど、
自分ひとりで使うなら何で組んだって勝手だよね。
wxWidgets がすきならそれをつかえばいいし、プラットフォームべったりでも好きなフレームワークがあればそれを使えばいいんだと思うけども、
どうも 35 さんは日本語入力周りをいじりたいというクロスプラットホームには不向きな題材をやりたいようだから...
やっぱやりたいことに即した言語/フレームワークを使うべきだとおもいます。
でもVisual C++ はよくないと思います。C++/CLI は変態で面白い言語だとは思うけど。
45:デフォルトの名無しさん
08/07/14 14:07:06
＞思ってwxWidgetsを選んでみたんですが
この苦難を乗り越えてこそ、
アプリとかのすぐれたデザインパターンを発見できるだろうし、
ソフトウェア資産になると思うんだが。
それが”WxWidgetsを組み込んだ場合の優良なデザインパターン”となるか、
”質問者の作成するはソフトウェアの要素からWxWidgetsが外される”ことと落ち着くか、
それは自分で決めることだけど。前者も無理じゃないと思うぞ。
46:35
08/07/14 14:24:32
どもです。
Visual C++ 人気ないですね。。MFCとか.NETが人気ないってことなんでしょうか。
ATL/WTL ってのがVisual C++ で使えるみたいなんですがこれはけっこう評価が良いような？？
あとはVisual C# とかですかね。。
>>45
まだ自分はデザインパターンとか見つけられるレベルではない気がします。。
47:デフォルトの名無しさん
08/07/14 14:35:41
別にVC++で問題ないよ。SDKでガシガシ書け。
どうせどんなGUIライブラリ使っても、細かいところはAPI直に触らなきゃならないんだから。
48:デフォルトの名無しさん
08/07/14 14:49:18
VC++/SDKなら問題無いかも。
それならその中にWxWidgets使っても無問題。
MFCはやめとけ。
１回生成されたダイアログを使ったソースを見てみれば、
”これ何語？”って感じであきらめることになるだろう。
ドトネトもやめとけ。作るものに限界があるし、そうだと、作っててつまんない。
49:デフォルトの名無しさん
08/07/14 15:04:36
＞まだ自分はデザインパターンとか見つけられるレベルではない
どっちにせよ、アプリの構造はつねに意識してないとね。
どういう構造が良いのかわかってないと、プログラム修正して良くなったのか悪くなったのかわからんだろ。
50:デフォルトの名無しさん
08/07/15 02:39:38
自分か身内だけで使うようなちょっとしたものだと、
C#に.NET3.0↑で書くのが楽すぎる
Windows専用になっちゃうんだけどさ
ってｽﾚ違いだな
51:デフォルトの名無しさん
08/07/15 04:26:43
>>46,35
以前に少し使った程度だけど、WTLは結構いい感じだったよ。あとwindowsで
コード組むなら、やっぱりVC++がいいと思う。単純にwindowsとの相性がいいのと
windowsで実行する場合、実行速度が速い。（独特な部分もあるので、注意が必要だけど）
将来移植するかもしれないけど、当分windowsメインなら自分でラッパークラスを作って
移植の時楽になるようにしておくのがいいんじゃないかな。
MFCはやっつけで作るには楽だけど、腰を据えて作る場合はなんか
いらいらすることが多くて、自分はあんまり使いやすく感じなかった。
構造覚えるのも労力かかるし、わざわざ使うことないんじゃないかな。
C#（というか.NET）は、細かいところにこだわりを持つ性分なら薦めない。
使いやすいけど、細かいことにこだわると、結局API叩くことになるから。
あとやっぱり、もっさりした感じになりやすいね。
ついでに書くと、Qtはフリー版で作ったものは、ライセンスがGPLになるのと
バージョンがあがった時に互換性がなくなった、変なプリプロセッサを通して
コンパイルするなどが嫌で、使うのやめたことがある。作り易そうではあるんだけどね。
52:デフォルトの名無しさん
08/07/15 08:05:00
>>51
で、wxWidgetsはどうなんだ？
53:デフォルトの名無しさん
08/07/15 20:30:58
そういえば、ここはwxのスレだった。
wxは以前に調べた限り、C++でクロスプラットフォームの開発をする場合は
一番妥当なライブラリだと思うよ。
日本語の入力が使えて、継続的に開発されていて、GUIの見た目がOSと
同じようになる。ある程度の実績があり、ライセンス的にもあまり
縛りが強くないってなると、wxしかなかった。
IME周りや日本語フォントなど細かいことをやるには問題があるかもしれないけど。
自分はクロス開発する必要があるものはwxを使って、api叩く必要がある場合は
ラッパークラスを作るようにしている。
あと日本語周りを細かく操作したいなら、どうせAPIを使うことになるから、
それが楽になるライブラリを探すよりは、そのあたりのAPIの使い方を
調べたほうが近道だし、応用が利くと思うよ。
54:デフォルトの名無しさん
08/07/19 05:41:43
そうだね
55:デフォルトの名無しさん
08/07/19 21:07:43
ところで、暇つぶしに、wx使ってどこまでできるの挑戦で、こんなのつくってみたんだ。
URLﾘﾝｸ(cvs.sourceforge.jp)
56:デフォルトの名無しさん
08/07/20 04:59:33
URLﾘﾝｸ(ugmail.sourceforge.jp)
57:デフォルトの名無しさん
08/07/25 16:02:55
ほしゅ
58:35
08/08/01 15:58:28
ご無沙汰です。挫折してしばらく何もしていなかったのですがまた最近やり始めています・・。
結局VC++はIDEの使い方を覚えるのが面倒で、またwxWidgetsに戻ってきてしまいました。
>どうも wxTextCtrl::SetStyle() とか GetStyle() を使うと、
>該当箇所の文字列が一瞬青く反転してしまうようです・・
この問題は、
(void) ::SendMessage(GetHwnd(), EM_HIDESELECTION, 1, 0) ;
wxTextCtrl::GetStyle(position, style);
(void) ::SendMessage(GetHwnd(), EM_HIDESELECTION, 0, 0) ;
こんな感じでGetStyle()をオーバーライドしたら解決しました。win32APIを直書きすればこれぐらいの問題ならば解決できたようです。
今まだ悩んでいるのがEN_IMECHANGEやWM_IME_COMPOSITION を捕捉するところです。
>>31さんに提示して頂いたように
class myTextCtrl : public wxTextCtrl
{
public:
virtual bool MSWCommand(WXUINT param, WXWORD id) {
if ( !wxTextCtrl::MSWCommand( param, id ) ) {
switch (param) {
case EN_IMECHANGE:
～
break;
default:
return false;
}
}
return true;
}
みたいな感じで色々試してみているのですが、このやり方だとどうもうまく捕捉できません。 これらのイベントの捕捉のしかたが分かるかたいらっしゃいましたらご教授頂けると幸いです・・ｍ(_ _)ｍ
59:35
08/08/01 16:00:52
>>47 >>48 >> 49 >> 50 >> 51
ありがとうございますｍ(_ _)ｍ お礼がめちゃくちゃ遅くなってすいません。
結局VC++とかWTLじゃなくてwxWidgetsをまだ使ってます。。
60:18
08/08/02 16:36:53
>>58
あれ？駄目なのかな。
ちとしばらく忙しくなるので、気長に待ってみて…
61:デフォルトの名無しさん
08/08/02 21:37:47
>>58
MSWCommand の先頭で、処理してもだめなのか？
wxStyledTextCtrlの場合でやったときは、
WXLRESULT wxStyledTextCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
WXLRESULT ret;
switch(nMsg)
{
case WM_IME_・・・・
//じぶんでつくった処理
break;
default:
ret = wxControl::MSWWindowProc(nMsg,wParam,lParam);
break;
}
return(ret);
}
なかんじでできたよ
62:35
08/08/04 13:01:51
レスありがとうございます。
MSWWindowProc()の方を試してみたら、VM_IME_COMPOSITIONを捕捉することが出来ました！ありがとうございましたｍ(_ _)ｍ
EN_IMECHANGE、VM_IME_CHAR、VM_CHAR はなぜか捕捉出来ず。
いまやりたいことが、「VM_IME_COMPOSITIONのタイミングで、IMEで編集中の文字列のフォントを変更する」ということなのですが、
VM_IME_COMPOSITIONを捕捉できてなんとかなったと思ったのですが、VM_IME_COMPOSITIONのタイミングでwin32APIの ImmSetCompositionFont(hIMC, lf) を使っても、フォントが変更されませんでした・・。
1が返ってきているので関数自体は成功していると思うのですが・・。
例えば、テキストインターフェース上で、太文字で強調表示させた文字列の直後にキャレットを置き、そこでIMEをONにし、キーストロークによって文字を打ち込むと、
直前の強調表示された文字列のフォント(太文字)がIMEのフォントにも継承されてしまうようで、
それをどうにかしたくてVM_IME_COMPOSITIONのタイミングでIMEの編集中の文字列のフォントを強制的にデフォルトのものに変えてしまおうという考えだったのですが・・
アドバイス頂けると幸いです。
63:35
08/08/04 13:56:38
> wxStyledTextCtrlの場合でやったときは、
wxStyledTextCtrlって、IMEをONにしたときの入力が正常に動かなくなかったですか？
自分の環境では変換待ちの文字列が常に一番上の行に出てしまって、それが嫌でwxStyledTextCtrlを使うのはやめたという経緯がありました。
64:デフォルトの名無しさん
08/08/04 20:01:03
「自分の環境」とは？
65:デフォルトの名無しさん
08/08/05 00:14:39
>>63
ああ、IMEの処理は実装されていないから、そうなる。
そもそも、IME関係はOS依存？FEP依存？のようで、wxWidgets に対応するものはない。
Scintilla の場合は、Plat？？.cpp でマルチプラットフォームを実現してるのだが、
（wxStyledTextCtrlでは、PlatWX.cpp がそれに該当する）
マルチプラットフォーム化する必要のために、IMEの処理を移植できなかったのかと思う。
66:65
08/08/05 00:19:11
あと、EN_IMECHANGE、VM_IME_CHAR、VM_CHAR の処理はwxWidgets のソースを見たほうがはやいな。
wxWidgets のソースは簡単だから、そっちをあたることをお勧めする。
67:デフォルトの名無しさん
08/08/12 13:24:03
wxJoystickを使うと、レジストリのHKLM\SYSTEM\.. というのを読みに行って失敗する・・・。
HKLM\ってうちのマシンには見当たらない。またwxJoystickEventがEVT_JOYSTICK_EVENTSで拾えない。
GetNumberJoysticksはなんか値が返ってきているから何かしらJoystickは見えているはずなんだけど。
コンパネのゲームコントローラはちゃんと認識しているのでHWの故障でもない。
さぁどうしよう。
飛ばしてwxMediaで遊ぶか。
68:デフォルトの名無しさん
08/08/12 20:12:17
HKLMってHKEY_LOCAL_MACHINEのことだけど
69:デフォルトの名無しさん
08/08/20 19:47:49
何でだろう、EVT_PAINTを登録するとCPUがブン回る・・・
samplesのプログラムはそうならないけど、何が違うのか分からない。
頭悪いな俺。
70:デフォルトの名無しさん
08/08/21 06:59:56
wxPaintDC使ってないだろ
71:69
08/08/21 10:01:31
wxPaintDC dc( this );
とするべきなところを
wxPaintDC dc;
と書いていました・・・。
直したら、ちゃんと動きました。
スレ汚ししてすみませんでした。
72:デフォルトの名無しさん
08/08/23 16:37:06
質問です
wxGridはデフォだとマルチセレクト且つダブクリで編集モードになりますが、
シングルセレクトにしてワンクリで編集モードに移行するようにできますか？
IDEとかRADのプロパティ表示みたいなことをやりたいんです。
DialogBlocksが多分wxWidgetsで組まれてると思うのであれがそのまま使えればいいんですけど
そのまんまのクラスって無いですよね？
73:72
08/08/25 22:14:35
探してみたらwxPropertyGridっていうまんまのコンポーネントが見つかりました。
wxCodeに載ってなくても探せば使えるコンポーネントって結構ありますね
74:デフォルトの名無しさん
08/08/28 17:27:01
で、クロス開発する場合、ＩＤＥはどれが一番良いの？
wxDev-C++を使ってるけどバージョンうｐされないorz
75:デフォルトの名無しさん
08/08/28 17:36:46
とりあえず、wx-Dev C++ と Code::Blocks は、どちらが良い？
76:デフォルトの名無しさん
08/08/28 18:46:17
GUI作成できるのは、
・wx-Dev C++
・Code::Blocks
・wxGlade
だけでつか？
77:デフォルトの名無しさん
08/08/28 22:40:12
>>74
wxDev-C++はHPで近いうちに更新するっていってたよ
>>76
そんなあなたに、このページを送ろう
URLﾘﾝｸ(wiki.codeblocks.org)
78:74
08/08/29 10:07:05
>>77
え”、更新ですか！wx-Devは大好きなので嬉しい。
そのページ凄すぎ。
結構１年近くググルでwx系を検索してたんですが３つ４つしか把握できなかったのに、
そのページで全部そろうじゃん。
こんなにいっぱいあるとは。。。
商用のは一旦除いて（商用でもC++ Builder並に良いものなら買うけど、決定打が無さそうなふいんき）、
使ってないやつで良いのがあるかもしれないのでまた調査。
79:61
08/08/29 21:03:27
>>76
私的には
Visualwx
URLﾘﾝｸ(visualwx.altervista.org)
あとは、wxStudioとか
URLﾘﾝｸ(wxstudio.sourceforge.net)
80:デフォルトの名無しさん
08/08/30 13:22:02
dialogblocksが挙がってないのは有料だから？
81:デフォルトの名無しさん
08/08/30 13:25:58
すでに72で挙がってるからですな・・・ｽﾏｿ。
82:76
08/09/01 09:19:29
>>79
VisualWxってえらい変わりましたね。
以前はコンパイラ起動できなかったような。
83:デフォルトの名無しさん
08/09/01 13:19:08
どれが良いか投票とか、
使える・使えないレビュー、
きぼんにゅ。
84:デフォルトの名無しさん
08/09/02 17:15:22
どのＩＤＥが好き？
85:デフォルトの名無しさん
08/09/03 00:19:27
まだ、これってIDEやRADがないんだよねー。残念ながら。
俺は今、MinGWのCodeBlocksを入れようと思ってんだけど、
wxmsw28??_core.lib（libwxmsw28??_core.a）や、
wxbase28??.lib（libwxbase28??.a）がないって怒られる
んだけど、下のサイトのようにwxWidgetsをビルドしても
ライブラリが生成されないんだけど。なんで？
URLﾘﾝｸ(python.matrix.jp)
もっと簡単なクロスなIDEはないもんかね？
86:デフォルトの名無しさん
08/09/03 01:18:15
趣味プログラミングでしかないけれど、wxFormBuilder 3はフォームデザインのみとはいえ使い勝手いいよ。
自分で書くコードと、wxFormBuilderが生成するコードが、完全に分離されるところが好き。
Makefileは手書き、ソースコードエディタはVim。開発は主にLeopardで行い、一回のmakeでWin/Mac用バイナリを生成……という感じ。
IDEって、突然バージョンアップが止まったり、なんだか変なものを導入したのか
不安定＆低速になったりとあんまり信用できない感じ。なんていうか、Delphiで懲りた。
87:デフォルトの名無しさん
08/09/07 00:17:44
>>85
そでだけだとよくわからんけど、
debugのバイナリ作ってないのに
デバッグビルドしようとして同じようなことになったことはあるな
Code::Blocksよりdialogblocksのほうが使い易いと思う
タダ版だとカスタムクラスが1つしか登録できないとか
RADツールで使えないクラスがあったりするけど
その辺は勉強もかねてエディタで乗り越えようとすれば問題なし
88:デフォルトの名無しさん
08/09/11 18:17:31
wxWidgetsで非矩形ウィンドウや半透明ウィンドウは扱えるのでしょうか。
また扱える場合は関連するメソッドを教えていただけると有り難いです。
89:デフォルトの名無しさん
08/09/11 22:13:46
>>88
リージョンは使えるよ。
半透明ウィンドウは、以前そんな話があったみたいだけど、
Windows以外のプラットフォームで出来ないのもあるみたい
なので、実装されなかったみたい。
90:88
08/09/11 22:38:14
>>89
なるほど。どうもありがとうございます。
対応プラットフォームが多いと実装もやっぱり大変なのでしょうねぇ。
91:デフォルトの名無しさん
08/09/12 11:35:27
ＩＤＥランキング調査スタート！
92:デフォルトの名無しさん
08/09/12 12:45:41
,. -‐ ' ´ ￣ ｀` ' ‐- ､
,. -─ ‐- ､ ／ ｀`' ､
∠-‐' "´ ￣ ｀ `'‐- ､ `'‐､
／´ ヽ､ `'‐ ､__
, ‐' (⌒'‐- ､ ＼
-='´ ='イ ヽ. ヽ
/ ヽ､=_,‐''´ ､_,ﾉ ヽ
. i ､ ヽ､＿, ／,. _-,=‐､ゝ' ',
.｛ ゞ_=､＜. ヽ-' ,､r‐;､彡‐＝=/ﾆ.ヽ ｝-‐- ､ /
＼ ', ､ｙ＝;'､ ´ゞ=''_,.´ / F､ヽ ', ./ ＼ /
＼ヽ`ゞッ / ￣ { |´ノ / ∠ ＼ ,/
`} ￣〈,. -‐､ ! ヽ／ ／ `､ `'‐-､ﾆ､_,.／
! ` '､ ヽ. ／ `'‐- ..,,j-‐'"´
ヽ. ' ´￣｀ ヽ ∨
. ＼ '" ,. } ∧
ヽ. ＿___, ,-‐'" ／ ,./ ‐ﾍ
）_,,.ハ ＜_,. -' ＼＿＿＿,,,.. ..,,
´ ト､ | | ／´ ｀`ヽ.
＿,. -‐'´j ヽ! ｨ /´ ﾄ､
／´| i. ヽ! ／// _,,,.. ....., ､ |i
| | |＼ __ .／ / {,. -‐´ ＿_ ` !.}
,-ソ ! ! / Y´ /くﾝ-─／´ _,,.. - / |
,. へ'´ ､ ﾘ ! ／>-<ヽ. ∠ノ ￣｀`'´ / i
‐ ､_ ､_ ヾ ﾉ !' ´ `／ / !
93:デフォルトの名無しさん
08/09/12 15:26:54
＿
_, - ' ´￣￣ ￣ ヽｰ -､_
／ ｀ｰ ､_
／ ＿ ｀ヽ
/ /´ ｀ヽ, ｀i
/ l i ヽ
i ヽ､ (_).ノ ヽ
| l l | /l /l | ﾊ /l ￣ ヽ
', l ヽ. ﾊ |ヽ| ヽ ､ l ヽ､ l ヽ ',
ヽヽ､ _-ヽヽヽヽ､ >_ﾆ=＝｀ｰ-､j i
冫､ _v ｰﾃ､ - 'ﾃtｧ- ', |
/ ヽ .,ヽﾟﾉ ヽヽ=ﾟ'´ ヽ !
i ! / ／￣ i
/ ', ｰ / l
! ヽ ｰ - - ! /
＼ ＼ _ ヽ _ ／
｀ー --'-'- ｀ー -‐ i ´ ｀ｰ'- -'-'-'-'‐'´
| |
| ヽ､
＿＿＿＿_ﾉ ｀ｰ - -､_
ヘ _, - ' ｀ｰ､
/ ＼ , - ‐ ' ´ ／ ￣￣ ヽ
l ヽ ､ _ , - ‐ ' ´ ／ i
y ／ |
／ ／ l
／ ／ ／ /
（ ｀ y ´ ／ ／ /
94:デフォルトの名無しさん
08/09/12 16:09:32
Libファイルを作成後に
sampleをコンパイルしてみようと思ったんですが
未解決の外部シンボル
だらけになってしまいます。
どうもまったくlibファイルを認識していないのか何なのか。
sampleはそのままの状態でコンパイルしてはいけないんでしょうか？
95:デフォルトの名無しさん
08/09/13 08:52:45
あのさ、こっちだってエスパーじゃないんだから、
自分がどういう環境で何をやってるか相手に判ってもらおうっていう気はないわけ？
96:デフォルトの名無しさん
08/09/13 09:46:27
原因を追求する気があるならあんな書き込みはしないだろ。
97:デフォルトの名無しさん
08/09/13 23:03:26
wxwidgetsのストリング関係のクラスは
日本語使える（漢字）？
98:デフォルトの名無しさん
08/09/14 00:07:06
>>97
使える。Unicode モードと、環境依存エンコーディング決めうちモード(なぜかANSIモードとよばれる)があるよ。
99:デフォルトの名無しさん
08/09/14 05:53:11
後者は基本的にユニバイト環境しか考えていない。
たとえばファイルのパス操作など、セパレータが \ かつ文字コードがCP932な
変態環境では問題が生じうる。
100:デフォルトの名無しさん
08/09/14 12:21:10
94です
すいません。８時間ぶっ通しで１つの進展も無く悩みすぎて色々おかしくなってました。
２日寝てようやく冷静になりました。
wxMSWのセットアップを使用して、WindowsXpにxwWidgetsをインストール後
VisualC++2005Expressに、\build\msw\ws.dswを読み込ませ各種libファイルをビルドしました。
この時点でエラーはありません。
その後、サンプルをビルドしてみようと
\samplesフォルダにある、samples.dswを読みこんでそのままビルドしてみましたが、
すべてのlib内の関数が「未解決の外部シンボル」と出て認識してもらえませんでした。
試しに、他の\samplesフォルダ内の
各サンプルの.dspファイルを直にVC++2005Expressに読み込んで、同じ様にビルドしてみましたが
すべて同じ症状でした。
生成したlibファイルの存在する\lib\vc_libにはリンク設定はしてるようですし、
インクルードディレクトリの設定にも問題があるようには思えませんでした。
sample内の.dspファイルはそのままの状態でコンパイルしてはいけないんでしょうか？
101:デフォルトの名無しさん
08/09/15 23:45:58
Libのモード（リリースビルド、デバッグビルドとか）が、
sample のがあってます？
それと、wxwidgetsのversionは、2.8.8だよね？
とりあえず、VC2003とVC2008の場合は、動作しますよ
102:デフォルトの名無しさん
08/09/16 22:11:41
94です。
助けありがとうございます。
wxwidgetsのversionは、2.8.8です。
Libのモード（リリースビルド、デバッグビルドとか）
のパスや名称は合っているようです。
URLﾘﾝｸ(forums.codeblocks.org)
にあった事例のようです。
I now compiled wxwidgets with VS2005 and
I am now able to build the samples,
but with new projects I still have problems.
It seems that the wizard does something wrong
- the linker wants to have wxmsw28d.lib
but I cannot find it on my system.
I have a lot of wxmsw28d_xxxxx libs...
という話しで
解決方法は
wxmsw28d.lib is for Monolithic debug builds;
you seem to have a Multilib build.
MultiLib is the opposite of Monolithic.
In the wizard un-check Monolithic or you need to build wxWidgets
as a Monolithic build.
とのことです。
つまり、wxmsw28d.libが生成されなければならないのに、
複数に分かれたwxmsw28d_xxx.libが生成されてしまうという問題です。
１つのwxmsw28d.libにまとめられれば、この問題は解決しますが
話が理解できません。
チェックを外すべきMonolithicとは何なのでしょうか？
どうすれば１つにまとまるんでしょうか？
103:デフォルトの名無しさん
08/09/16 23:22:59
94 氏とは別件だけど、2.8.8をMinGWでコンパイルで、ライブラリ(～.a)を
作成したまでは良いんだけど、リンクエラーが出ます。
ヘッダが無いとかが、原因ですかね？
～\wxWidgets\lib\libwxmsw28d_core.a(corelib_imagjpeg.o):..\src\common\imagjpeg.cpp|238|undefined reference to `jpeg_std_error'
104:デフォルトの名無しさん
08/09/17 00:36:56
>>102
ビルドが出来るってことは、WindowsSDKは大丈夫なんだね。
スタートメニューから、Visual Studio Tools でコマンドプロンプトを開ける？
開いたら、cd wxWidgetsのディレクトリ\build\msw して、
nmake /E MONOLITHIC=1 makefile.vc
してみて。
105:デフォルトの名無しさん
08/09/17 00:39:20
>>103
undefined referenceが出る場合は、そのシンボルの実態が無いって事だから、とりあえずリンクするライブラリ不足を疑うと良いよ。
jpeg_std_errorでググると、libjpegの中の関数だってわかるから、g++のコンパイルオプション（というかリンクオプション）に -ljpeg を
付けて再チャレンジして見て。
106:デフォルトの名無しさん
08/09/17 09:11:10
>>103があと数回は同じ質問を繰り返す様が見て取れるようだ。
107:デフォルトの名無しさん
08/09/17 23:25:19
>>104
94です。
たびたび助かります。
104を試したところ
しばらくコンパイルが通った後、
..\..\src\msw\utils.cpp(173) : error C2143: 構文エラー : ')' が '__stdcall' の前
にありません。
..\..\src\msw\utils.cpp(173) : error C2059: 構文エラー : ')'
..\..\src\msw\utils.cpp(175) : error C2143: 構文エラー : ';' が '*' の前にありま
せん。
以下エラー略～～な状況です。
この173行目は
typedef int (PASCAL *WSAStartup_t)(WORD, WSADATA *);
こんな内容です。PASCALかWORDかWSADATAのどれかが、定義されていないと思われるんですが、
VCのオプションでも、SDkへのパスは設定してありますし、
Microsoft Platform SDK\SetEnv.Cmdは実行済みなので(試しに直前にもやってみたけど結果は同じ)、
SDKのパスが通っていないとは思えないです。
おそらく、これが最後の関門だと思います。
どうかもう一度よろしくお願いします。
108:デフォルトの名無しさん
08/09/18 00:09:03
>>107
__stdcallは、PASCALというマクロが展開された結果。
その前に ')' が必要といわれてるんだから、問題になってるのはそこより手前
本当にそのコンパイルエラーの手前にWarningかエラーない？
109:デフォルトの名無しさん
08/09/18 00:33:20
>>107
というか、MONOLITHIC=0がデフォルトなんだから、MONOLITHICじゃないライブラリ使えば良いじゃない。
1. wx_dll.dswを開いて、構成をDLL Unicode Releaseを選択してソリューションをビルド
2. samples.dswを開いて、構成をDLL Unicode Releaseにしてソリューションビルド
で、普通にいけるぞ？
110:デフォルトの名無しさん
08/09/18 01:05:55
94です。
>>108
warning C4068: 不明なプラグマがありました。
というwarningが大量にありました。
>>109
>1. wx_dll.dswを開いて、構成をDLL Unicode Releaseを選択してソリューションをビルド
この時点で未解決の外部シンボルの嵐で全然ダメです。
wx_dllは他の構成でも全然ダメでした。
もしかして、何かおかしなことが起こってますか…？？
111:デフォルトの名無しさん
08/09/18 01:21:30
>>110
とりあえず、WindowsSDKとVC++2005消して、新しい環境を構築しなおせ。
VC++2008Express SP1
Windows SDK for Windows Server 2008 and .NET Framework 3.5
112:デフォルトの名無しさん
08/09/19 00:14:55
そうします。
やっぱり何か異常な状態なんですね。
113:デフォルトの名無しさん
08/09/21 00:19:51
すいません。Code::Blocks+MinGW+WxWidgets2.8.8の環境構築について
解説しているサイトはないですか？ググったのですが見つからなくて
困ってます。
114:デフォルトの名無しさん
08/09/22 17:26:08
wxPythonでのトラブルですがwxWidgets絡みなので
ここで質問させてください。
wxWidgetsのDLLをUPX圧縮した状態でwxを使うツールを
２重起動するとOS毎固まる症状が出ています。
調べた限りではwxのどのDLL,pydを圧縮しても
同じ症状が出るようです。
OS Win98
WxWidgets 2.8(wxPython2.8.7.1 本家のWin版)
UPX 2.0.3
AVSP(1.3.6 python2.4 wx2.6)ではUPX圧縮してあっても
多重起動できているのでバージョンの問題かも
しれませんが、ツールを一纏めにして配布する
予定なので出来るだけ圧縮して使用したいのです。
御教示お願いします。
115:デフォルトの名無しさん
08/09/23 08:32:34
ツールを一纏めにして最後にZIP圧縮して配布すればよい。UPX圧縮したのを一纏めにするのとほぼ同等の効果がある。
というより何形式であれ圧縮されたファイルはそれ以上ほとんど圧縮されない。何故なら圧縮されているからだ。
116:デフォルトの名無しさん
08/09/23 09:18:59
wxWidgets 2.8.9 リリースされたみたい。
117:デフォルトの名無しさん
08/09/23 10:15:22
コンパイルするのまんどくさいんで
誰かランタイムとヘッダだけまとめて配布してくれ
118:デフォルトの名無しさん
08/09/23 10:19:43
>>115
圧縮されてるから圧縮されないんじゃないよ
均一にどの視点から見ても完全にランダムなデータになってるから圧縮出来ないんだよ
同じデータでも圧縮する前に可逆な方法でランダムに入れ替えたデータでやるとまったく圧縮出来ないよ
圧縮率の上下はいかにランダム性を生ませないような構造にデータを持っていくかが味噌なんだ
最近の圧縮アルゴリズムなんてとっくの昔にエントロピーなんて越えてるし
119:114
08/09/23 17:35:09
>>115
pythonの場合はスクリプトなので起動時のロード時間が
非常にかかります。wxWidgetsのライブラリは
テキストが多く含まれているので圧縮すると半分くらいの
大きさになりロード時間がかなり削減できます。
今回は圧縮率よりもロード時間を気にしています。
念のために。UPX圧縮による実行時のメモリ浪費は
気にしなくて結構です。
120:デフォルトの名無しさん
08/09/23 17:53:39
スレ違いで申し訳ないのですが、widestudioを使ったことがある方っていますか？
IDEも付いている至れり付くせりな感じなのでいいんではないかと思うのですが、あまり稼動実績が見当たらないのですよね。
wxWidgetsと比べてどんな感じかとか、使ったことある方いらっしゃったら教えて頂けると嬉しいです。
121:120
08/09/23 18:02:58
すいませんwidestudioのスレあったのでそっちいきます。。
と言ってもここでも色々意見頂けるとありがたいのですが。
122:デフォルトの名無しさん
08/09/24 03:36:42
widestudioはwx以上に使われてない感があるな～
見た目がOS標準じゃないのがちょっと・・・
OS標準よりもかっこよければ、非ネイティブでも許せるんだけども
123:デフォルトの名無しさん
08/09/25 13:45:50
>>116
おっ、まじですか
そろそろ汎用的なXMLPerserｷﾀｰかな?一寸見てこよ。
つか、>>91-93が完全に空気になっているのに吹いた。
124:デフォルトの名無しさん
08/09/25 20:11:40
>>122
ありがとうございます。
うーん、やはりそんな感じなんですね・・
125:デフォルトの名無しさん
08/09/28 13:43:04
WxWidgetsについて質問させてください。
Windows上で、WxRubyを使ってアプリケーションを作っているのですが
そのアプリケーションの中で、時間のかかる作業（多くのファイルのコピー）を始めると
作業中にウインドウが固まってしまいます。
（ウインドウ上のボタンが押せない＆他のウインドウをアクティブにすると、元のウインドウを表示できなくなる）
定期的にupdateメソッドを実行してみたりもしたのですが
表示が更新されるだけで、固まる問題は解決しませんでした。
WxWidgetsにおいて、時間のかかる作業をやりたいときの
定石のようなものはないでしょうか？
126:デフォルトの名無しさん
08/09/28 14:04:17
処理を分割してタイマーか何かで少しずつ進めるか、処理を別スレッドにする。
wxWidgetsに限らず大抵のウィンドウシステムではこうなるわな。
127:125
08/10/01 15:40:25
ありがとうございました！
Rubyスレッドの中で処理を実行して、WxTimerで10msおきにスレッドに処理を回すことで
余裕を持って動くようになりました
128:デフォルトの名無しさん
08/10/01 20:22:11
MinGWでwxwidgetsをコンパイルして使えるところまで来たと喜んでいたんですが、
簡単なサンプルで
C:/wxWidgets-2.8.9/include/wx/chkconf.h:103:9: #error "wxUSE_DYNLIB_CLASS must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:111:9: #error "wxUSE_EXCEPTIONS must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:119:9: #error "wxUSE_FILESYSTEM must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:127:9: #error "wxUSE_FS_ARCHIVE must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:140:9: #error "wxUSE_DYNAMIC_LOADER must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:148:9: #error "wxUSE_LOG must be defined."
・・・
というようなエラーが出てします。原因は何が考えられますか？
ちなみに付属のサンプルはmakeコマンドでビルド出来ました。コンパイル時の
オプションの問題なのでしょうか？
129:デフォルトの名無しさん
08/10/02 11:12:59
>>128
MinGW 使ったことないから外しているかもだけど
setup.h は include している？
130:デフォルトの名無しさん
08/10/02 11:25:01
`wx-config --cxxflags --libs`とか？
131:デフォルトの名無しさん
08/10/02 11:45:58
>>128
samplesフォルダのminimalはコンパイルできる？
132:デフォルトの名無しさん
08/10/02 11:47:49
ああ、makeで出来たって書いてあった、すまん。
コンパイル時に打ったコマンドをさらした方がよいと思われ。
133:128
08/10/02 14:05:05
レスありがとうございます。
windows上でプログラム作るときは、やはりVC++使ったほうがいいのかなと思って
開発環境を変えようかなと思っています。
>>129
setup.hはインクルードしてませんでした。たぶんコレが原因…
>>132
make時は、
URLﾘﾝｸ(wiki.codeblocks.org)(MSW)
を参考に、mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release
を使ってました。コンパイル時にはNetBeansを使っていたのですが、もうアンインストールしちゃったので分かりません。
NetBeans、もっさりしすぎです・・・
134:128
08/10/02 14:15:34
連投すみません。setup.hが原因の場合、includeパスにwx.hがおいてあるフォルダを
設定していたら、そこにsetup.hを放り込んでおけば良かったのでしょうか？
サンプルのminimalをmakeは出来たのに、自分でコンパイル出来なかったということは、
インクルードパスの設定が不十分でsetup.hが見つからなかったことですよね。たぶん
135:デフォルトの名無しさん
08/10/02 17:56:59
>>134
wxは複数のバージョンや条件(Unicodeだとかデバッグだとか)でビルドしたライブラリ
を置いといて、wx-configにオプションを与えることで設定通りの条件のsetup.h
だとかライブラリだとかが使われるコンパイラ引数を出してくれるようになってる。
なのでsetup.hを手前で適当に放り込むなんてのはしない方がよい。
ファイルがどこにあるか調べ上げて自分でパスを列挙するなんてのとは違う。
136:134
08/10/02 19:11:22
>>135
wx-configはちょっとしたプログラムを作るためのもので、まともなプログラムを
作る場合はmakefileにインクルードパスなどを細かく書くものだと思っていました。
`wx-config`はcygwin,linuxあたりでは使えると思うのですが、windowsの
開発環境(VC++,eclipse,netbeans等)で、コンパイルオプションに指定して
動くものなのですか？
137:デフォルトの名無しさん
08/10/02 19:21:13
もともとMinGWって言ってるじゃねーか。
なんでVCが出て来るんだよ。
138:デフォルトの名無しさん
08/10/02 19:39:53
> まともなプログラムを作る場合は
もっとマシな人間をアサインする
139:デフォルトの名無しさん
08/10/02 19:47:32
>>137
確かに、それは私が悪いんですが、wxwidgets自体がクロスプラットフォームな
ライブラリじゃないですか。そうすると、VCで使う人もいるだろうし、
VCの場合はどうするのか気になったんです。
結局、'wx-config'はcygwin上からでしか使えないのですか？
140:132
08/10/02 19:51:52
wx-configは、makefileに細かく設定するのがめんどくさいから使うもの。
wx-configはWindowsのコマンドラインからは使えないので、使えるようにするためのツールがMSYS。
MSYSからwx-configを使ってコンパイルしてみなされ。
ちなみにwx-configをくくってるのは半角のバッククォートだよ？Shift+@で。コマンド置換とかで調べてみ。
gccのオプションとかについても調べましょう。
141:デフォルトの名無しさん
08/10/02 20:06:45
>>140
回答ありがとうございます。
バッククォート間違ってたorz
どうもいくつか腑に落ちないことがあって、ヘッダファイル除いてみたり
してたんですが、根本的に間違えてるかもしれないです。足掻いてみます。
お騒がせしました。
142:デフォルトの名無しさん
08/10/03 11:02:20
>>139
VisualStudio の場合、基本的には.dspなんかを使うんだけど
それが build/msw フォルダに入っている。
で、その中で include パスの設定なんかが入っているので
そのままコピーするなり好きなように設定すればOK
143:デフォルトの名無しさん
08/10/04 23:14:11
WxWidgetsってIDEで使うの難しいよ。
私のスキルがないのもあるけど、今までEclipse+CDTやCode::Blocksと
環境づくりができなかったよ。もっと簡単にできないと普及しないんじゃ
ない？wxDevC++は簡単だったんだけど、デバッグに難ありじゃ使えない…。
144:デフォルトの名無しさん
08/10/04 23:27:38
今、wxDev-C++のサイト見てきたけど、Web Update したら Ver7相当になるのかな？
そろそろ、バージョンアップの日は近い？？
145:デフォルトの名無しさん
08/10/06 22:31:49
いや、普及しないのはきっとバイナリが馬鹿でかくなるせいだ。
ちょっとしたアプリでも2M以上になるんじゃ恥ずかしくて公開できない。
146:デフォルトの名無しさん
08/10/06 23:04:03
今時実行ファイルがでかいぐらいで恥ずかしがることもあるまい
.NET Frameworkが必要と言った瞬間に文句を付けてくるような奴がいる世の中だ
別途インストールが必要ないのは利点だぜ
147:デフォルトの名無しさん
08/10/06 23:33:03
.NETの必要な400KBのプログラムよりは
単体で動く4MBのプログラムの方が良い
148:デフォルトの名無しさん
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++で分かれていたコードをドロップ。