-
- 1
- 2010/04/09(金) 15:12:36
-
クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)についてのスレ。
本家
ttp://www.wxwidgets.org/
wxWindows日本語プロジェクト
ttp://wxwindowsjp.sourceforge.jp/
Cross-Platform Programming with wxWidgets
ttp://wxwidgets.info/
Let's wxWidgets
ttp://dot-gray.s33.xrea.com/
wxWindowsで始めるC++ GUIプログラミング
ttp://www.h3.dion.ne.jp/~k5_n/wxwin/
wxWidgets でクロスプラットフォーム GUIアプリを作ろう
ttp://0xcc.net/pub/uu-2004-08/
前スレ
【GUI】wxWidgets(旧wxWindows) その4【サイザー】
http://pc12.2ch.net/test/read.cgi/tech/1214657360/
-
- 636
- 2014/03/15(土) 23:39:19.87
-
>>635
了解です、参考にさせていただきます
-
- 637
- 2014/03/21(金) 12:58:58.01
-
わかりました
wxWindowBase::wCaptureMouse()を呼び出すと以降座標とイベントが取得されるようです
-
- 638
- 2014/03/23(日) 17:51:04.60
-
はい。知ってますよ。
-
- 639
- 2014/03/23(日) 19:26:21.87
-
いや、知らないです
-
- 640
- 2014/05/12(月) 21:36:09.61
-
クロスプラットフォームの開発環境について調べてるんですが、wxWidgetsの
GUIは外観とかは各プラットフォームのものが使われるんですか?それとも
独自のテーマになってしまうんでしょうか?
-
- 641
- 2014/05/12(月) 21:48:19.14
-
>>640
各プラットフォームのものが使われます
つまりWindowsならWIN32、LinuxならGTK、MacならCocoa
それぞれの外観になります
対してQtやTk、JavaのSwingなどは独自のテーマになります
-
- 642
- 2014/05/12(月) 21:58:07.29
-
Qtってそうだったんだ
-
- 643
- 2014/05/12(月) 22:57:11.37
-
>>641
ありがとうございます。他の環境まで概括してくださるとは助かりました。
-
- 644
- 2014/05/13(火) 02:25:29.32
-
>>640
敢えてプラットフォームのを使わず
テーマ選ぶ方法もあったはず
-
- 645
- 2014/05/23(金) 01:42:23.54
-
wxFormBuilder 3.4.2betaがリリースされていたので試してみたら、
wxWidgets3.0ベースのGUI描画になったおかげか、2.8をベースに作っていたレイアウトがごっそり狂った。
これから3.0で作る分にはいいと思うけど、2.8で作る分には3.4.0betaで止めておいた方が良いかも。
-
- 646
- 2014/06/03(火) 09:02:12.18
-
Swiftスレ
http://peace.2ch.net/test/read.cgi/tech/1401736341/
-
- 647
- 2014/06/04(水) 21:33:25.19
-
いまこのスレ開いたら、>>645にあったはずの有益な書き込みが消えている…
貼っておこう
> 646 名前:デフォルトの名無しさん [sage]: 2014/05/23(金) 01:42:23.54 ID:NdcsMWjh
> wxFormBuilder 3.4.2betaがリリースされていたので試してみたら、
> wxWidgets3.0ベースのGUI描画になったおかげか、2.8をベースに作っていたレイアウトがごっそり狂った。
> これから3.0で作る分にはいいと思うけど、2.8で作る分には3.4.0betaで止めておいた方が良いかも。
-
- 648
- 2014/06/05(木) 01:15:41.59
-
なんと、板移転したときに消えたのかもしれないね。
-
- 649
- 2014/06/19(木) 12:54:27.42
-
wxWidgetsを使って作られたプログラムの一覧ってあったりするのかね?
とりあえずAudacityは知ってる
-
- 650
- 2014/06/19(木) 19:37:20.57
-
http://www.wxwidgets.org/about/screenshots/
とか
-
- 651
- 2014/06/19(木) 19:41:04.43
-
おーありがとう
後で見て回る
テンプレにあってもいいじゃないかな?
-
- 652
- 2014/06/19(木) 20:07:59.88
-
車の再発見
-
- 653
- 2014/06/19(木) 22:56:02.45
-
商用アプリは
http://wiki.wxwidgets.org/Commercial_applications_using_wxWidgets
-
- 654
- 2014/08/20(水) 15:57:43.03
-
>>644
そんなんあったっけ?
-
- 655
- 2014/08/24(日) 18:20:53.22
-
wxWidgetsで、フォームを閉じる処理をして実際に閉じるまでの間に発生するイベントとかある?
.NETで言うところのOnClosingみたいな感じで。
-
- 656
- 2014/08/25(月) 02:12:21.61
-
OnClose
OnVeto
-
- 657
- 2014/08/25(月) 14:23:49.85
-
>>656
?
おかげで作業が進みました。
-
- 658
- 2014/08/26(火) 17:09:00.43
-
Windows で、
CrossBlock + MinGW + wxWidget
で最も簡単な GUI アプリを基本プロジェクトで作成してみたところ、
MyTest.exe のサイズ:736KB
(wxWidgetのDLL) wxmsw28u_gcc_custom.dll のサイズ : 15.9MB
MyTest.exe のメモリ使用量 : 7,732KB // TaskManagerの表示
となった。
この基本アプリは、HelpでAboutでメッセージ・ボックスが表示できる
ようになっているが、メニュー項目をクリックしてから実際にそれが
出るまで数秒かかる。実験したのはそこそこ速いマシンと速いWindows
での事。
-
- 659
- 2014/08/26(火) 17:09:45.00
-
ただし、遅いのは最初の一回だけ。
一度でも表示すると後は速い。
-
- 660
- 2014/08/26(火) 17:56:51.72
-
Mailer の Thunderbird-Portable なんかもマルチプラットフォーム対応
だけど、起動がかなり遅い。これも巨大な dll を読み込んだりしてる
からかな。
起動やメニュー操作が遅くなるのはマルチプラットフォーム化する代償
として負わされるのかも知れん。
こういうツールキットで軽快なアプリを作るのは難しいのかもな。
-
- 661
- 2014/08/26(火) 19:14:34.45
-
小規模の自作ソフトでwxWidgetsをスタティックリンクしない理由が分からん
わざわざ合計バイナリサイズを大きく、速度も遅くする理由がどこにあるのだろう
-
- 662
- 2014/08/26(火) 21:27:38.25
-
>>661
なるほど、スタティックリンクにすれば、起動後になってからユーザーの
命令に対する応答が遅れる事はなくなるかもしれない。
起動が遅くなるだけで済むんなら、そっちの方がストレスが少ないかも。
-
- 663
- 2014/08/26(火) 21:50:56.10
-
ある程度規模が大きくなるとスタティックリンクだと初回起動が遅すぎになので
dllにモジュールを分割してやったほうがいい
起動時のメモリへのロード時間はどうしようもないのでスプラッシュをつけてごまかす
-
- 664
- 2014/08/26(火) 22:39:34.76
-
CrossBlockでは、monolithic タイプのライブラリをビルドしてから使う
ようになってるんだけど、それも遅い原因なのかな。
でも起動後にユーザー入力に対するレスポンスが遅いのはどう説明すれば
いいんだろう?
普通の Windows の仕様だと原則、起動時に全ての DLL をロードする。
LoadLibrary()を使えば動的にロードすることも可能は可能だけど、
それをする必要は旧OSでサポートしてなかった新OSのDLLをロードする
ような場合は、多言語化のサポートなど。
なるほど、多言語化のせいかも。_("xxx") みたいなのがあったから、
gettext を使ってる。それでリソースを動的ロードしているのか。
-
- 665
- 2014/08/27(水) 04:40:25.51
-
何度かアプリ起動しているうちにWindowsのFetchが学習してくれて
DLLとか先読みしてくれるようにならないのだろうか
-
- 666
- 2014/08/27(水) 06:47:58.33
-
>>665
それはなる。
・ディスクの内容は、メモリにキャッシュされる。
・同じDLLは、全てのアプリで物理メモリが共有されると聞いたことがある。
# >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。
それより、wxWidget 本家のソース配布に入っている samples を
Windows の mingw32 でビルドしてみたところ、全然遅くなかった。
・アプリの起動は速い。
・起動後のメニューコマンドやユーザー入力に対するレスポンスも速い。
・Aboutダイアログも瞬間ではないが、0.3秒程度で、Windows Nativeアプリ
でも、その程度の遅さはある場合があるので遜色ない。
CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
ライブラリを使用しているからか。
-
- 667
- 2014/08/27(水) 07:54:18.52
-
>>666
># >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。
なんだと思ったらわりと素人じゃねえかおい
>CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
>ライブラリを使用しているからか。
monolithicってのはwxWidgetsのモジュール全部入りのDLL作るという意味なので遅くて当然
(実際試したことないので遅いというのは初めて知ったが…)
普通は ./configure --prefix=/mingw --enable-shared みたいに指定してビルドするから
モジュールごとに分割されたDLLが作成される
Windows上で開発する時はMinGW + NTEmacs/eclipse CDTの環境がおすすめ
-
- 668
- 2014/08/27(水) 09:58:52.27
-
>>667
最後の段落:多分、wxWidgets 本体を MInGW32 用のビルドする際は、
configure は使えない気がする。
CodeBlocks のQuickなんたらRefの説明では、いきなり、
make するように支持されていた。しかも、-fno なんたら dll-export
みたいなオプションを付けろと指示。これは、MinGW32のバグで、
付けないと最後のldの段階でldがクラッシュする事をたまたま発見。
ところで話は変わって聞いておきたいのですが、 eclipse では
wxWidget のイベントを書くようなときに
・BEGIN_EVENT_MAP に自動的に一行マクロを挿入してくれて
・*.h にもメンバ関数宣言を書いてくれて
・*.cpp にも5行くらいの関数定義本体の雛形を書いてくれ
たりしますか?
-
- 669
- 2014/08/27(水) 10:01:06.29
-
つまり、イベント・ハンドラを追加したとき、
BEGIN_EVENT_TABLE(wxListMainWindow,wxScrolledWindow)
EVT_PAINT (wxListMainWindow::OnPaint)
EVT_MOUSE_EVENTS (wxListMainWindow::OnMouse)
EVT_CHAR (wxListMainWindow::OnChar)
EVT_KEY_DOWN (wxListMainWindow::OnKeyDown)
EVT_KEY_UP (wxListMainWindow::OnKeyUp)
EVT_SET_FOCUS (wxListMainWindow::OnSetFocus)
EVT_KILL_FOCUS (wxListMainWindow::OnKillFocus)
EVT_SCROLLWIN (wxListMainWindow::OnScroll)
EVT_CHILD_FOCUS (wxListMainWindow::OnChildFocus)
END_EVENT_TABLE()
とか、クラスを書くとき
IMPLEMENT_DYNAMIC_CLASS(wxListMainWindow,wxScrolledWindow)
見たいなものの自動生成があるとうれしいんですが、そういう IDE
はありません?
-
- 670
- 2014/08/29(金) 11:13:03.59
-
wxWidgetsの問題点の1つは、プログラムのサイズが大きくなる事。
特に静的リンクしたときに顕著。
Windows は、VC++ にて、
ac1rd: CUI の Win32 と printf() を使ったもののリリース・動的リンク版が 16KB程度。
puts() を使えばもっと小さく出来る。
ac1rs: CUI の Win32 と printf() を使ったもののリリース・静的リンク版が 40KB程度。
puts() を使えばもっと小さく出来る。
ag2rd: GUI の MFC の 基本的な MDI アプリがリリース・動的リンク版で 36 KB 程度。
ag2rs: GUI の MFC の 基本的な MDI アプリがリリース・静的リンク版で 332 KB 程度。
wxWidgets 2.8.12 の samples では、
bc1rd: CUI の console.exe がリリース・動的リンク版で 138KB
bc1rs: CUI の console.exe がリリース・静的リンク版で 863KB
bc1dd: CUI の console.exe がデバッグ・動的リンク版で 184KB
bg2rd: GUI の keyboard.exe がリリース・動的リンク版で 293KB
bg2rs: GUI の keyboard.exe がリリース・静的リンク版で 2,924KB
bg2dd: GUI の keyboard.exe がデバッグ・動的リンク版で 492KB
ただし、bc1xx は、アプリ本体のプログラムが複雑なことをしているようなので、
もっと小さく出来る可能性があり。
-
- 671
- 2014/08/29(金) 19:04:31.75
-
その説明にac1だの何だの自分以外分からない定義を使う必要があったのだろうか
-
- 672
- 2014/08/29(金) 19:07:59.00
-
今から見るとそうかも。
a: Windows Native or MFC
b: wzWidgets
c: CUI
g: GUI
r:release, d:debug
d:dynamic link, s:static link
-
- 673
- 2014/08/30(土) 00:17:55.46
-
>>668
>最後の段落:多分、wxWidgets 本体を MInGW32 用のビルドする際は、
>configure は使えない気がする。
なにいってんだCodeBlocksのドキュメントにそう書いてあるだけで
基本autotoolsで作られたソースはconfigureでビルドできるぞ
実際自分はWindows上のmingw32/64、LinuxのクロスビルドからのMinGWでconfigure使ってる
なぜMakefileでやれという指示なのかというと、そのほうが簡潔で保守しやすいからだ
あとGNU MakeじゃないMakeでもビルドできるようにしたいとかいう微妙なこだわりが有る場合も有る
>>669
エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
ソースのひな形自動生成機能は知らんなあ
-
- 674
- 2014/08/30(土) 00:21:29.81
-
>>670
MinGWビルドでバイナリをストリップしたやつとか比較しないのか
-
- 675
- 2014/08/30(土) 07:56:49.02
-
>>674
Stripに詳しくないので、言っている意味が分からない。
Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの?
-
- 676
- 2014/08/30(土) 07:58:19.03
-
>>674
Stripに詳しくないので、言っている意味が分からない。
Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの?
-
- 677
- 2014/08/30(土) 08:15:51.54
-
日本語インライン入力の対応ってまだなの?
というか予定自体なくて諦めた方がいい?
wxWidgets使ってるEditraってエディタにそろそろ移行できるかなと
思って試してみたら、未だにインライン入力できない
-
- 678
- 2014/08/30(土) 08:19:53.34
-
>>674
小さくなりますた!!
Relese, 動的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_mswdll/keyboard.exe
strip 前:299,808 bytes
strip 後:124,430 bytes
Relese, 静的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_msw/keyboard.exe
strip 前:2,993,255 bytes
strip 後:1,887,758 bytes
strip 後も、*.exe が正常に起動することを確認済み。
-
- 679
- 2014/08/30(土) 08:22:26.84
-
>>673
>エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
詳しく:
-
- 680
- 2014/08/30(土) 11:51:11.86
-
馬鹿には無理
-
- 681
- 2014/08/30(土) 12:02:34.82
-
スタンド・アローン・コンプレックスと化した馬鹿には無理さんオッスオッス
>>679
cua-modeでググって
http://qiita.com/yyamamot/items/7efcbfdcccdb5fa45ebe
例えばイベントテーブルとかはこれでザクッと一気に書ける
もちろん個々のwxWindowIDとメソッド定義は書かなくてはいけないが
クラス名とマクロ定義は同じ文字列の繰り返しなのでだいぶ楽になる
-
- 682
- 2014/08/30(土) 13:53:01.64
-
>>681
あー、そういう風に沢山のイベントを一気に書きたいんじゃなくて、
開発段階で徐々にイベントを追加して行く際に、
1. *.h のクラス内にメンバ関数宣言
2. *.cpp に EVENT MAP
3. *.cpp に メンバ関数定義の本体
の三箇所にコードを書くのが面倒ということなんだわ。
-
- 683
- 2014/08/30(土) 14:33:49.98
-
>>682
それは自分で作らないと無さげですねえ
-
- 684
- 2014/08/30(土) 19:11:57.66
-
wxFormBuilderでしかGUIとイベントを設計できない俺には何言ってるのかさっぱりわからんぜよ……
-
- 685
- 678
- 2014/08/31(日) 15:54:21.95
-
wxAUI のデモ・アプリ wxauitest.exe のサイズは、1,417,216 bytes。
スタンドアロンのアプリで、環境変数からパスを完全に消去しても起動
できた。つまり、ライブラリはDLLを使わずに静的リンクされている。
wxAUIはFloating & Dockingのできる強力なGUI。
>>678 に示した keyboard.exe はキーボードから押されたキーの値を
表示するだけで、上記アプリよりずっとシンプルなのにも関わらず、
1,887,758 bytes と 470,542 bytes も大きい。
理由は不明。
-
- 686
- 2014/08/31(日) 15:56:18.96
-
そんなことしなくても
DLLの依存関係調べるツールあるのに
このページを共有する
おすすめワード