【GUI】wxWidgets(旧wxWindows) その4【サイザー】

1 名前：デフォルトの名無しさん mailto:sage [2008/06/28(土) 21:49:20 ] クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)についてのスレ。 本家 　www.wxwidgets.org/ wxWindows日本語プロジェクト 　wxwindowsjp.sourceforge.jp/ Let's wxWidgets dot-gray.s33.xrea.com/ wxWindowsで始めるC++ GUIプログラミング www.h3.dion.ne.jp/~k5_n/wxwin/ wxWidgets でクロスプラットフォーム GUIアプリを作ろう 0xcc.net/pub/uu-2004-08/ 267 名前：デフォルトの名無しさん mailto:sage [2008/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 mailto:sage [2008/12/30(火) 18:17:14 ] 今気づいたがぜんぜんwxWidgetsと関係ない話に脱線してるな。ｺﾞﾒﾝﾅｻｲ。 269 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 16:23:30 ] いや、おもしろいよ。どうせ閑古鳥スレだし。 270 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 16:39:20 ] wxWidgets の場合、公式バイナリのような dll が無いので、 dll をほかの wxWidgets アプリと 共有しようとしたら違うconfigやコンパイラでビルドされた dll を使ってしまう可能性があって危険。 (C言語の場合ABIが決まってるけど、C++だとコンパイラのバージョンそろえないと怖い) だから、wxWidgets の dll を system32 とかにぶち込む気にはなれない。 dllを共用できないのであれば、スタティックリンクにした方がいらない関数をリンクから外すとか できるのでサイズが縮む。起動時間もダイナミックリンクがいらない分早くなるはず。 271 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 16:54:07 ] >>267 単純に疑問なんだけど、リンク形態によってテスト工数が変わる理由がわからないんだが 単純に配布のファイルフォーマットの話じゃないの？ どっちにしろテストは全部しなきゃならんわけで 272 名前：263 mailto:sage [2008/12/31(水) 17:17:47 ] >>267 たしかに、評価工数とかを考えると、フツーにモジュールを別にしますね。 >その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。 ええおかげさまで、ひどい目に遭いましたよ。帰れない日々が・・・。 COM形式なら、最悪IFクラスそのものを切り替えてしまえばいいので それもありですね。 やっぱ、状況しだいなのかな。 273 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 17:40:14 ] >>271 前に、 モジュール（DLL←→EXE）間の、 「構造体メンバのアライメント指定」が不一致が原因でメモリ壊してる バグがあったです。と言うのは関係ないか。 どっちかというと、バイナリとしてのモジュールが違うから、 別の担当者に作業を割り当てることができるから、というのも違うな。 LIBにするのだから、IFでわけるわな。 納品される側から考えたら、DLLでもLIBでも対して違いはないですな。 作る側から考えたら、DLLの概要仕様から作らなきゃならんわけで、 めんどくさいてのはあるかも。 外注に、「DLLの要求仕様を出してないんかい」てのは、なしの方向で。 274 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 17:48:18 ] DLLは基本的に「そうせざるを得ない」場合にしか使わないなぁ 275 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 18:09:06 ] お前ら完全にスレ違いだが いいぞもっとやれ 276 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 18:40:32 ] そもそも、ネタがない・・・。 無理矢理作るか？ 「wxwidgets乗ってたはずのC++Builder X ってどうなったんだ」とか？ これからやろうとしてるのだけど、 MFC製Dialogベースアプリを、 wxWidgetsのMDIの一画面にしてまともに動くのかとか？ 277 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 19:11:49 ] mfcのdllとか危険過ぎる。 278 名前：デフォルトの名無しさん mailto:sage [2008/12/31(水) 23:10:02 ] ちょっと気になった＆連絡。 あけましておめでとうございます。 SVNのVCプロジェクトファイルなんだけど、 今までマルチバイトのはずだった(Debugと、ユニバーサルじゃない方)設定 が全部、Unicodeビルドになってる。。。 2.9に更新する場合は、wxString → char*変換周り、全部直さないとだめぽ。 279 名前：デフォルトの名無しさん mailto:sage [2009/01/01(木) 04:24:51 ] >>278 それ以前に、ASCIIで事足りる文化圏の人間じゃないなら、最初からUnicode使っておけよ。 280 名前：デフォルトの名無しさん mailto:sage [2009/01/01(木) 13:30:08 ] >>278 前スレとかにあったような気がするんだけど、wxWidgetsの3.0からUnicodeに統一されるよ。 詳細は以下のサイトとかが参考になると思う。 ttp://wxwidgets.blogspot.com/2007/11/looking-forward-to-wxwidgets-3.html 281 名前：デフォルトの名無しさん mailto:sage [2009/01/01(木) 20:38:42 ] wxとboostがあればもう何もいらない。 これでSOHO GUIアプリ請負で25歳月収60-70万だぜ。 282 名前：デフォルトの名無しさん mailto:sage [2009/01/02(金) 21:05:10 ] >>281 すごい。SOHOって仕事は自分で営業して取ってくるの？ 283 名前：デフォルトの名無しさん mailto:sage [2009/01/02(金) 23:21:46 ] 発注元の慈悲に過ぎん。あと有能な営業なら同じ仕事でも100万で取ってくる。 284 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 01:49:01 ] マ板ネタになりそうだからこれで最後にするが >>282 もちろんそうよ。ただ、特定の取引先と運良く良いコネが生まれたってのもある。 283のいうとおり、相手の良心に依存してるのはたしかだ。 まだwx自体が知られてなくて、それなりのGUIを作れるわりに オープンでクロスプラットフォームということもあって ある程度安心してガンガン技術習得に時間投資できるから 技術的精度が良かったり小回りが効いたりで客の評価は概ね高い。 285 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 02:17:40 ] webやDB込みだよね？ スタンドアロンなアプリで60ならすごいな 286 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 02:52:57 ] たしかにスキルがあって良いコネがあれば，そんぐらいもらえるかもなあ… 羨しすぎる 287 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 09:25:49 ] 個人は浮き沈みが激しいから最高値だけで語れないし 将来が不安すぐる 俺も学生の時に某大手商社から個人契約でやらないかって言われたけど ２年後くらいにその商社の社員の賞与が全額カットとかで 行ってたら余裕で切られてたはず で、今はニートな訳ですが何か？ 288 名前：282 mailto:sage [2009/01/03(土) 14:16:16 ] >>287 自分も今は無職だよ。 ハローワークとかでも、ちょこちょこMFC使った案件の募集をやってる(自分は面接で落ちてしまうけど)んで、 そのままクロスプラットフォーム対応にしたwxWidgetsもそれなりに需要はあると思う。 ただ、wxWidgetsはAUIとかが今後メンテ・拡張されてくのかちょっと不安。 VS2008SP1のMFCみたいな強力なGUIとか、今後開発されるのかな？ 289 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 15:28:01 ] 無職ならOSSで名を売る作業に戻るんだ けど、OSSから職に繋がったのなんてほとんど聞いたことない 290 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 16:49:55 ] AUIってドッキングインターフェース？ 一般的なアプリでそれほど必須の機能とは思えないけど… ドッキングできる場所が限定されれば自分で書くのもそれほど大変じゃなさそうだし 市販アプリならスキン的にやたらエキセントリックなUIにしたがるからそっちの方をなんとかしたほうが wxWidgetsは何処ぞの組み込み系描画ライブラリ企業からバックアップ受けてるから wxUniversalだのの、コンポーネントを自己描画する方向性ばかりが強まりそう でもSwingでさえLook&Feelはそれほど発展しなかったのに wxUniversalにどれほどの需要と将来性があるか個人的には非常に不明だわ ハロワでMFC案件なんてあるんだ、行ってみようかなぁ 291 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 18:55:11 ] こんなスレまでハロワとかの話題が出てきて 悲しい気分になってきた．． 292 名前：デフォルトの名無しさん mailto:sage [2009/01/03(土) 21:09:04 ] ハロウは楽しかったなあ。俺はあんまり仮装には参加できなかったけどね。 293 名前：282 mailto:sage [2009/01/03(土) 21:22:39 ] >>289 OSSが仕事で出来れば、それに勝る幸せはないかも。 >>290 wxMac(wxCocoa?)はMac持ってないんで良く分からないんだけど、 wxGTKではMDIがノート(タブ)形式になってしまうんで、LinuxでもMDIっぽいことを やろうとすると何だかんだでAUI頼みになりそうな気がする。 wxUniversalは個人的には黒歴史として闇に葬り去られて欲しいんだけど、 wxPythonとかではむしろ積極的に活用されてるのかな？ >>291 ごめん、ハロワとかの暗い話題はこの辺でやめときます。 294 名前：デフォルトの名無しさん mailto:sage [2009/01/12(月) 12:28:27 ] 290みたいな御託だけで何もしなさそうな奴が、無職なのはすごく納得する。 295 名前：デフォルトの名無しさん mailto:sage [2009/01/12(月) 15:59:53 ] wxBlogの方で以下の記事を見かけたんだけど、 日本語に翻訳されたものって何処かにあるのかな？ [wxBlog: Another Year of WX] wxwidgets.blogspot.com/2009/01/another-year-of-wx.html [The Wonderful World of wxWidgets 3.0] svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/docs/publicity/WoWoW30.html?view=co 296 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/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 名前：デフォルトの名無しさん mailto:sage [2009/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 mailto:sage [2009/01/12(月) 19:19:24 ] >>296-299 翻訳超乙。Unicode化の理由と、Graphicsの改善のあたりが良く分かった。 とりあえず、3.0は期待して損はなさそうだね。 301 名前：デフォルトの名無しさん mailto:sage [2009/01/12(月) 21:10:20 ] 一服して若干気を取り直したので続きを投下。 Changes to wxBase （訳注：wxBase自体の紹介は省略） ・wxStringとコンテナクラスには多くの変更がある。 ・wxBaseの一番大きな変更はwx3.0でイベントベースのプログラムを書くための 　イベントループ、タイマー、ソケット等の追加。 ・ソケットのコードは重複部分を削除、C/C++で分かれていたコードをドロップ。 302 名前：デフォルトの名無しさん mailto:sage [2009/01/12(月) 21:10:54 ] New controls and other major GUI additions for all ports 全ての修正とマイナーチェンジを羅列できないので、GUIの変更の概要のみ。 ・柔軟な表現が可能なwxDataViewCtrl/wxDataViewTreeCtrlを実装。wxListCtrl/wxTreeCtrlを一部代替。 ・wxGridの表形式はwxHeaderCtrlに分離したネイティブなヘッダを実装。 ・wxPropertyGridの追加。 　　　名前-値のペアを表現する一般的クラス。 　　　wxDataViewCtrlと同様、数値、テキスト、リスト、フォントなどの 　　　組み込みのエディタ（in-place, ポップアップ、コンボボックス等）を提供する。 ・wxHyperlinkCtrlをGTKでネイティブに、他では一般的方法で実装。 ・ファイルダイアログのカスタマイズのためwxFileCtrlを実装。 ・wxRichTextCtrlに親・子スクリプトのサポートを始め高速化など色々改良。 ・wxTreeCtrlに状態アイコン表示機能追加。チェックボックス的にも使える。 ・wxCalendarCtrlを刷新しMSWとGTK+でネイティブに。その他改良。 ・wxTextCtrlとwxComboBoxでオートコンプリート機能を実装。 ・wxAUIのクラス群にwxAUIToolBarを追加。より柔軟で自然に。 ・wxBitmapComboBoxを再実装、MSWとGTKではネイティブに。 ・wxBitmapToggleButtonを全プラットフォームに。 ・wxStaticTextは全プラットフォームで省略表現をサポート、GTK+でマークアップ書式をサポート。 ・全プラットフォームでwxListBoxの選択イベントの発起方法を書き直し精確にした。 ・GTKとOSXでwxCollapsiblePaneをネイティブ実装。 ・複数行に渡ってwrap可能な新しいsizer、wxWrapSizerを追加。 ・OpenGlキャンバスにマルチサンプル、アンチエイリアスサポート追加。 　wxGLCanvasとwxGLContext分離。 ・wxTopLevelWindowをネイティブウィンドウハンドルから構築するため 　MSWとGTK+にwxNativeContainerWindowを追加。 303 名前：デフォルトの名無しさん mailto:sage [2009/01/12(月) 21:11:29 ] wxMac specific changes (now called wxOSX) ・wxMacという呼称は廃止、wxOSXと呼称、iPhoneとiPodを一部サポート。 ・Carbon, Cocoa, CocoaTouchの3つの一般コードに整理。 ・OSXのCoreFoundationへのラッパでったり一般的なクラスへのラッパだったり。 ・CarbonがwxMacのコアで安定していたが、iPhone対応にCocoa(Touch)が必要で、 　64bitのOSXでは非推奨となるため、現在はCarbonでも今後はCocoaにフォーカス。 ・リストラクチャリングの一貫としてQuickDraw APIを使ったコードは削除。 　今後はCoreGraphicsを使用する。 ・同様にOSX10.4にないCarbonの関数を使用したコードは削除。 　OSX10.4が最低動作環境になる。 ・IconRefのサポート拡充。 ・英語以外のロケールでのメニュー項目の重複を修正。 ・ボタンにアクセラレータが使用可能に。 ・CFLocaleを使用したwxLocal::GetInfo()の実装。 wxGTK specific changes ・GTK+のAPIが後方互換性がなくなって来たためGTK+2.4を最低環境とする。 ・wxToolbarは新しいGTK+のツールバーAPIを使用。 ・wxChoiceはGtkOptionMenuでなくGtkComboBoxを使用。 ・wxComboBoxは非推奨のGtkCombでなく常にGtkComboBoxを使用。 ・URLのドラッグはwxURLDataObjectで"text/x-moz-url"を使用。 ・GtkPrintとCairoのダイアログを使用した新しいプリントバックエンド。 ・アイドルイベントの生成コードを書き直し。 ・タブの走査はGTK+でネイティブに。 ・wxFrameのメニューバー、ツールバー、クライアントウィンドウとステータスバーは 　GtkVBoxを使用したレイアウトに書き直し。 ・ウィンドウマネージャに帰属するウィンドウの装飾に係わらず 　トップレベルウィンドウSetSize()/GetSize()を正しく実装。 ・wxYield()の呼び出しを避ける（リエントラント問題回避）ため 　wxClipboardの非同期APIを追加。 ・Nokiaのタブレットで使われるMaemoプラットフォームの 　Hildonコントロールをいくつかサポート。 304 名前：デフォルトの名無しさん mailto:sage [2009/01/12(月) 21:13:12 ] wxMSW specific changes ・後方互換性が確保されており、ユーザ数が多いため最も安定しており、 　他のプラットフォームに比べ大きな変更はない。 ・wxCheckListBoxがよりネイティブな感じに。 ・長いツールチップが可能に。 ・wxCheckBoxとwxToggleButtonで複数行ラベルをサポート。 ・より正確なプリントプレビュー。 ・サイズ変更可能なダイアログでリサイズグリップを表示。 以上、>>294曰く「御託だけで何もしない無職」の大雑把な訳でした。 305 名前：300 mailto:sage [2009/01/12(月) 23:38:51 ] >>301-304 引き続きサンクス。wxOSXが結構面白そうに思えたんで、Mac Miniの中古でも 買ってみようかな。 あと、御託云々はあんまし気にしなくても良いと思うよ。 それよか、スタティックリンクでソース公開しなくてもいいwxWidgetsを使って 金儲けできると良いんだけど、クロスプラットフォームでお金になりそうなアプリって どんなのだろ？どうにもイメージが沸かない。 306 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 07:22:12 ] ２ちゃんでちょっと煽られたくらいでむきになるようだと 実社会で辛くないか 307 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 07:46:14 ] 翻訳しただけでムキになってるとか決めつけるようだと 実社会ですぐ口論にならないか 308 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 18:05:10 ] まぁ、どう見ても煽られたのが原動力にはなってるがな 309 名前：デフォルトの名無しさん mailto:sage [2009/01/13(火) 18:18:57 ] 翻訳人は無能ではないことを証明したし 英語読めない人は3.0の改善項目がわかったし みんな幸せってことでいいんじゃなかろか 310 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 00:58:01 ] 英語読めるようになりたいな 311 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 01:40:22 ] これからはアラビア語の時代だけれどもね。 312 名前：デフォルトの名無しさん [2009/01/14(水) 13:11:27 ] つまらん、次 313 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 13:56:31 ] これからはアラビアゴムの時代だけれどもね。 314 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 22:09:16 ] MinGWでコンパイルしたwxWidgetsを使って minimal sampleを動かそうとしたんだが 意味不明なタイミングでSIGSEGVが出て起動すらしない ◆gdbのスタックのコピー スレッド [1] (中断中 : シグナル 'SIGSEGV' を受け取りました。説明: Segmentation fault)        9 wxFontMapperBase::Get()  0x0044e816        8 wxFontMapperModule::OnInit()  0x00546e3b       7 wxModule::DoInitializeModule()  0x00478632         6 wxModule::InitializeModules()  0x0047878c      5 wxEntryStart()  0x004bb64a         4 wxEntryReal()  0x004bb879      3 wxEntry()  0x00430e9e      2 WinMain() KirbyClone.cpp:117 0x00401406        1 main()  0x005340d1     ソースコードはほとんどそのままなんだけど、（少なくとも上に載っている関数は触ってない） 原因があるとしたらどこ？ 315 名前：デフォルトの名無しさん mailto:sage [2009/01/14(水) 22:13:06 ] それにしても、今日wxWidgetsの勉強を始めたばかりなんだが、 configureのオプションをいじると恐ろしいほどビルドに失敗するね disable系を何個かつけると高確率でmakeが止まる 316 名前：314 mailto:sage [2009/01/14(水) 22:47:14 ] sample自体をそのままmakeすると成功するみたいだ となると、俺が自力で書いたMakefileが悪いのかな… 317 名前：デフォルトの名無しさん mailto:sage [2009/01/15(木) 10:31:46 ] >>316 MinGW はさわったことがないので山勘ですが。 メモリマップの方法がライブラリと本体で違うとか？ 318 名前：デフォルトの名無しさん mailto:sage [2009/01/15(木) 19:07:46 ] 商用版とGPL版しかなかったQtにLGPL版が出たね。 static linkできないのはちょっとアレだけど、なんかで使ってみてもいいかなー 319 名前：デフォルトの名無しさん mailto:sage [2009/01/15(木) 23:12:46 ] このままじゃ対抗できないからwxもWt（ワット）に改称してキャッチーな感じで攻めようよ。 320 名前：デフォルトの名無しさん mailto:sage [2009/01/16(金) 22:44:34 ] wxWidgetsにスタティックリンクしたプログラムをgdbでデバッグする。 コンパイル時に-gでデバッグ情報をつけるわけだが、 この時にライブラリの方もデバッグバージョンを使わないといけないのか？ なんかリリースバージョンをリンクした状態でデバッグしようとしたら gdbが異常終了するんだが… 321 名前：デフォルトの名無しさん mailto:sage [2009/01/16(金) 23:46:48 ] >>320 俺の環境ではデバッグ無しでビルドしたwxをスタティックリンクしてもgdbは問題なく機能したよ もちろん自分で書いたソースの範囲内でね gcc3.4.5 gdb6.8と、あとは大体新しいやつ 322 名前：デフォルトの名無しさん mailto:sage [2009/01/17(土) 00:16:34 ] >>321 gdbを6.8に変えたらちゃんとエラーメッセージが出るようになった！ んで、開発にEclipse使ってるんだが、「共用ライブラリーシンボルを自動的にロード」 のオプションを外したら何もエラーが出ずにデバッグできるようになった gdbのバージョンが古いと勝手に落ちる、「共有〜」にチェックつけてるとgdbが落ちる、 っていう前例も見つかったわ。 両方とも結構問題になってるみたいだ。 結果的にwxWidgetsは関係なかったな…でも解決したからいいや、ありがとう。 323 名前：220 mailto:sage [2009/01/17(土) 00:26:59 ] すいませんお礼忘れてました汗 レスくださった方々ありがとうございましたｍ(_ _)ｍ 結局ディスクがおかしかったみたいでchdiskで直りました。 ところで・・QTがLGPLで使えるようになるようですね。。 正直乗り換えるかもしれない(爆 324 名前：デフォルトの名無しさん mailto:sage [2009/01/17(土) 00:55:18 ] >>323 いますぐ全部ファイルをバックアップして HDD とりかえたほうがいいと思う ハードディスクは消耗品だからいちど壊れはじめるとはやいよ。 325 名前：デフォルトの名無しさん mailto:sage [2009/01/17(土) 06:58:04 ] 不治痛のHDDは壊れやすい 凍死場に九州されるみたいで不安 326 名前：デフォルトの名無しさん mailto:sage [2009/01/17(土) 15:13:35 ] 挙動が怪しいHDDはマジやばい ファイルシステムが壊れてるだけならいいけど 物理的にエラーがでてて代替セクタとか使い出すと 見た目普通のままコロっと逝く時があるよ 初心者でも使いやすくてHDDの状態が大体わかる CrystalDiskInfoを勧めちゃう 327 名前：デフォルトの名無しさん mailto:sage [2009/01/17(土) 21:07:43 ] >>326 なんで急にオカマ口調なの？ 328 名前：デフォルトの名無しさん mailto:sage [2009/01/17(土) 22:29:44 ] CrystalDiskInfoって確かMFCで作られてるから wxWidgetsでクロスプラットフォーム化するのってそんな手間じゃないのかな。 329 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 01:27:50 ] ここのところ wxpython-usersに Subject: will Qt mean the end of wxPython ? っていうメールがめちゃめちゃ流れててワロタ 330 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 05:56:41 ] APIはQTのほうがすっきりしているからな。 モッサリだけど。 331 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:12:19 ] 少くともQtでOS毎に自然な外観提供できて 複雑なライセンス体系が無くならない限り移行はできないなあ。。 332 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:17:28 ] LGPLになったんだから、ライセンス簡単だろ？ 333 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:36:23 ] >>332 結局商用アプリ作るとかになったら、どうせ金クレクレモードに突入するじゃん。 334 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:45:40 ] LGPLだと無問題だお？ 335 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:53:39 ] >>334 すまん、よく調べたらそうだった。 商用版も継続するってことは結局商用には使用料とるのかと思ってたよ。 こりゃやばいなwx。。 C++でクロスプラットフォームGUIライブラリが充実する って流れは大歓迎だけどね。 336 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 18:56:53 ] wx使う前はイメージﾖｶﾀんだが、IDEが悪いせいかMFCっぽくコントロールに連番ふってて、ダメだこりゃとｵﾓﾀ。 この辺、Qtで解消すんのかなぁ？ 337 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 19:11:28 ] 統合開発環境が簡単にインストールできれば、wxも生き残れるだろうが、 今のところ、qt 優勢。 338 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 19:38:40 ] 俺はEmacs使うからIDEはいらんから、軽いRADツールがあるのが一番かな。 339 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 21:24:28 ] 良RADさえあれば一気に巻き返せそうな気はするんだが 340 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 21:31:41 ] wxのRADって有力なのはDialogBlocksとwxFormBuilderぐらい？ 俺はここ来るまでwxGladeとXRCedしか知らなかった。 ウェブ検索してもこれ以外あんまり引っかからなかったし。 341 名前：デフォルトの名無しさん mailto:sage [2009/01/19(月) 23:39:01 ] あー，そういえば最新のDialogBlocks(4.29)で プロジェクト開ける人いる？ linuxで引数としてプロジェクトを指定すると can't open /hoge/moge/"hage.pjd" 的な事を言われる． ダブルクォーテーションのせいかしら． 342 名前：デフォルトの名無しさん mailto:sage [2009/01/20(火) 07:37:07 ] IDEとしての方が意味が大きいけどCode::Blocksも入るんじゃない？ ただし作業自体はRAD的でもXRCじゃなくコードが挿入される形だけどね あのコード見るとJavaでGUI作るときの苦々しさを思い出す・・・ 343 名前：デフォルトの名無しさん mailto:sage [2009/01/21(水) 03:00:39 ] code::blocksはQtのプロジェクトも組める。あれでRADに dialogblocks程度の操作性があれば良かったんだけど。 吐くソースはcode::blocks(wxSmith?)の方が親切な気がするし。 344 名前：デフォルトの名無しさん mailto:sage [2009/01/21(水) 08:45:41 ] ＞code::blocks 操作感が気に入らないﾟ�听 wx-devcppの操作感が好き。 吐き出すコードは？だけど。 345 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 03:48:17 ] >>344 wxSmithが我慢出来ない人はwxFormBuilder使うといいよ。 イベントもconnectとEVENT_TABLE選べるみたいだし、 とりあえずSizerの領域を均等に割り振る様な事もない。 wxGlade、DialogBlocks、wxSmith、wxFormBuilderと触ってみたけど、 操作性はDialogBlocks、ソースはwxSmithがいいと思った。 ソースはユーザーの弄り易さだけで、質はまだよく判らないんだけど。 それよりcode::blocksはnightyなんて出してないで、判りやすいバグを 放置したリリース版をリプレースするべきだ。 30分も触ると落ちるのは、どうかしてる@win32 346 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 08:35:21 ] 30分さわって強制終了なんて一回も経験したことないな 特定の使い方をして落ちてるか、環境が悪いかのどちらかじゃないか？ 347 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 10:44:42 ] DialogBlocks人気っぽいから入れてみたけど 軽快だし操作感がやたらいいな。 348 名前：344 mailto:sage [2009/01/22(木) 11:37:56 ] そんなに沢山の選択肢示されても、無理。 349 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 15:51:12 ] >>346 環境バカはかえれ 350 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 17:09:59 ] >>346 Thread searchタブを右クリックしてThread searchのチェックを外すと マウスオーバーでThread searchの部品が浮かび上がる。 あるいはScript consoleタブにThread searchのレイアウト(のみ)が表示される。 その後view menuからThread searchのonoffを行えば1分も経たずに落ちる。 他にも2byte圏のlocaleを使用するとhelp pluginが動かなかったり。 30分はwxSmithとbuildのみを使用して落ちる時間。 日本語化すると少し挙動が変わるから、その辺も不完全みたいだ。 以上は自宅のwindows xp sp3及び2000sp4での話。 落ちた事が無い=ほとんどまともに使ってない、と理解する。 >>347 動作自体はかっちりしてる。editorはscintilla使ったcode::blocksの方が高機能だけど。 351 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 19:59:10 ] >>350 日本語化して動作が不安定になるなら、英語版を使ったほうがいい 日本語版と英語版で使い勝手に差が有るなら、日本語化を行なっている作者に文句をつけるべきだ どうやら話し口調からして、いくつか特定の「落とし方」を知っているようだから、 それらをまとめて公式のフォーラムで報告することをおすすめする オープンソース系のソフトを「まともに使っている」と自負できる人間なら、自分で修正してビルドするのもいい 一ついえることは、ここで文句を言っても、お前を含めて誰も得をしないということだ 352 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 20:29:17 ] >>351 トラブルは全て英語の話で、日本語化もgettextを使った物だからbuildは一緒だ。 そもそも初めて使って5分で出る症状を、1年近く経ってから一々報告してどうする。 30分じゃ落ちた事がないと、使ったこともない奴が宣ってるから、実例を上げただけで、 ある情報に対しての損得は、その人次第だろう。 353 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 22:15:44 ] ひさしぶりにwx-Devcppのサイト覗いたらバージョン上がってるんだけど、 使っってる人いたら教えてください。正常にデバッグができますか？ 354 名前：デフォルトの名無しさん mailto:sage [2009/01/22(木) 23:59:37 ] >>352 何か勝手に「使用経験なし」だと思っているようだが、 俺はCodeBlocksを使って何本かソフト作ったことがあるぞ？ それこそ強制終了など一度も経験せずに。（むしろgdbがよく落ちた記憶がある） 報告してどうするって、バグフィクスを期待するに決まっているだろう ユーザーがバグ報告するというのはソフト制作の大事な一環じゃないか。 修正とまでは行かなくとも、バグ回避の方法が製作者から聞けることだってある。 「文句を言うという行動は生産的ではないから、自分で何かしら行動したほうがいい」 ということがいいたいのだ。 とはいっても、こんなことは２ｃｈで言うべき言葉ではなかったかもしれないな 355 名前：デフォルトの名無しさん mailto:sage [2009/01/23(金) 02:38:38 ] 俺もcode::blocksが落ちたことはないな 特定のペインが表示されなくなって困ったことはあるが 356 名前：デフォルトの名無しさん mailto:sage [2009/01/27(火) 20:14:55 ] WindowsのMinGW-5.1.4とMSYS-1.0.10を入れた環境で、wxWidgets-2.8.9をconfigureした後makeしたんですが、下記のようなエラーが出て先に進まなくて困っています。 0 [main] sh 2996 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump ご助言を頂けないでしょうか。 357 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 12:10:51 ] WindowsだったらVisual Studioでやったらいいと思うんだけど 358 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 14:05:13 ] せっかくフリーで可搬的なライブラリ使ってるのに Windows上でだけ特別にVSなんか使いたくないわな。 359 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 16:14:06 ] とりあえず>>356のエラーメッセージは糞の役にも立たないわな。 役に立たないレベルでは50歩100歩だが、同様の環境でwxWidgets-2.8.7はビルド成功してるんで参考までに。 360 名前：デフォルトの名無しさん mailto:sage [2009/01/28(水) 17:15:08 ] configureやdumpの内容も書いてない状況でした。 失礼しました。 同様の環境で出来たとのお話もあったので、 ライブラリ周りを見直してみたら上手くいきました。 助かりました。ありがとうございます。 361 名前：デフォルトの名無しさん mailto:sage [2009/01/29(木) 19:14:42 ] マウスイベントでWindowsAPIのSetCaptureに相当するものってあったっけ？ 362 名前：デフォルトの名無しさん mailto:sage [2009/01/29(木) 19:18:07 ] 自己解決 CaptureMouse(); ReleaseMouse(); 363 名前：デフォルトの名無しさん mailto:sage [2009/01/30(金) 17:32:00 ] マウスの動きに連動して描画させると 非同期に描画命令が発行されるんだけど つまりマウスの動きに合わせてPaintイベントが何度も呼ばれる 全部処理してから最後の描画が終わるまで画面が更新されない そのせいでマウス移動中に画面がぐちゃぐちゃになるんだが 完全に表示が終わるまでマウスを動かなくするとか 他の描画が来たらそれ以前のはすべてキャンセルさせるとか出来ないの？ 364 名前：デフォルトの名無しさん mailto:sage [2009/01/30(金) 18:17:32 ] >>363 他からPaintイベントが出るなら マウス操作中は自分だけが処理するように OnPaintを自前で用意すればいい。 マウスの移動だけではPaintイベント出ないとは 思うんだけど… 365 名前：デフォルトの名無しさん mailto:sage [2009/01/30(金) 19:45:18 ] マウスの動きに連動して描画させると 366 名前：デフォルトの名無しさん mailto:sage [2009/01/30(金) 23:14:50 ] 描画（が何してるかわからんけど）でOnPaint出たっけ？ 367 名前：デフォルトの名無しさん mailto:sage [2009/01/30(金) 23:23:21 ] >>363 マウスイベントハンドラで Refresh() を呼んでPaintイベント出してるとかいった状況？ もしそうなら、Refresh() 呼んだ直後に Update() 呼べば、同期的に画面更新できるよ。 (つまり、Update() から戻ってきたときにはPaintイベントが処理されて、画面更新が終わってる)

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef