【GUI】wxWidgets(旧wxWindows) その5【サイザー】
レス数が900を超えています。1000を超えると表示できなくなるよ。
ググったら>>64がヒットした。
x64のgcc4.7以降でソースからコンパイルすると途中でcc1plusが止まった
x64のvc9じゃ止まらない。更新途絶えてるから修正期待するのは無理か >>64
>>542
共有ライブラリもしくはモノリシックライブラリをビルドする場合、公式のMinGWだとメモリを使い果たしてしまう
TDM-GCCに切り替えた上で CXXFLAGS='-fno-keep-inline-dllexport' を付けて configure実行するよろし
これはwxWidegts側のバグと言うよりもMinGWのバグだ >>543
あらゆるオプションくっつけてもダメだった
FLTKはvcでもgccでも問題なかったんだけどな、これgccじゃなくてmingw側の問題なのか wxWidgetsってVisualStudio2012で動く? >>545
普通にVS2012でビルドして使ってるよ 昨晩発見、mingw-w64-dgnってトコのパッチ当てたらx64MinGWでもビルド出来た。
gccはTDM4.7.1、時間が無いのでconfigureのオプションくっつけて無いけど一発で通った
具体的には、textentry.cppの#include <shlguid.h>を削除するだけ ハードディスクのMBR領域をバックアップしたいんだけど
どうやってプログラム書いたらいいかな
Linuxのときは/dev/sdaを開いて読むだけだったけど
Windowsとコード一緒にできない wxPythonなんですがベジエ曲線を書くにはどうすれば良いですか? Latest Development Release: 2.9.4
Current Stable Release: 2.8.12
Previous Stable Release: 2.6.4
http://www.codeproject.com/Articles/11515/Introduction-to-wxWidgets Mac OSX LionだとwxWidgets 2.8 がビルドできない・・・
wxWidgets 2.9ビルドするとダイナミックリンクライブラリが一部作成されない・・・
Mac PortのwxWidgets-devをダウンロード するのが一番良さげ
あとMac OSXでpthreadをバイナリにリンクさせたらいきなり実行ファイルが落ちやがる
罠多すぎだろあのOS ttp://www.HackInt0sH.org/ wxWidgets-2.9.5では>>429で言ってたバグが直ってるぞ、やったぜ みなさんお世話になりました
明日で2ch終了らしいので
今のうちに最後のご挨拶をしておきます wxWidgetsのコミッタのVadim ZeitlinがC++11でwxWidgets書いてるぞ
wxWidgets and C++ 11
http://wxwidgets.blogspot.com/2013/08/wxwidgets-and-c-11.html >>566
昔から何度も提唱されてるブラウザによる全てのGUIの描画ですか
Googleは達成できるか mozillaに出来なくともgoogleになら出来る >>572
どうしてるんだろうな
そのプロジェクト... 3もRC2まで行ってるし、次は今月中に正式版出るかな 出たとしたらLinuxのパッケージにwx-3.0が出て使えるようになる
楽しみ おいおい3.0だぞ?出たんだぞ?なんでこんなに盛り上がんないんだよ… メインの機能追加がUnicode対応だからなぁ
今までも別に日本語使えなかったわけではないし 何言ってだこいつ
unicodeは前から使えてるっての
所感
・Mac向けビルドの安定化
・wxwebviewが全ポートで使える
→ ネットワーク接続して、html, Javascriptの解釈可能に
・aui系のバグ修正と見た目の品質向上
・c++11, clang対応
・その他即死系のバグ修正
間違ってたらすまん
とりあえず2.9で出てたバグは直ってるはず あと>>364で出てたUTF-8以外の文字列からの変換とかどうなったんだろ
うまく変換できてるなら嬉しいけど
その他にもクラスは2.8の時より増加してるよね MinGW gcc + wxWidgets 2.8.12で作っていたプログラムを3.0.0で作り直したら、
ウィンドウリサイズ時のwxStaticText、wxCheckBox、wxListBoxのフリッカーが見るに耐えんレベルになった。
かと言ってSetDoubleBufferを使うとリサイズがモタつく上に、何故かwxRadioBoxの枠線が消えるんだよなー。
仕方ない、一つ一つwxEVT_ERASE_BACKGROUNDを潰す作業を初めるか…。 gcc4.8で動くなら使う
x86_64-w64-mingw32じゃ、2.9はとうとうビルドさえ無理だった 4.8だとやっぱりcc1plusが停止した、しかも2.9と同じファイル
公式から落としてきたライブラリ使ってもリンクに失敗
4.7ならライブラリのビルドもリンクも問題なし あ、やっぱ出来た
パラレル無しでビルドするか>>543の
CXXFLAGS='-fno-keep-inline-dllexport'
をつけると大丈夫みたい、後者だと1度止まるけど再ビルドすれば通るしサンプルもビルド出来た 連投失礼、>>584-585は見なかった事にしてね
当方の環境、win7 64bit msys上からビルド、gccは4.9、静的リンクでビルド
configureにCXXFLAGS="-fno-keep-inline-dllexport"をつけてもevent.cppで止まる
その時あらためてmake CXXFLAGS="-fno-keep-inline-dllexport"としてビルドすると通る
gcc4.8だと2.9はビルドでこけるしリンクも失敗するってのは国内外でよく見かけたし、実際俺も
あきらめてたけど…ひょっとして2.9もこの方法で通ったのかなあ。
でも、なぜかサンプルのimage.exeだけ強制終了した(ビルドは可能) constexprも使えないコンパイラは要らないんですよ メタプログラミングって奴でしょ?
何が何だかサッパリ分からないよー。
つまり俺にはまだ早い代物だという事は承知してるが、
どういう用途で使うものなのか教えてほしい。 GCC3xの頃はvc++の方が速かった気がするけど、4.6から急激に速度が向上した気がする
あくまで自作プログラムでの話だけどね
ただ、gccでビルドされる様々なテストプロブラム見てるとvc++でビルドって安全性って意味
でヤバいんじゃないかって思っちゃうの >>591
実行時の計算オーダーを減らす機能。事前計算機能だね。
コンパイルタイムにできるだけ計算して結果を出しておくことで実行時の計算量を減らす。
ネットの変人がそれでレイトレーシングやったりしてる。
C++14のやつはそれなりに簡単だよ。 >>590はちょっと冗談気味だが
正直VC++はC++とは言えない
C++の機能を最大限活かす/楽しむにはgccやclangを使うべきだと思います
会社でプログラム書けと依頼されたらもしかしてVC++使うかもしれないけど chrome のブックマークバー、 IE のお気に入りバーのようなコントロールクラスを探しています。
全てのアイテムが編集可能でアイコンとテキストが表示されて
そのアイテムの値のテキストを編集できるメニューを作りたいのですが
最適なコントロールクラスはどれか教えてください。
wx.Menu を使おうと思ったのですが、
右クリックやコンテキストメニューのイベントが Bind しても呼び出されず苦戦しています。
wx.ListCtrl を使った場合は右クリックのイベントは受けられるのですが、
左クリックのイベントが wx.EVT_COMMAND_LEFT_CLICK のみで
これは MS Windows のみと書いてあるのでできたら使いたくありません。
これらのイベントについても誤りがあれば教えて欲しいです。
環境は wxPython 2.8-msw-unicode です。
よろしくお願いします。 >>596
理想の実装になるかわからない&C++しかわからないが
wxMenuをそのまま使うのが良いと思います
実装の骨子
・メニューの項目一つ一つにwxWindowID ( enum )を振る
・wxWindowIDはwxCommandEventで起動するようにしておく
・上記のwxCommandEventを処理する関数はenumをswitch文で処理する
・wxCommandEventはEVT_MENU_RANGEで定義しておく(enum値が 1000~1200の場合反応する関数を作るなど)
アイテムを編集可能にするために
・EVT_UPDATE_UIをwxMenuに設定しておき、ユーザーがメニューの項目を触ったら更新を実施
右クリック
・wxのConnectとかBindでwxMouseEventをくっつければいいと思う
-------------------------------------------------------
上記をやろうとすると、ユーザーが設定した項目でループを回して常に更新かける
感じになるんじゃないでしょうか。
wxMenu *menu = new wxMenu;
wxMenu *foo = new wxMenu;
for ( ユーザーが設定した数だけループ ) {
foo->Append(wxID_HOGEHOGE_RANGE + i , wxT("ユーザー設定項目1"));
foo->Connect(); // 右クリックイベントを定義しておく
} >>597 レスありがとうございます。
wxMenu に対して Connect/Bind を試してみたのですが、
クリックイベントは wxEVT_MENU または wxEVT_MENU_RANGE だけが呼び出されました。
LEFT_UP, RIGHT_UP, COMMAND_LEFT_UP, COMMAND_RIGHT_UP, CONTEXT_MENU のイベントを試しましたが、
こちらは EVT_MENU の有無にかかわらず呼び出されませんでした。
試したソースコード : http://codepad.org/S9vtw4yX
wxEVT_MENU の際に右クリックか左クリックかわかれば処理を分岐できるのですが、
wxCommandEvent でクリックしたボタンの情報の取得方法がわかりません。
wxWindow::PopupMenu では wxMenu を参考にして GUI を作り出すようですが、
そこですでにイベントが途絶えているように思えてしまいます。
ウィンドウハンドルも得られないようだし、
ポップアップメニューにイベントを追加することはサポートされていないように感じます。
wx.ListCtrl でも思ったことなのですが、
wx.CommandEvent 系のイベントを使うコントロールクラスでは
wx.MouseEvent 系のイベントは関連付けられないのでしょうか? >>598
う〜ん、メニュー上での右クリックは悲しいことにできなさそうね
[wx-users] Trapping wxMouse events over wxMenus
https://groups.google.com/d/msg/wx-users/xAGPwk-f9Ao/0BGV9JD55L4J
この会話の中で、Vadimさん(wxWidgetsのコミッタ)が無理やでとか言ってる
メニューの項目の中で右クリックするとイベントはメニューのほうに行ってしまう
から、そのイベントをつかむのは無理だと。
で、それはWindowsとGTKのネイティブ実装がそうなっているから。
> Ideally, I would like to be able to left-click and
> right-click WITHOUT the menu disappearing.
This is impossible under the two main platforms: MSW and GTK. Menus grab
the mouse when popped up (down?) and so all mouse events go to them. いや、ちょっと違うか
メニューの右クリックイベントは掴めるけど
その時呼び元のメニューの項目が消えるといってるのか
その解決策としてはwxMenuを使わずに
menuのウィジェットを自分でエミュレートするしかないとのこと >>599-600
ありがとうございました。
wxMenu を流用できないのは残念ですが、
これで踏ん切りがつけたので、 wxListCtrl を使ったものを試そうと思います。
引き続き、wxListCtrl のような wxControl 派生に対して
wxMouseEvent 系のイベントをつける方法を求めていますので
何か参考になることがありましたらよろしくお願いします。 >>601 です。 >>596 について進展したので参考になればと思い報告します。
メニューアイテムの上で右クリックしてポップアップメニューを表示することが可能なクラスが wxPython にありました。
wx.lib.agw.flatmenu がまさにぴったりのクラスでした。
RIGHT_UP のイベントはありませんが、 FlatMenuItem::SetContextMenu(FlatMenu) で >>596 でしたいことが簡単にできます。
自作のために PopupWindow あたりを調べているときに見つけました。
また何かありましたらよろしくお願いします。 サンプルが多すぎて逆にわからないのですが、
ランタイム時にGUIパーツを生成消滅させることって可能ですよね?
例えばユーザが読み込んだファイルによってボタンの数を変化させるなど ありがとうございます
関連するサンプルなどありましたら教えていただけると幸いです そうなんですよね〜でもsample多くてどっから見ればよいか、という感じです
まあできるということがわかればとりあえず見て回ります チュートリアルで最初の方から見ればすぐ出ると思う。 デモ実行してみて自分の欲しい機能と似たものを見つけたら「ソースを見る」をクリック。 すいません、見てるものが違うかもしれないので確認させてください
チュートリアルとは何を指してますか?
デモはdemosフォルダの中にあるプロジェクトですよね?「ソースを見る」とはなんでしょうか? ごめん。
見てるものが違った。
wxPython の方見てた。 wxPythonのDemo見て目星を付けて
wxPythonのソースを参考にwxWidgetsでCソース書くのもあり なるほど
wxPythonでコードを書いたものがC++に直接変換できたりしたら便利ですね
wxGladeみたいに なんか久しぶりにwxスレが伸びてるぞ、新規ユーザー大歓迎
ボタンとかテキストエリアの動的な生成は、wxPanelとかwxSizerを使った簡単なサンプルを作ったら理解できると思う
言葉で説明するよりコード書いたほうがよいけど一応書いとく
例えばボタンを生成・削除しようとする場合
親Panelをparent, 子panelをchildとすると
1. ウィジェットの生成:parentをnewして、必要な分だけchildをnew
child = new wxPanel(parent, …);
...
2. ウィジェットの削除:parent.DestoryChildren();
この関数で子ウィジェットを全部きれいに削除できる
説明の意味がわからなければ、まずは適当なチュートリアルサイトに行くべし
おすすめ
http://zetcode.com/gui/wxwidgets/ >>614
慣れたら直接C++で書けるから多分コンバータは需要無いよ >>615
詳しくありがとうございます
拝見致します
>>616
wxGladeも要りませんかね?
フローはwxGladeで枠を作って機能をC++で書く感じになるのかと どっちも1992年頃にできた。OSSといえども商業的な成功がコミュニティ形成の鍵。
それ以外はGood Oldを懐かしむロートルか宗教的価値観に支えられているだけ。 GUI比較スレってなんだよね・・・
比較的な話ってここで展開してもよいものやら
というかwxWidgetとQtどっちも使ってる人っているのか 世の中のアプリケーションはQtかAwt/Swingが採用される流れ。
直交性ならgtk。サクッと安定したものを書くならtk。
トイプログラムならSDL+OpenGL。生きるとは残酷なことである。 バイナリサイズでかいですな
VC2010でサイズ最適化オプションかけてもHelloWorldで5MB...
これはもうどうしようもない感じ? どうしようもないっす
ベース部分(wxStringとかwxWindowとか)の定義が容量食ってるから?ではないかという疑惑 うーんなるほど
ランタイムで色々判断出来るような設計なんですかねえ そうですねwxWidgetsはRTTIの仕組みが活かされてるみたいなドキュメントはどっかで見た
たぶんwxWidgetsの中核であるwxWindowクラスはそんなんばっかしなんだろう ファイル操作系が異様にやりにくい
wxString dir_name("some directly name");
dir_name.Traverse(some_traverser,wxString(""),flags);
でディレクトリたどりながらファイル抽出できるかなとおもったが
flags = wxDIR_FILES
だとそのディレクトリの中身”のみ”探す
flags = wxDIR_DIRS
だとその下の”全ての”階層のディレクトリを抽出する
wxDIR_DEFAULT
だとその下の”すべての”ファイルを探す
なんでこんな仕様なんだ ああわかった
ディレクトリが見つかった場合のみその下も探す、ということなんだな
するとファイルのみだと当然下なんぞ無いからそれ以下を探すことはなく
ディレクトリのみ、とすると下にもいけるから最下層まで探そうとするわけか
うーん 連投失礼
Traverserクラスを継承してそのOnDir関数の返り値で制御すればいいということでした 浮動小数点を扱えるsliderってデフォルトではなさそうですか? たとえば 0 - 100 を 10 で割ると
0.0 - 10.0 のレンジになります やっぱそんな感じなんすね
最大値最小値現在値ラベル表示が便利だなーとおもったんですが、小数点付きでやろうと思ったら
自分でラベル付けるしかなさそうですね 右側のボタンを押したら左側のパネルを再描写させたい、など
あるイベントから(親でない)ほかのイベントを誘発させたい時ってあると思うのですが
その辺に関する記事てどっかにあります? >>634
そのへんはイベント処理の領域になりますね
wxWiki見るしかない感じ
イメージとしては
Sample::LeftPanelRedraw(wxCommandEvent& event);
というイベント関数のIDがID_LeftPanelRedrawであった場合
そのイベントは
wxCommandEvent e(wxCommandEvent(wxEVT_COMMAND_BUTTON_CLICKED, ID_LeftPanelRedraw));
LeftPanelRedraw(e);
で呼べる glcanvasを使ってパネルを描写し、ドラッグに反応するようにしたのですが
ドラッグ中に、ポインタがパネルの範囲外に出た時に、反応が止まってしまいます
sampleのdragimagではドラッグ中であれば範囲外でもイベントが取れるようですが
sampleのopengl/penguinだと取れないようです
マウスイベントの接続は両者ともEVT_MOUSE_EVENTSで行っているので
何が違って取れているのかわかりません
その辺の事情、どなたかご存知ないですか? わかりました
wxWindowBase::wCaptureMouse()を呼び出すと以降座標とイベントが取得されるようです クロスプラットフォームの開発環境について調べてるんですが、wxWidgetsの
GUIは外観とかは各プラットフォームのものが使われるんですか?それとも
独自のテーマになってしまうんでしょうか? >>641
各プラットフォームのものが使われます
つまりWindowsならWIN32、LinuxならGTK、MacならCocoa
それぞれの外観になります
対してQtやTk、JavaのSwingなどは独自のテーマになります >>642
ありがとうございます。他の環境まで概括してくださるとは助かりました。 >>641
敢えてプラットフォームのを使わず
テーマ選ぶ方法もあったはず いまこのスレ開いたら、>>646にあったはずの有益な書き込みが消えている…
貼っておこう
> 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で止めておいた方が良いかも。 wxWidgetsを使って作られたプログラムの一覧ってあったりするのかね?
とりあえずAudacityは知ってる おーありがとう
後で見て回る
テンプレにあってもいいじゃないかな? wxWidgetsで、フォームを閉じる処理をして実際に閉じるまでの間に発生するイベントとかある?
.NETで言うところのOnClosingみたいな感じで。 Windows で、
CrossBlock + MinGW + wxWidget
で最も簡単な GUI アプリを基本プロジェクトで作成してみたところ、
MyTest.exe のサイズ:736KB
(wxWidgetのDLL) wxmsw28u_gcc_custom.dll のサイズ : 15.9MB
MyTest.exe のメモリ使用量 : 7,732KB // TaskManagerの表示
となった。
この基本アプリは、HelpでAboutでメッセージ・ボックスが表示できる
ようになっているが、メニュー項目をクリックしてから実際にそれが
出るまで数秒かかる。実験したのはそこそこ速いマシンと速いWindows
での事。 ただし、遅いのは最初の一回だけ。
一度でも表示すると後は速い。 Mailer の Thunderbird-Portable なんかもマルチプラットフォーム対応
だけど、起動がかなり遅い。これも巨大な dll を読み込んだりしてる
からかな。
起動やメニュー操作が遅くなるのはマルチプラットフォーム化する代償
として負わされるのかも知れん。
こういうツールキットで軽快なアプリを作るのは難しいのかもな。 小規模の自作ソフトでwxWidgetsをスタティックリンクしない理由が分からん
わざわざ合計バイナリサイズを大きく、速度も遅くする理由がどこにあるのだろう >>661
なるほど、スタティックリンクにすれば、起動後になってからユーザーの
命令に対する応答が遅れる事はなくなるかもしれない。
起動が遅くなるだけで済むんなら、そっちの方がストレスが少ないかも。 ある程度規模が大きくなるとスタティックリンクだと初回起動が遅すぎになので
dllにモジュールを分割してやったほうがいい
起動時のメモリへのロード時間はどうしようもないのでスプラッシュをつけてごまかす CrossBlockでは、monolithic タイプのライブラリをビルドしてから使う
ようになってるんだけど、それも遅い原因なのかな。
でも起動後にユーザー入力に対するレスポンスが遅いのはどう説明すれば
いいんだろう?
普通の Windows の仕様だと原則、起動時に全ての DLL をロードする。
LoadLibrary()を使えば動的にロードすることも可能は可能だけど、
それをする必要は旧OSでサポートしてなかった新OSのDLLをロードする
ような場合は、多言語化のサポートなど。
なるほど、多言語化のせいかも。_("xxx") みたいなのがあったから、
gettext を使ってる。それでリソースを動的ロードしているのか。 何度かアプリ起動しているうちにWindowsのFetchが学習してくれて
DLLとか先読みしてくれるようにならないのだろうか >>665
それはなる。
・ディスクの内容は、メモリにキャッシュされる。
・同じDLLは、全てのアプリで物理メモリが共有されると聞いたことがある。
# >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。
それより、wxWidget 本家のソース配布に入っている samples を
Windows の mingw32 でビルドしてみたところ、全然遅くなかった。
・アプリの起動は速い。
・起動後のメニューコマンドやユーザー入力に対するレスポンスも速い。
・Aboutダイアログも瞬間ではないが、0.3秒程度で、Windows Nativeアプリ
でも、その程度の遅さはある場合があるので遜色ない。
CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
ライブラリを使用しているからか。 >>666
># >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。
なんだと思ったらわりと素人じゃねえかおい
>CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
>ライブラリを使用しているからか。
monolithicってのはwxWidgetsのモジュール全部入りのDLL作るという意味なので遅くて当然
(実際試したことないので遅いというのは初めて知ったが…)
普通は ./configure --prefix=/mingw --enable-shared みたいに指定してビルドするから
モジュールごとに分割されたDLLが作成される
Windows上で開発する時はMinGW + NTEmacs/eclipse CDTの環境がおすすめ >>667
最後の段落:多分、wxWidgets 本体を MInGW32 用のビルドする際は、
configure は使えない気がする。
CodeBlocks のQuickなんたらRefの説明では、いきなり、
make するように支持されていた。しかも、-fno なんたら dll-export
みたいなオプションを付けろと指示。これは、MinGW32のバグで、
付けないと最後のldの段階でldがクラッシュする事をたまたま発見。
ところで話は変わって聞いておきたいのですが、 eclipse では
wxWidget のイベントを書くようなときに
・BEGIN_EVENT_MAP に自動的に一行マクロを挿入してくれて
・*.h にもメンバ関数宣言を書いてくれて
・*.cpp にも5行くらいの関数定義本体の雛形を書いてくれ
たりしますか? つまり、イベント・ハンドラを追加したとき、
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
はありません? 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を超えると表示できなくなるよ。