【GUI】wxWidgets(旧wxWindows) その5【サイザー】
レス数が900を超えています。1000を超えると表示できなくなるよ。
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 は、アプリ本体のプログラムが複雑なことをしているようなので、
もっと小さく出来る可能性があり。 その説明にac1だの何だの自分以外分からない定義を使う必要があったのだろうか 今から見るとそうかも。
a: Windows Native or MFC
b: wzWidgets
c: CUI
g: GUI
r:release, d:debug
d:dynamic link, s:static link >>668
>最後の段落:多分、wxWidgets 本体を MInGW32 用のビルドする際は、
>configure は使えない気がする。
なにいってんだCodeBlocksのドキュメントにそう書いてあるだけで
基本autotoolsで作られたソースはconfigureでビルドできるぞ
実際自分はWindows上のmingw32/64、LinuxのクロスビルドからのMinGWでconfigure使ってる
なぜMakefileでやれという指示なのかというと、そのほうが簡潔で保守しやすいからだ
あとGNU MakeじゃないMakeでもビルドできるようにしたいとかいう微妙なこだわりが有る場合も有る
>>669
エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
ソースのひな形自動生成機能は知らんなあ >>670
MinGWビルドでバイナリをストリップしたやつとか比較しないのか >>674
Stripに詳しくないので、言っている意味が分からない。
Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの? >>674
Stripに詳しくないので、言っている意味が分からない。
Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの? 日本語インライン入力の対応ってまだなの?
というか予定自体なくて諦めた方がいい?
wxWidgets使ってるEditraってエディタにそろそろ移行できるかなと
思って試してみたら、未だにインライン入力できない >>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 が正常に起動することを確認済み。 >>673
>エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
詳しく: スタンド・アローン・コンプレックスと化した馬鹿には無理さんオッスオッス
>>679
cua-modeでググって
http://qiita.com/yyamamot/items/7efcbfdcccdb5fa45ebe
例えばイベントテーブルとかはこれでザクッと一気に書ける
もちろん個々のwxWindowIDとメソッド定義は書かなくてはいけないが
クラス名とマクロ定義は同じ文字列の繰り返しなのでだいぶ楽になる >>681
あー、そういう風に沢山のイベントを一気に書きたいんじゃなくて、
開発段階で徐々にイベントを追加して行く際に、
1. *.h のクラス内にメンバ関数宣言
2. *.cpp に EVENT MAP
3. *.cpp に メンバ関数定義の本体
の三箇所にコードを書くのが面倒ということなんだわ。 wxFormBuilderでしかGUIとイベントを設計できない俺には何言ってるのかさっぱりわからんぜよ…… wxAUI のデモ・アプリ wxauitest.exe のサイズは、1,417,216 bytes。
スタンドアロンのアプリで、環境変数からパスを完全に消去しても起動
できた。つまり、ライブラリはDLLを使わずに静的リンクされている。
wxAUIはFloating & Dockingのできる強力なGUI。
>>678 に示した keyboard.exe はキーボードから押されたキーの値を
表示するだけで、上記アプリよりずっとシンプルなのにも関わらず、
1,887,758 bytes と 470,542 bytes も大きい。
理由は不明。 そんなことしなくても
DLLの依存関係調べるツールあるのに ちなみにwxWidgetsで作った一番小さいexe探したら65kbのがあった Windows実行形式であっても、コンパイラが、MinGW32 と VC++ でサイズに
大幅な違いが出てくるのかな? >>685
実行ファイルの関数テーブルに何が入っているか nm で確認したら少しはわかるかもね
>>688
大幅とは行かないかもしれないがVC++はWindowsのみをターゲットにしているから
基本的にコンパイル後のバイナリサイズは MinGW > VC++ だよね CodeBlocks + MinGW32 で、
wxWidgets の Monolithic、ASCIIライブラリ, 静的リンク で
最も簡単な Frame Based な GUI を作成してみたら、
2,073,600 バイトよりは小さくならなかった。
wxWidgets のライブラリは、
-Os
-ffunction-sections
-fdata-sections
でコンパイルし、
-Wl,--gc-sections -s
でライブラリ化した。その時のコマンド:
mingw32-make -j2 -f makefile.gcc CPPFLAGS="-MD -MP -DHAVE_W32API_H
-D__WXMSW__ -DNOPCH -DwxDEBUG_LEVEL=0 -DNDEBUG" CFLAGS="-mthreads
-fmessage-length=0 -ffunction-sections -fdata-sections -fno-builtin
-Os" CXXFLAGS="-mthreads -Wno-ctor-dtor-privacy -fmessage-length=0
-ffunction-sections -fdata-sections -fno-builtin -Os
-fno-keep-inline-dllexport" LDFLAGS="-Wl,--subsystem,windows
-Wl,--gc-sections -s -mthreads -mwindows"
BUILD=release UNICODE=0 SHARED=0 MONOLITHIC=1
CodeBlocks でアプリのリンクのオプションにも、
-Wl,--gc-sections -s
は付けてある。 ちなみに、Unicode 版より ASCII 版のほうが小さくなることを確認済みである。
[Compiler settings - #defines]
が、標準では、
__GNUWIN32__, __WXMSW__, WXUSINGDLL, wxUSE_UNICODE, WX_PRECOMP
となるところを:
__GNUWIN32__, __WXMSW__
だけとし、
[Search Directories] の Compiler, Linker, Compiler
の、gcc_dll の部分を、gcc_lib に変えた。
アプリにリンクするリンクライブラリとしては、上記で作成した Monolithic
ライブラリだけでは足りず、以下が必要であった。Win32のimport libraryは、
ライブラリを動的リンクする場合はライブラリのDLLが行っているので必要ない
が、ライブラリを静的リンクする場合は、アプリが直接リンクする必要がある
ため必要となるのは理解できる。libwxpng, libwxjpeg, libwxtiff, libwxzlib
が必要となった理由は不明。
libwxmsw28 // これが wxWidgets の monolithic ライブラリ本体。
libwxpng
libwxjpeg
libwxtiff
libwxzlib
libuuid // Win32 の import library
libcomctrl32 // Win32 の import library
libwinspool // Win32 の import library
liboleaut32 // Win32 の import library
libole32 // Win32 の import library
ちなみに、wxWidgets を動的リンクする場合は、ここが、libwxmsw28
だけで済む。 誤:[Search Directories] の Compiler, Linker, Compiler
正:[Search Directories] の Compiler, Linker, Resource Compiler
誤:Win32のimport libraryは、ライブラリを動的リンクする場合はライブ
ラリのDLLが行っているの
正:wxWidgets ライブラリをアプリに動的リンクする場合は
wxWidgets ライブラリの DLL 部分が Win32 の import library の
リンクを行っているの サイズはどうでもよくないか。exeを使う側としては速度では?
あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。 完全テンプレートライブラリにしたら軽くなるんだろうか >>694
でも wxWidgets がやっていることの割にはリンクされるバイト数が多すぎる
感じがする。
基本、Win32をラッピングしているだけなのだから、2MBも必要ない。 ラッピングしてるだけじゃなくマルチプラットフォームのために徹底した抽象化をしてるんでしょ
とソースも読まず推測 >>697
でもソースを呼んでみたら、たとえば、wxListCtrl なんかは、
Win32 の LIST CONTROL をそのまま使っていた。
DrawRect()などで書いているわけではない。
ただし、wxGenericListCtrl だったかは、DrawRect()みたいなグラフィック
関数で独自に描画していた。が、それは、Windows版では簡単には使えない
という噂を聞いたが。 >>697
wxWidgets の基本設計は、Widgetは、OS nativeの物を使うが、
どんなサイズであっても対応できるように Sizer で Layout を
コントロールする、という物。
なので、抽象化はサイズと配置程度で済むはずなのだが・・・。 >>696
>>697の言ってることが正しい。
---------------------
wxWidgets
---------------------
Win32 | GTK | Cocoa etc...
---------------------
wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
型情報・関数テーブルの情報だけで結構容量食う
>>692
ASCIIモードでビルドするのはやめておいたほうがいい
日本語使えないし
というかなぜMonolithicビルドにこだわるのか…
普通にconfigureからビルドしてdllごと配布したほうが立ち上がりは早い wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。
実は、Win32 の LIST CONTROL は、
・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
奇妙な動作をする。奇妙な動作と言ったがバグに近い。
こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。 wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。
実は、Win32 の LIST CONTROL は、
・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
奇妙な動作をする。奇妙な動作と言ったがバグに近い。
こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。 >>700
>wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
>型情報・関数テーブルの情報だけで結構容量食う
オイラはコンパイラの基本部分に詳しいが、それだけで1MBなどには
ならない。 >>694
諦めることも手かも知れないけど、やっている事の規模とサイズとの
ギャップに納得がいかない人もいるはず。
wxWidgetsはラッピング・ライブラリの一種。
8bit時代、16bit時代を知る人にとって、Widget 程度が64KBを超える
事があってはならない。どういうプログラミングをしたら2MBにもなる
のか。 >>703
>>704
一理あるのでちょっとメーリングリストを探ってみたり
まず、wx/wx.hがいろいろなヘッダファイルを事前にincludeしているので
それがバイナリサイズの増加の一因になっているらしい
[wxMSW]: why EXE-files are so large?
https://groups.google.com/d/msg/wx-users/psTmm3nB6AU/9j6-4ir95-gJ >>591 のライブラリを samples/keyboard にも使ってみたら、
keyboard.exe のサイズを 1,619,968 にまで縮小することに成功した。
コンパイラは MinGW32 のまま。
条件は:release, 非UNICODE(ASCII), SHARED=0(静的リンク), MONOLITHIC = 1
どうやら MONOLITHIC であるかどうかは最終 exe サイズには関係してないらしい。
ライブラリと言うのは集めてもばらしても、最終 exe のリンク結果には影響を
及ぼさない事が基本なので、元々当たり前なことなのだが。
[samples/keyboard]
$ mingw32-make -f makefile.gcc BUILD=release UNICODE=0 SHARED=0 MONOLITHIC=1
[samples/keyboard/makefile.gcc の修整]
-------------------------------------------------------------------------------------
$(OBJS)\keyboard.exe: $(KEYBOARD_OBJECTS) $(OBJS)\keyboard_keyboard_rc.o
$(CXX) -o $@ $(KEYBOARD_OBJECTS) $(__DEBUGINFO) $(__THREADSFLAG)
-L$(LIBDIRNAME) -Wl,--subsystem,windows -Wl,--gc-sections -Wl,-s -mwindows
$(____CAIRO_LIBDIR_FILENAMES_p) $(LDFLAGS) $(__WXLIB_CORE_p) $(__WXLIB_BASE_p)
$(__WXLIB_MONO_p) $(__LIB_TIFF_p) $(__LIB_JPEG_p) $(__LIB_PNG_p)
-lwxzlib$(WXDEBUGFLAG) -lwxregex$(WXUNICODEFLAG)$(WXDEBUGFLAG) -lwxexpat$(WXDEBUGFLAG)
$(EXTRALIBS_FOR_BASE) $(__UNICOWS_LIB_p) $(__GDIPLUS_LIB_p) $(__CAIRO_LIB_p)
-lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
-loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32
--------------------------------------------------------------------------------------
上記は original の makefile.gcc に、
-Wl,--gc-sections -Wl,-s
を追加しただけ。 wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。
実は、Win32 の LIST CONTROL は、
・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
奇妙な動作をする。奇妙な動作と言ったがバグに近い。
こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。 >>694
>あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。
「>>692」で示した Win32 import library は、Windows のシステム DLL
をリンクするための小さなライブラリ。例えば、
libcomctrl32 をリンクしていても、実際は、comctrl32.dll が動的リンク
される。libcomctrl32.a は、MinGW32 が用意している import library で:
/xxx/CodeBlocks/MinGW/lib/libcomctl32.a # 86,428 bytes
C:/WINDOWS/system32/comctl32.dll # 617,472 bytes
のように、windows/system32 の comctrl32.dll を動的リンクするための
呼び出し部分だけを提供する小さなライブラリ。 MONOLITHIC の値が違うと別の *.o が作成されることが判明。
以下は、SHARED=0(静的リンク)の場合の、MONOLITHIC が 0 と 1 の場合。
CORELIB_CXXFLAGS = $(__DEBUGINFO) $(__OPTIMIZEFLAG) $(__THREADSFLAG) \
$(GCCFLAGS) -DHAVE_W32API_H -D__WXMSW__ $(__WXUNIV_DEFINE_p) \
$(__DEBUG_DEFINE_p) $(__NDEBUG_DEFINE_p) $(__EXCEPTIONS_DEFINE_p) \
$(__RTTI_DEFINE_p) $(__THREAD_DEFINE_p) $(__UNICODE_DEFINE_p) \
$(__MSLU_DEFINE_p) $(__GFXCTX_DEFINE_p) -I$(SETUPHDIR) -I..\..\include \
$(____CAIRO_INCLUDEDIR_FILENAMES) -W -Wall -DWXBUILDING -I..\..\src\tiff \
-I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex \
-I..\..\src\expat\lib -DwxUSE_BASE=0 $(__RTTIFLAG) $(__EXCEPTIONSFLAG) \
-Wno-ctor-dtor-privacy $(CPPFLAGS) $(CXXFLAGS)
MONOLIB_CXXFLAGS = $(__DEBUGINFO) $(__OPTIMIZEFLAG) $(__THREADSFLAG) \
$(GCCFLAGS) -DHAVE_W32API_H -D__WXMSW__ $(__WXUNIV_DEFINE_p) \
$(__DEBUG_DEFINE_p) $(__NDEBUG_DEFINE_p) $(__EXCEPTIONS_DEFINE_p) \
$(__RTTI_DEFINE_p) $(__THREAD_DEFINE_p) $(__UNICODE_DEFINE_p) \
$(__MSLU_DEFINE_p) $(__GFXCTX_DEFINE_p) -I$(SETUPHDIR) -I..\..\include \
$(____CAIRO_INCLUDEDIR_FILENAMES) -W -Wall -DWXBUILDING -I..\..\src\tiff \
-I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex \
-I..\..\src\expat\lib -DwxUSE_BASE=1 $(__RTTIFLAG) $(__EXCEPTIONSFLAG) \
-Wno-ctor-dtor-privacy $(CPPFLAGS) $(CXXFLAGS) 違いは、-DwxUSE_BASE の部分で、
MONOLITHIC = 0 の場合 : -DwxUSE_BASE=0 // #define wxUSE_BASE 0
MONOLITHIC = 1 の場合 : -DwxUSE_BASE=1 // #define wxUSE_BASE 1
となっている。
例えば、/xxx/src/msw/dc.cpp は、同じソースに対し make に渡すオプションに応じて
以下の2種類の *.o ファイルが作成される。
1つ目は、MONOLITHIC=0の時に作られ、2つ目は、MONOLITHIC=1の時に作られる。
ifeq ($(USE_GUI),1)
$(OBJS)\corelib_dc.o: ../../src/msw/dc.cpp
$(CXX) -c -o $@ $(CORELIB_CXXFLAGS) $(CPPDEPS) $<
endif
ifeq ($(USE_GUI),1)
$(OBJS)\monolib_dc.o: ../../src/msw/dc.cpp
$(CXX) -c -o $@ $(MONOLIB_CXXFLAGS) $(CPPDEPS) $<
endif
ソースを見ると、wxUSE_BASE の値に応じて場合分けされている箇所が多数ある。
つまり、MONOLITHIC の 0 と 1 の違いは単に *.o ファイルの集め方の問題では無い。
コンパイル時点のソース自体が変更されるのである。故にリンク後の*.exe のサイズ
が変わって来ても不思議は無い。これは驚くべきことである。 >>713
コンパイルオプションまで変えてしまって何をやっているかと言うこと
なんだよ。ライブラリの集め方だけの問題じゃないって事なんだ。
ライブラリの動作が変わってしまい、MONOLITHIC が 0 と 1とで結果が違うことに
悩まされる可能性もある。
単にライブラリのオブジェクトの集め方(含み方)の問題では無いとすると、MONOLITHIC
オプションの意味はいったい何かと言う問題になる。
また、最終EXEが大きくなる理由として、アプリが使ってないオブジェクトを
非常に基本的なライブラリの一部が参照している可能性がある。
そしてそのオブジェクトが別のオブジェクトを勝手に参照して・・・という
事が続いて最終EXEのサイズが肥大化してしまっているのかも知れない。 http://wiki.wxwidgets.org/WxWidgets_Build_Configurations
「MONOLITHIC=1 :
Packages all libraries in a single file.
(Note: do not combine this option with a static build.)」
とあった。static build の時は、MONOLITHIC=1 にするな、と
書かれている・・・。 configure を試してみたら、configureのヘルプ通りには行かなかった:
・以下、xxx = wxWidgets-2.8.12 とする。/xxx/ に configure スクリプトがある。
・configureを使用するために、単なるcmd.exeではなくcygwin環境が必要であった。
・cygwinを起動する際、cygwin に入ってからの PATH が、
(MinGWのbin) : /usr/local/bin/ : /usr/bin/ : (Winからのbin)
の順になるようにした。
・カレントを /xxx/ にして configure した。configure の引数には少なくとも
・--build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-pc-mingw32
を指定し、例外, rtti, regex, zlib, jpeg, png, tiff は無効にするオプション
を設定した。他にも無効にしたものも多い。大量に及ぶので スクリプトに記述した。
・Makefileが普段の /xxx/build/msw/ ではなく、/xxx/ に作られた。
・/xxx/samplesのサブディレクトリにあるMakefileが書き換えられた。
・setup.h が、
/xxx/lib/wx/include/msw-ansi-releasw-static-2.8/wx
/xxx/lib/wx/include/msw-ansi-releasw-2.8/wx
の二箇所に作成された。元々各所にあるが、例としては
/xxx/include/ws/msw や /xxx/lib/gcc_lib/msw/wx にある。
・/xxx/ で make[ret] してみた。
・途中で例外を有効にするように言われたので有効にした。 ・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
ないエラーとなった。。
そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
を最後尾に追加した。
・make には成功した。
・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
/build/msw から make した場合は、/xxx/lib/gcc_lib に作られるのと対照的
である。
・/xxx/samples/console で make してみたら、成功した。
・「プロシージャエントリポイント _gxx_persolanity_v0 が
ダイナミック リンク ライブラリ libstdc++-6.dll から見つかりませんでした。」
のメッセージボックスが出て起動できず。
・Makefileを書き換えて、LIBS の最後に -lstdc++ を書いても症状は治まらない。 ・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
ないエラーとなった。。
そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
を最後尾に追加した。
・make には成功した。
・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
/build/msw から make した場合は、/xxx/lib/gcc_lib に作られるのと対照的
である。
・/xxx/samples/console で make してみたら、成功した。
・「プロシージャエントリポイント _gxx_persolanity_v0 が
ダイナミック リンク ライブラリ libstdc++-6.dll から見つかりませんでした。」
のメッセージボックスが出て起動できず。
・Makefileを書き換えて、LIBS の最後に -lstdc++ を書いても症状は治まらない。 console.cpp の中身を printf() だけを使う4行の main() 関数だけに
書き換えてみたら問題なく起動して普通に文字列が表示された。
なので、MinGW 環境の問題ではなさそう。 wxPrintf()だけを使った console 版 hello world が、static link
で 96,468 bytes で済んだ。
ところが、wxString を使った場合、作成した exe を実行しようとすると
>>721 後半で書いたメッセージ・ボックスが出て起動できない。 libstdc++がダイナミックリンクになってるだけだろ。 >>724
ダイナミックライブラリであるところの
libstdc++-6.dll
は既に読み込めているんですわ。
「libstdc++-6.dll から見つかりませんでした。」
の「から」がそれを表している。
なお、configureを使わずに、build/msw から build したライブラリだと
wxStringとwxPrintfだけを使ったconsoleアプリは、静的リンクでも
451,584 バイトで済むことが判明。こちらはちゃんと起動できる。 パスが通ったところに互換性のない別バージョンのdllがあるんだろ。
mingwだとsjljとdw2の2種類あるから。 MinGW/bin を
i686-pc-mingw32-g++ と MinGW/bin/g++ は別物らしくコンパイラのサイズ
(作ったプログラムのサイズではなく変換機のサイズ)がそもそも違う。
また、前者では、リンク段階で何もエラーを出さないが、
後者では、ちゃんと、_gxx_persolanity_v0 や _Unwind_Resume が
undefined reference というエラーになる。 >>726
最初、xxx dw2 yyy.dll が見つからない、と言うメッセージ・ボックス
が出たのだが、そのdllを検索すると MinGW/bin にある事が分かって、
そこにパスを通したらそのメッセージ・ボックスは出なくなった。
その代わりに >>721 のメッセージ・ボックスが出るようになった。 結論的に言うと、自分のローカルにMinGW32 の別バージョンが沢山あった。
サンプルのコンパイルに使われたのと同じMinGW32のbinだけをパスに
設定してからサンプルを起動すると実行できるようになった。
実行結果も問題ない。実行ファイルはstripするとサイズが小さくなったが、
>>691のライブラリをリンクした物よりも大きくなってしまった。
[wxStringを使った最小な cui program のサイズ]
・>>691 のwxライブラリ使用時 : 451,584 bytes
コンパイラは CodeBlocks付属のMinGW
・configureしたwxライブラリ使用時 : 547,342 bytes
コンパイラは cygwinにインストールしたMinGW
[wxFrameを使った最小な gui program のサイズ]
・>>691 のwxライブラリ使用時 : 1,611,264 bytes
コンパイラは CodeBlocks付属のMinGW
なお、今回は、>>719-720 のような不具合を回避するため、RegExや、png,jpeg,tiff,zlib
などはconfigureで有効にしておいた。そうすると>>720の最初のヘッダファイル問題は
消えたので、何か良いことがあるかと思ったから。ただし、様子を見るとそれは必要なかった
かも知れない。サイズ縮小のためには disable にすべきかも。 よかったな
-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
にすればlibstdc++とスタティックリンクできるかもな cygwin版のMinGWと、cmd.exe 版のMinGWって結構違うような気がしてきた。
Makefileなんかもcygwin版だと/cygdrive/c/xxx/yyy/zzz の形式になっている
のに対し cmd.exe版は c:\xxx\yyy\zzz になっているらしい。
また、コンパイラに -I 指定したパスなんかも同様の違いがあるらしく、
configureが作ったMakefileは、cygwin版MinGW用で、
cmd.exe版のMinGWでは、#inclde "wx/setup.h" のパスが探せなかったり
する。
build, host, target の指定は、全て mingw を指定していたのだから、
cygwinが入り込む余地は無かったはず。これは、configure.inか、
Makefileのどちらかを自前で修整する必要がありそう。
さらに、makeが(?)
process_begin: CreateProcess(NULL, sh xxxxxx, ...) failed.
というエラーを出すことがあり、その原因を探る必要もある。 cygwin版のMinGWと、cmd.exe 版のMinGWって結構違うような気がしてきた。
Makefileなんかもcygwin版だと/cygdrive/c/xxx/yyy/zzz の形式になっている
のに対し cmd.exe版は c:\xxx\yyy\zzz になっているらしい。
また、コンパイラに -I 指定したパスなんかも同様の違いがあるらしく、
configureが作ったMakefileは、cygwin版MinGW用で、
cmd.exe版のMinGWでは、#inclde "wx/setup.h" のパスが探せなかったり
する。
build, host, target の指定は、全て mingw を指定していたのだから、
cygwinが入り込む余地は無かったはず。これは、configure.inか、
Makefileのどちらかを自前で修整する必要がありそう。
Makfileの / を \ で置換して、/cygdrive/x/ を x:/ にしてみたら結構
行ける。途中、pch でファイルにアクセス拒否で書き込めないと言われるが、
もう一度 make すると、何事も無かったように続行する。 >>732
wx アプリのサイズダウンの仕方関連なんだけど。 作ったバイナリのサイズなんてwxWidgetsのビルド方法によって大きく変わるうえ、
最終的に使い物にならないライブラリの出来上がりとなるのが目に見えている
本当に必要なものだけを炙り出すつもりなら止めはしないが、どう考えても徒労でしかないと思うぞ 正直wxWidgetsのバイナリサイズの話以外はほとんど既出だし
CygwinとMinGWの仕様の違い、クロスコンパイラのターゲット、configureの基本
それらの件に関しては自分のブログにでも書いていてほしい まあ一応上から目線でコメントしとくと
>>725
libgccの存在に関して勉強不足、>>726の言うとおりdllの種別が2種類ある
DLLにするよりもlibgccだけスタティックリンクしたほうがいいが、libtoolにかませるのが
割と面倒なので一緒に配布したほうが楽、まぜこぜにするとか初心者くさい
>>727
クロスコンパイラとネイティブコンパイラを混同している
>>731
もうネット上で一万回は言及されたであろうCygwinとMinGWのファイルパスについて
述べているが無駄なのでやめてほしい、てか環境を混ぜるな >>737
最後の段落について。
・cygwin版のMinGW ---> ファイル名はUnixライクな /cygdrive/c/xxx/yyy/zzz 形式だが、
出来た実行ファイルはcygwinが無くても動作する。
ユーザー・プログラムからは主にWin32 APIを使う。
・cmd.exe版のMinGW ---> 何もかも Windows 用。ファイル名もDOS式、
出来た実行ファイルは Windows のみで動作。
ユーザー・プログラムからは Win32 API を使う。
・cygwinのgcc ---> cygwin環境で動く実行ファイルを作成する。
ユーザー・プログラムからはUnix系関数を使う。 >>738
スレ違いだ、こっちでやれ
Cygwin + MinGW + GCC 相談室 Part 7
http://peace.2ch.net/test/read.cgi/tech/1357019230/
あとMinGWはcmd.exeではなくminttyから使うべきだ
さっさとネットで資料を探す作業に戻るんだな ちなみに c:\cygwin\bin と c:\cygwin\usr\local\bin にパスを通せば、
cmd.exe からでも cygwin のコマンドが実行できるようになる。
gccもlsもmakeも。ここでbashを起動すればcygwin環境になる。 久しぶりに2ちゃん観に来たら
wxのスレめっちゃ野比てて嬉しい wx のソースを修正したら、wxString() を使った最小サンプルが、
静的リンクしても 70KB で済むようになった。
PATHには、MInGW/bin しか設定せずにテストしているので、wx の DLL
がリンクされている可能性は無く、間違いなくスタンド・アローンの
プログラム。
ちなみに、wx のソースを修正しなければ、451,584 バイトになってしまう。
>>729 に書いたものとほぼ同じプログラムだから。 wxというよりgccとライブラリのお話で伸びている >>742
dllの依存関係すらまともに調べられないのか
dependency walkerとかobjdumpとか使え mingw入ってるならlddコマンドでもいける>依存動的ライブラリ ただ、パス設定を空にして起動できるかどうか見るのも1つの確実な方法。 GUIアプリのサイズ縮小を試みていたが、断念するかも知れない。 △性格が悪い
○無駄が嫌い
◎無駄な事をしてる奴が嫌い >>749
何も悪いことをせず、自分にも害を与えない人を嫌うのが性格が悪いんだよ。 公園の蚊を駆除するのに外側からじゃなくて内側から始めるとかが無駄
自分にも危害が及ぶので嫌 >>749>>750
言われた側が一方的に立場が悪くなるという効能は興味深いと思う
言ったもん勝ちという現象は絶対にあるのだ
>>751
生死にかかわる難しい判断を
「無駄なこと」に無理やりおしこめた詭弁
物事を矮小化させる効果もある >>751
正直言って、今回のこととの関連も分からない。
それ以前に外側から、内側から、ということの意味が全く分からない。
まるで会話ロボットが生成した文書のようだ。
>>752
この文書も意味不明。人間が書いたとは思えない全く理解できない文書だ。 俺の大好きなwxWidgetsスレがめちゃんこ糞スレになって泣きそう 案の定あらし化したか
これ以上触れないで放っとくの推奨 wxWidgets って、GTK をバックエンド(port to)に使うことも出来るらしい
ね(wxGTK)。
上位のツールキットが、下位のツールキットに被さっているってことか。
X11 を直接バックエンドに使うのともまた違うのかな? \ ヽ | / /
\ ヽ / /
‐、、 殺 伐 と し た ス レ に 鳥 取 県 が ! ! _,,−''
`−、、 __/\ _,,−''
`−、、 _| `〜┐ _,,−''
_ノ ∫
_,.〜’ /
───────‐ ,「~ ノ ───────‐
,/ ` ̄7
| 島 根 県 /
_,,−' ~`⌒^7 / `−、、
_,,−'' 丿 \, `−、、
,'´\ / _7 /`⌒ーへ_,._⊃ /`i
! \ _,,-┐ \ _,.,ノ r‐-、、 / !
゙、 `ー--<´ / L. ,〜’ ゙、 >−一'′ ,'
y' U `ヽ/ / ヽ ヽ '´ U イ
____
/ __ | \____\
___/__ / ̄ ____|____ \ \____\
//ヽ /___ /|\ \ \____\
/ / ヽ / /__ / | \ \_______
/ / / / / / | \ | \
/ / / / _/ __/ | \__ | \  ̄―_ >>756
X11は組み込み向けのportなので一般的には使われないよ(メンテされてるかもよくわからん)
Linuxでの使用の際はGTKベースと思っていた方がいい
つまりwxWidgetsのクラスやメソッドでコードを書いてLinux上でビルドするとGTKアプリができる
最近はwxQtというwxWidgetsからQtをバンドルするイカれたプロジェクトが本流にマージされたようだが… >>759
目的は、Qtベースのデスクトップ(KDE)でもwxWidgetsアプリを使うためとか
(→まあKDE上でGNOMEアプリを使うツールもあった気がするのだが…)
あとQtをバンドルすることでAndroid対応も果たしていた(実用性は不明) wxWidgetsで、POPUP Menu (Windows では、Context Menu が正式名称かも)を作る場合、
どうしてますか?
特に、CodeBlocksなどのIDEで行う場合の最良の作法が知りたいです。
自分は、基本的な wxSmith の使い方が分かったところです。 MenuItem作って
SubMenu作って
AddItem >>762
それは手作業の場合ですよね。
そこの部分は対した手間ではないですが、
イベント・ハンドラを*.cpp, *.h, EVENT_TABLEの全てに書くのが面倒で。 >>764
これ、今ちょうど数秒前に見終わったところだった。
これ見てると、
1. wxSmithでwxFormをエディット中に、「MenuBar」ではなく「Menu」ボタンを押して
「要素」を追加する。
そうするとwxSmithの上辺に要素のアイコンが並んでいる末尾に新しいアイコンが追加される。
2. 追加したMenu要素に名前を付ける。
3. wxFormの中に既に配置してあったwxPanelに対して、マウス右UPイベントに対応するハンドラを追加する。
4. そのハンドラの中に、手作業で PopupMenu()関数の関数呼び出しを書き、
その引数に2.でMenuに付けおいた名前を書く。
こここまでは大した手間じゃない。
その後が問題で、EVENT_TABLE の「自動的にwxSmith が作成する範囲」の外側(直後)に、
POPUP MENUのMENU項目数分だけ、手作業で Connect() 関数を書いている。メニュー項目が7個だと、
Connect()関数も7個書く。それぞれ、MENU項目に付けた ID_xxxx の値と、対応する自前の
イベント・ハンドラの関数名を引数に指定して。
最後の部分が知りたかった事で、POPUP MENUの作り方としてはかなり面倒な方法に属する。 7個のメニュー項目にイベント結びつけるのに7行コード書くのって、そんな突出して面倒か? >>767
それは、「EVENT_TABLE」の箇所だけの話で、実際は、*.h に
メンバ関数宣言を7つ書き、*.cpp に
Zzzz Ccccc::OnXxxxx( Yyyy *pYyyy )
{
return Qqqqq;
}
みたいなの(4行)を 7 つ書く必要がある。
少なくとも (1+1+4)*7 = 42 行だ。 なんで今更wxSmithなんだよ古臭いな
なんでイベントテーブル使ってんだよ古臭いな
黙ってwxFormBuilder使ってみろよメッチャ簡単で笑えるぞ >>770
IDEとの組み合わせは?
IDEがサポートしていなくてもいけるんだろうか? >>771
ちんまい個人用ツールしか作った事が無いから大規模プログラムでどうなるかは分からんが、
俺はwxFormBuilderでGUIデザインし、VisualStudioでコード書いてる。
GUI部品を追加したくなったら、いつでも追加編集できる。
もちろんイベント追加も問題ない。
VSでコード書きつつGUIエディットしても、VSにフォーカスを移したら勝手に読み込み直してくれる。
今まで書いたコードがGUI生成時に消去される事も無い。
これにはちょっと条件があるけどな。 >>772
POPUP MENU を作る時、EVENT_TABLE を使わずに何か良い方法で
やってくれるのかな? wxFormBuilderかあ
もはやクロスプラットフォームでGUIがGUIでデザインできるのか(しかもフリーソフトウェア) VSは、外部エディタでソースを編集した場合、VSに戻ると自動的に再ロード
してくれる機能がある事は知ってる。これは昔からある機能。 >>773
凝りに凝ったメニューは知らんが、ポップアップメニューの作成および
メニュークリック時のイベント生成なんかは全部wxFormBuilder上で出来る。
従来のイベントテーブルでも生成してくれるし、Connect関数を使ったイベント生成も出来る。
今はConnectも古くてBindがトレンドらしいが、詳しくは知らない。
http://www.dotup.org/uploda/www.dotup.org5309542.zip.html
参考までに、wxFormBuilderのみで作ったサンプルコードを添付する。
自分で書いたのはmain.cppとthis->Close();だけ。
VS2013 + wxWidget3.0.1でビルド確認済。 >>776
これは、どうやって作ったの?
生成されたコードも参考にはなるけど、wxFormBuilder上での操作方法が
知りたい。 >>777
説明がめんどくさいから、wxFormBuilderでこの「wxMenuTest.fbp.」を開いて確認してくれ。
あとは適当に触ってれば理解できるだろ。
http://www.dotup.org/uploda/www.dotup.org5310926.zip.html
適当にGUIを作ったらF8キーでメインクラスを生成して、
その後F6キーでサブクラスを生成すればいい。
あとは添付した「main.cpp」みたいなコードを書いてビルドすれば目出度くGUIプログラムの完成だ。 レイアウトやイベントの仕様が
前もって分かって一発で決まるようなものならいいけど
そうでない場合は細かいテクが必要になるんだよなぁ
VB,delphi,VisualStudio他のポトペタとは違って
基本クラスや継承クラスの生成コードは
上書きしちゃってよしなにしてくれないから目視マージが必要になる
で、それならxrcでいっかなとなったりとね
あとは最近のバージョンでは修正されてるかも知らないけど
splitter > panel > sizer > xxx
の深いネストが嫌いだったな
バグだよね >>778
出来れば言葉で説明していただけるととても有難いんだけれども。 >>776
MyProject1MyFrame1.cpp に、
void MyProject1MyFrame1::m_button1OnButtonClick( wxCommandEvent& event )
{
// TODO: Implement m_button1OnButtonClick
this->Close();
}
と類似の行が沢山あるけど、this->Close() 以外は、wxFormBuilder が自動生成したとのことで Ok ?
>>779
>基本クラスや継承クラスの生成コードは
>上書きしちゃってよしなにしてくれないから目視マージが必要になる
>で、それならxrcでいっかなとなったりとね
この辺りとの関連が知りたい。自分で書いたコードが勝手に上書きされて消されてしまうということ? そもそも wxFormBuilder って、人間が書いたコードと「マージ」や「アペンド」する機能は全くなくて、
デザイナのテキスト領域に表示されるコードをコピペして使う程度の事しかできないのかな? xrcはwxFormBuilderだとwxRibbonとかで生成に抜けがあるよね
これ自体はそのうちなおるだろうけど、案外使われてないのかなxrc class MyFrame1 : public wxFrame {・・・};
class MyProject1MyFrame1 : public MyFrame1 {・・・};
となっていて、
http://stackoverflow.com/questions/8255753/how-to-add-personal-code-into-wxformbuilder-generated-class
の
・build your frame/panel in formbuilder
・generate inherited class
・implement your handling code in inherited class
・make changes to form/panel in wxFormbuilder ->
will only affect generated class, not inherited class
の最後の行と矛盾するね。
wxFormBuilder は、MyFrame1 は書き換えるが、それを継承した所の MyProject1MyFrame1 は、最初の
一回しか書き換えない(というよりユーザーが指示しないと生成しない)、ということらしいから。 つまり、>>781 のイベント・ハンドラにおいて、this->Close(); の外側の部分も手作業で
書くしかないのではなかろうか?
そして、対応する *.h ファイルの中に、同じ関数のメンバ関数宣言も手作業で追加するしかないのでは? 実装の中身以外は何一つ手では書かないっていうなら、wxWidgetsは投げ捨てて
QtCreator有するQtか、C++ Builderあたりを使うしかないよ。
wxFormBuilderはIDEじゃないし。 >>786
QtCreator では、それが出来るのかな? >>785
言葉通りに受け取ってくれればいい。
本当に「this->Close();以外書いてない」んだ。
つまり関数実装部は全て自動生成される。
つーか試してくれよ。
これだけ御膳立てしたんだからさ。 >>789
大体、答えが分かった。
つまりあなたは、wxFormBuilder に MyProject1MyFrame1 を生成させて、
this->Close();
を追加したんだ。
そいういうやり方だと、ボタンやメニュー項目を一つ増やす度に、手作業で、また、
this->Close();
を自分で書かなきゃならない。
それが、>>779 の意味だね?
だとすれば、this->Close(); の部分は、実践的には、もっと長くなるのだから、
物凄く面倒で、なおかつ危険が伴う作業になるね。 >>790
>そいういうやり方だと、ボタンやメニュー項目を一つ増やす度に、手作業で、また、
>this->Close();
>を自分で書かなきゃならない。
ここの部分を補足すると、その時に追加したボタンやメニュー項目に対するハンドラだけ
でなく、既に存在していたボタンやメニュー項目に対する全てのハンドラの中身を手作業で
コピーする必要があるということになる。
ボタンやメニュー項目の個数をN とすると、O(N^2) の作業時間が必要になるね。 >>790
> そいういうやり方だと、ボタンやメニュー項目を一つ増やす度に、手作業で、また、
> this->Close();
> を自分で書かなきゃならない。
そこらへんに少しコツがあってな。
自動生成された部分を一切変更しない限りにおいて、
後から機能追加して再度サブクラスを生成した時、以前書いた部分は削除されない。
つまり今回の例では「this->Close();」は消えずに残る。
逆に言えば「// TODO〜」コメントの削除や編集すら許されないという事なんだけどな。
これが守られなかった場合、同名の(空の)関数が別に生成される。
この場合は旧関数から新関数へのコピペおよび旧関数の削除の手間が生じるが、
いずれにせよ一度書いたものが消える事は無い。
ヘッダファイルにおいても同様であり、
//// end generated include と
/** Implementing MyFrame1 */ の間、それと
//// end generated class members 以降の行に書いた内容は削除されない。
安心して機能追加できる。
不安だったら再生成する前にバックアップ取っておけばいい。
問題があるとすれば、コードのインデントが全て消える事。
Eclipse等開発環境のコードフォーマッタで解決するが、3.4.0beta時点では
インデント維持されてた筈なんだ。なんで維持されなくなったんだ?
俺の見落しか仕様かバグか。 なるほど、wxFormBuilderも新規出力(全書き換え)しかできないわけではないという
ことなの?
どうやるのかな? あと、EVENT TABLEが古いと言ってる人がいたけど、Connect()がそれに置き換わっただけ
だからね。使う側から目線では(抽象的な意味では)変わってない。配列で静的に持っているか、
関数で登録するかの違いに過ぎないから。 以下によると、wxSmith には、TOP LEVEL RESOURCE を2つ以上作成する方法が見つからないらしい。
いったん、1つのTOP LEVEL WINDOW を作ると、全てがそのウィンドウの子供になってしまう。
POPUP MENU や、メインウィンドウに付随する1群のダイアログは、作るのが難しいらしい。
それに対して、wxFormBuilderは、2つ以上の TOP LEVEL RESOURCE を作ることが出来る、
と主張している。
http://forums.codeblocks.org/index.php?topic=15742.0
It's one of reasons why I have switched from wxSmith to wxFormBuilder.
I haven't found how can I create more than one "top level" resource in my XRC file using wxSmith.
Once I created a top level window, everything needed to be a child of this window.
Create a set of popup menus? Forget it. Create a set of dialogs along with your main window? Forget it.
wxFormBuilder allows more than one top level resource.
Moreover, wxFormBuilder can create only a XRC file - well, it creates a code, too,
and you can paste parts of the code in your own code.
I am curious what I have missed. I am a "XRC user", too. お前が返信に時間かかってるのは煽るための文言を探してくるためか?
これだけ御膳立てしてやっても自分では一切手を動かす気は無いんだから、
呆れを通り越して笑いすら出てくるわ。俺はお前の保護者じゃねえよ。
英文は読めるみたいだからソフトの使い方が分からない筈があるまいに。
>>793
こんな問いに答える気はもう無い。理由は上記の通りだ。
今まで以上に噛み砕いた説明は俺には出来ないし、
そもそも手を動かしていれば既に理解している筈の内容ばかりだからな。
F8とF6からクラス選んで名前付けてコード生成すら出来ん奴が本当にプログラム書けるのか?
無理しないでVSやMonoでC#あたり使ってればいいんじゃないか?
そっちの方がずっと楽だぞ。
>>794
それ書いたのは俺だが、利用上はそれだけの違いでは済まないという事も
英文読んだなら理解できてるはずだろ。煽るためのネタにはならんぞ。
柔軟性は高いに越した事はなかろうよ。
もちろんその機能が自分にとって役立つかどうかは別問題だ。 >>796
誰も悪気がやってやってるわけじゃない。
あなたが勝手にそう取ってるだけだよ。 >>791
それは難癖だよ
継承側で動的バインドという
他と同じ手法を取ればいいだけの話だから
手間はおんなじだよ
>>792
その癖やコツをつかむのに
試行錯誤したりソースを読み解く必要性があるのが辛いんだよね
正味な話不安で信用ならない
手動目視でDiffるか
PEGでも使って自前で書いたほうが楽 >>799
> ここの部分を補足すると、その時に追加したボタンやメニュー項目に対するハンドラだけ
> でなく、既に存在していたボタンやメニュー項目に対する全てのハンドラの中身を手作業で
> コピーする必要があるということになる。
電卓とか参考になると思うよ >>800
ならないと思う。
全てのボタンを一気に wxFromBuilder で作ってからイベントハンドラの
コードを手作業で書けば問題は表面化しないから。
そうでなくて、実際のプログラミングでは、機能追加のたびにボタンを追加して行く
ような作業が必要となる。
その時に上書きされてしまうかどうかがポイント。 だから「ソフトの様式さえ守っていれば」書いたコードが消去されるような事は無いと何度言えば分かってくれるんだ。
試してないのが丸判りだ。ほんっっっっっっとに口ばっかりだなお前は。
これで悪気が無いというんだから最悪だ。本当に本当に最悪だ。
そもそもwxFormBuilderで生成したイベント部に何十行も書くのか?
保守性考えたら、C++だったら別にクラスや関数作って、そっちに処理ブン投げて終わりじゃないか? >>803
全部自分で試さなきゃならないなら、人に聞く権利がなくなるじゃん。
試すのが時間がかかりすぎるから、誰かが試した結果が文書化されるん
だから。 自分はネット上に調べ物を書くときは自分が試した範囲のことしか書かないよ
妄想の実行結果で文句言ったりしないし、困難があれば自分で突破する 「共助」という概念を知らないの?
「自助」しかしてはならないなら、掲示板の意味がほとんど無くなる。 >>803
>そもそもwxFormBuilderで生成したイベント部に何十行も書くのか?
>保守性考えたら、C++だったら別にクラスや関数作って、そっちに処理ブン投げて終わりじゃないか?
これは駄目。
なぜなら、また、*.cpp と *.h に決まりきったコードを書く必要が出てくる
から。イベントハンドラ 1 つずつにこれを書く作業が大きなロスを
生む。 >>804
共助?お前だけは言っちゃいかん言葉だ。
1から100まで他人に聞いてばっかじゃんかお前。
お前がスレの閲覧者に対して何か有益な事一つでも書いたか?
ぜ〜〜〜〜〜んぶ愚痴もしくは煽りじゃんか。
全部自分で試さなきゃいけないとか言ってるがよ。
そもそもお前、俺の言った事何一つ聞く気が無いだろ?
徹頭徹尾お前はコードが消える前提でしか話してない。
信じてるなら未だにコードが消えるなんて言ったりする筈が無いからな。
書かれた事を信じず、そのくせ試す気も無い奴が共に助け合う?笑わせんな。
あと、決まりきったコードを書く必要が出てきてはダメな理由がまるで分からん。
そもそも一度書いたら終わりなのに、なんでロスなんだ?
具体例をサンプルコードで挙げてくれないか。
共助とか抜かしてるんだから勿論やってくれるよな? >>809
あんたが作ってるプログラムとは規模が違うからだよ。 てか決まりきったコードを減らすためのテンプレート?
そのためのメタプログラミングでしょ >>809
中段、あんたの言っていることはある程度は分かるんだよ。
でも、wxSmith の方が遥かにドキュメントが充実している上に、
CodeBlocks に統合されており、元々の設計からしてwxFormBuilderの
ような勝手な新規上書き仕様にはなってない。
wxSmithではマージやアペンドは当たり前なんだよ。その上で、
POPUP MENU だけは、作り方が分かたなかったから詳しい人に
聞いてみたかったんだ。質問する側が、答える側の言っていることを
全部試すなんて期待すべきじゃないぞ。 なんちゅうか、wxSmithは古いと勝手に決め付けて、wxFormBuilder
の方がいいという主張なんだから、どう良いかはあんたが説明すべき
でこっちに試せと言うのはお門違いなんだよ。
そもそもドキュメントが少なすぎる。試すしかないないなんて、
原始人レベルじゃないか。仕様は紙に書くのが基本だが、wxSmithの
場合は動画も多いからまだいいんだよ。wxFormBuilderなんて駄目
なんじゃないのか。進めている海外サイトもあるが、開発者本人が
書いているだけかも知れんから、信用すべきじゃない。 wxFormBuilderがどう良いかはもう書いた。お前が理解しようとしてないだけだ。
あとはお前が試すだけなんだが、自分が知らない新しい技術を試す気が無い
臆病者には永久に理解する事は無理。だからもう何もやらなくていい。お前を諭す事は諦めた。
まだ「勝手な新規上書き」とか言ってるしな。しないって何度言わせるんだか。
なんで理解しようとしないんだ。正規のドキュメントじゃないからか。
同じ事を書いてる奴が俺以外にいないからか。
それとも2chの落書きは信用ならんと?だったらなぜここで質問なんかしたんだ。
wxSmithだろうが何だろうが2chの書き込みって時点で信用度は同じだろう。
なんのかんのグダグダ言っても、結局wxSmithに関する事以外は試す気が一切無いという事も良くわかった。
もうお前が俺を論破して俺が尻尾巻いて退散したって事でいいや。相手するのがバカらしくなった。
所詮お前はマニュアルがブ厚いだけで満足する好奇心の無い老害だって事もわかったし。
ついでに口だけプログラマで、ちょっとしたサンプルコードも書けない無能だって事もね。
「馬鹿には無理」
いい台詞だわ。今頃になってつくづく思うよ。 >>816
質問者に対して試さないから無能だなんて、なんて性格悪いの。 だよな。ゆとり世代がメインストリームのご時世に
再質問する前に手を動かすなんて面倒なことしてくれるなんてかんがえるほうが愚か 感情や思考を産み出しているのはあなた自身
怒るか怒らないかを決めるのもあなた自身 mingw32でwxWidgets作ったら、それを使って作ったプログラムがwinspool.dllがないって怒られるんだよね。
ググったらlibwinspool.aのwinspool.dllをwinspool.drvにバイナリエディタで書き換えたら桶みたいなのがあって試したら動きやがんのな。
まあ、自分のパス通している所にwinspool.drvをwinspool.dll名義で置く方が安全かもしれんが。 >>821
今ならmsys2のpacman使えばwxWidgetsのバイナリがすぐ手に入る
自前ビルドはライブラリのデバッグするのでもないかぎり不要やで 自分でコンフィグ(config.h)いじってライセンスに問題ありそうなregexや必要ないコンポーネント除去したり
必要なものだけ自分のプロジェクトに含めて一緒にコンパイルしたほうが小さくなるし最適化よく効いていいで trunkのgcc5をビルドした
"これまでのgccでビルドしたwxライブラリ"はgcc5じゃ使えなくなるっぽい
自前ビルドのwxライブラリが"再配置が必要"とか言われて使えなかった
gccを4.9.2に変えたらビルド出来た
fltkも同じで、gcc5でfltkのライブラリ作り直したらビルド出来た
が、gcc5でビルドしたライブラリをgcc4.9で使うとビルド出来ない
ひょっとするとgcc5になるとほとんどのc++ライブラリ(特にguiのヤツ)はビルドし直しになるかもしれん
ググったらABIの仕様が変わるって書いてあるけどそのせいかしら メジャーバージョン上がっちゃうとAPIレベルで変わっちゃうからしゃーないね
たぶんlibcとかglibとかも同じじゃないかな wxWidgetsいじってみたいのだが、基本ビルドしないのでwin環境でビルドの最に必要になってくるライブラリ列挙していただける方居ませんか? とりあえずpacman -S mingw-w64-x86_64-wxWidgetsしたんだがこの後どうすればいいんだ えっバイナリあるからそれ使っちゃえって思ったんだけどもしかして自前ビルドの方がいい? なにこの右斜め上に返事したら左斜めに質問が来た感じ 導入さえ乗り越えれば後はサンプルみればどうにかなるしな 情報が少ないって事は記事書けばアクセス数稼ぐチャンスだと思いな wxWidgetsはマジ糞だな、MFCの方が全然イイ >>846
多分出来ないと思うけど、一体何がしたくてそんなことを思いついたの? wxRichToolTipってwxToolTipのサブクラスじゃないのか…
マウスカーソルがしばらく置かれたら表示ってしたいときは、自分で全部動きを用意するしかないのかな wxInputFileStream使ったらゲロ遅でワロタ wxpythonでボタンをクリックしたら別のpyに書いたウィンドウを表示させているのですが、開いたpyウィンドウを閉じるともとのボタンをクリックしても再実行されません。
importは一度だけというのはわかっているのですが・・・
どのような記述をすれば閉じても何度でも再実行できるようになるのでしょうか。
教えて下さい。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
M8KJ6 これの文字コード変換ツール(UTF8とwchar)バグってない? wxPythonのDataViewCtrlでValueChanged()呼んだ後のソート結果がおかしい(ソートが途中で終わってる)ことがあるんだがなんでやろ。
ValueChanged()で指定したオブジェクトがその後のDataViewModel.Compare()でなぜか引数のitem2の方に入ってるときはそうなる。
助けて… https://pastebin.com/49kBvu8t
https://github.com/wxWidgets/Phoenix/
にパッチ当てて
demo/DVC_DataViewModel.py を実行してAcquired列でソートしてみてください
こちらの環境はPython 3.7.3@windows10、wxPython 4.1.0 ViewクラスにXRCファイルからwXWidgetsのコントールを読み込む処理を作成しました
ViewクラスはViewModelクラスのポインタを持っていて、ViewModelクラスで
何かデータが変化した時に、Viewクラスのコントロールを更新したいのですが、
どのように実現すればいいか、ご存じの方は教えていただけないでしょうか? wxwidgetsのGUIスレッドでstd::threadを立ち上げたらアプリがabortしましたけど、
wxThreadを使わないといけないのでしょうか? 少なくとも日本人にとっては、
日本語の良い解説が無いからじゃないか? Qtよりはマイナーかな
個人的にはQtよりも好きだけどね 「日本語の良い解説がないから使えない」が本当だったら、
ヘタレすぎないか? いやだってさ、日本人なら出来ることにそこまで違いがなく、日本語リファレンスがある方とない方があるなら、
ある方に流れるでしょやっぱり
で、Qtにはあるし、JAVAや.NETにもある 今wxwidgetsを学びつつGUI版のマインスイーパ作ろうとしてるけど
肝心のマスを表示する部分とマウス操作をどうするのか決まりそうにない >>877
ああ、3.1.5 は開発版だからまだ各種言語用のバインディングが無いんですね 日本語情報少ないから(日本では)利用者少ない
っていう程度の話ならちょうど良い馬鹿除けフィルタになってると思うが Code::Blocksでウィジェットの編集が不安定じゃね?
プロパティ弄っただけで落ちてしまうんで初心者には辛い
なるべくコード側で設定しろというwxWidgets神からのお告げか? wxFormBuilderの方が安定しているやろか? GUIな開発系の支援ツールを作ると仮定して
・wxWigets
省リソースで起動も速いくほぼ何でも出来るが特に今基準だとお手軽とは言い難い
・Webアプリ
お手軽で起動速度の心配もないがファイルの読み書きが出来なかったりデータを保存できなかったり制限が多い
・Node.js系
ストレージとメモリ消費が多い上に起動が遅い
・Tk/Tcl系
省機能版wxWigets。メリット、デメリットもほぼ同じだが更にレガシー
・HTA
Windowsならかなり理想的だったけど今基準だと時代遅れ感が・・・
なかなか良さそうなのがない・・・ 今のC++は昔のC++と比べると使いやすくなっているし、
wxWidgetsもMFCと比べたら作りやすいから問題ない
こんなソフトが無料で使えるなんて有難いわ wxLua(しかもLuaJITサポート)なんてのがあるらしい。動くなら良さそうかも?
wxRubyは死んでしまったからなぁ・・・
>>885
C++は今のご時世にメモリ不安全な時点でお手軽からはほど遠い感 wxWidgets の Rust 版があれば最強か wxRust ? 今まで食わず嫌いして使わなかったが、意外と使い易いぞ
日本でももっと普及しないかなぁ qiitaで情報集めようと思ったら僅か13件しかヒットしなかったんですが・・・ そもそも、Qiitaで情報を集めること自体が無意味。 公式のドキュメントとサンプルでけっこう何とかなるよ 小規模のソフトなら、わざわざ高価な開発ソフト用意しなくても
wxWidgets で十分だよな
慣れは必要だが、それはどんな開発ソフトでも同じ事だし 個人的に、QtよりもwxWidgetsのほうが好み。 Bindを使う時どういう場面だとwinidだのlastidだのを指定する必要があるのかまじで訳分からん >>895
ほんそれ
>>896
必要最小限でいいんじゃね
基本付けない方が楽 windowやframeに対してBind()するのか
control.Bind()するのか
どっちが良いの? >>898
どちらが推奨されているのかは分からないが、
俺だったら、controlのイベントは、control.Bind()を使うな 別クラスでもキャプチャしてるラムダをさっとbindできる楽でいい Qt5.15LTSの商用版を1年後にオープンソースにするという約束だったが、
それはきちんと守られた様だ・・・ 3.1.6は最後の3.1.x系列で次は3.2らしいけど次は一年後ぐらいかな? なんだかんだで、
wxWidgetsでGUI開発するのが一番保守ができるわw 以前試した時、デザイナがメニュー項目やアイコンボタン的なものだけはあるが、
押してみると機能しないものが多かった。
また、チュートリアル通りと全く同じ順番で全く同じ操作した場合には
動作するが、ちょっとでも違うと動作しなかった。
それから、サイザーで箱的なものを最初に作ったとき、箱が小さすぎて
分かりにくかった。 Code::Blocks使ってみたら、
最初、フレームにいきなりサイザーを置いたら物凄く小さくなってびっくり
どうやってこれにウィジェット配置するんやと・・・
しかし、いろいろ試していたら、先にパネルを配置してそれからサイザーを
配置すれば小さくならないことが分かった そういえば、まだCode::Blocksが3.2.0に対応していないのか? https://zero-cheese.com/6667/
(本記事略)
雑談
世間では、「(略)」が流行している中、wxPythonが作る「PC用ネイティブアプリ」は、取り残されている感あります。そう思うのは、私だけでしょうか?
現代の「ネットとスマホの時代」、PC用ネイティブアプリの開発は、優先度は低いように感じてしまいます。
なぜなら、Webアプリや、スマホアプリで、ほとんどが代用できるからだと、思われます。(スプレッドシート等がいい例です。)
私自身、本記事のために、久しぶりに「PC用ネイティブアプリ作り」のためのコードを書いてみました。すごく懐かしい感じを覚えました。
(もちろん業界により、違いはあると思います。日々、PC用ネイティブアプリを開発されている方々には、不快な思いをさせたかもしれません。その際は、お詫びいたします。)
思い返せば、Windowが95 とか 98 の時代は、Visual C++、Visual Basicが流行っており、PC用ネイティブアプリを作るのが当たり前でした。
(当時、まだ学生でしたが、「VIsual Basic」を買うのに(確か5万円位)、とても苦労した記憶が・・ それが今や無料版があります。)
その時代をインターネットが、流れを変えてしまいました。ご存じの通り、技術の成長速度は、年々早まっています。
本記事は2022年3月時点に書いていますが、今後の20年は、過去120年分の技術進歩に相当すると、予測している研究者もいます。(技術の成長曲線に対し、外挿が当てはまると、その通りになるとの事。)
その時代にあって、PC用ネイティブアプリを作るニーズは、将来、あまり明るくないかもしれません。
既にBlenderみたいなソフトも、Steamを使って遠隔操作できるので、今後5G、6Gが普及してくと、ますますPC用ネイティブアプリの開発ニーズが、減少していきそうです。
(Blenderや、Steam自体が、PC用ネイティブアプリじゃん! というツッコミが入りそうですが(笑)。 ただ、既に遠隔で操作できるという事から、今後、Webアプリに置き換わっていくかな? と思った次第です。)
(以下略) wxPython/wxWidgetsのAndroid/iOS版でええやん >>915
ウィザードスクリプト弄ればwxWidgets 3.2系に対応出来るようになってたのね ソースはsrcフォルダにまとめようとおもってウィザードスクリプト変更したら、
なんかイベントハンドラが一発で登録できんようになった。
再度、定義されたハンドラを指定するとなぜか登録できるが、なんかめんどくさい。
念のため、プロジェクトファイルと同じ階層に保存するように戻したら直った。
もしかして、Code::Blocksっていうか、wxSmithプラグインって
プロジェクトファイルと同じ階層に.cpp.hを入れないと正常に動作しないのやろか? うーん、wxTextCtrlのインスタンスを複数作っただけで終了時に落ちてしまう
どうやらバグらしいね
せっかく3.2出たから試していたが、やっぱまだ不安定か・・・
(自分で直せればいいんだけど、さっぱり分からんw) >>921
自分の環境だけじゃなくて、他でも再現しているような話が出てるってこと? >>921
> どうやらバグらしいね
なぜバグと判断できる?
具体的にGitHub IssueかPRの何番かに上がっているの? どうやら、TDM-GCC 10.3 (64bit のみ?) でビルドするとダメみたい
(MSVC や MSYS2 上の gcc では発生していないらしい)
一応対策済みファイルは上がっているけど、
根本的な原因が分かっているわけではない模様...
(TDM-GCC の libstdc++ に問題があるかもしれないとのこと) すまん、Issue 番号書き忘れたわ
Issue #22639 PR 番号も見つけたので上げておきますわ
PR #22641 実際に確認するの遅れたが、
関連するファイルを更新してビルドし直したら、tdm-gccでも普通に動作しましたわ
問題を修正してくださった開発者の方々に感謝します change log見ると#22639も修正されてんね (^-^)y- (^o^)y-。o0○ ( ;゜゜)ノ⌒-~ ←……( ̄ー|柱| ポイステキンシ フリーのGUIフレームワーク最後の希望
3.2.3が来たよーーーっ! 3.2.3に更新したついでにcode::blocksの夜間ビルド試してみようと思ったらサーバダウンしてるやんけ!!! >>935
そうであれば、多言語にbindingしたらええがな これええな
mingw-w64-i686-wxwidgets3.2でCP932って使えないん? msvc 使うなら CP932 でも大丈夫だと思うけど
gcc 使うなら素直に UTF-8 を使った方が良いんじゃね もういい加減、WindowsはCP932を廃止せなあかんわ
いつまで、「ワールドワイド言語サポートでUnicode UTF-8を使用」を標準でonにしないのか 以前から思っていたのですが
5chではなんでみんな似非関西弁使うねん!
(あかん、俺にも伝染しとるわ・・・) なんでも実況板で似非関西弁で書き込むのが習慣になったから なるほどそういうことだったんですね。ありがとう
次回は、なぜ実況版で似非関西弁で書き込むのが習慣になったのかの謎に迫る! Code::Blocks 20.03が古過ぎるためかスミス氏の機嫌が悪い
試しに夜版バイナリを使ってみたらこっちはご機嫌やった
32bit版のバイナリが無かったけどこっちは自前でビルドしてみた
公式のドキュメント通りにやっても上手くいかなかったけど
エラーの内容を検索しながらやったらポンコツの俺でも出来たわ(涙目) マイルストーンを見たら3.3.0と3.3.99があったんだけど違いはなんやねん! >>944
一般的には
3.3.0 Release
3.3.1 Release ... バグ修正
...
3.3.99 3.3系で取り敢えず入れたい直したいごった煮
3.4 中機能改変
4 大機能改変
ブランチタグやIssueが、管理しやすくなるでしょ? >>945
ありがとうございます
バージョン管理ソフトを使用したことないから良く分からないけど
何らかの意図があってやってるんですね >>946
バージョン管理「ソフト」の話じゃないでしょ、
バージョン管理の話だよ レス数が900を超えています。1000を超えると表示できなくなるよ。