【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/ 231 名前：デフォルトの名無しさん mailto:sage [2008/12/25(木) 23:04:51 ] >これだけのものは他にないな。 Qt ... 232 名前：デフォルトの名無しさん mailto:sage [2008/12/25(木) 23:13:21 ] 流行らないのは、「クロスプラットフォームなGUIアプリ」のニーズが 少ないから ポータブリティがタダで（犠牲なしに）手に入るのならいいが、残念ながら そうではないしな 233 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 00:34:10 ] 宣伝してないのと日本語資料が無きに等しいからだろう 234 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 08:55:58 ] >>231 やっぱ、Qtってメチャクチャ良いの？ クロスプラットフォームの開発にwxDev-C++でやってるんだけど、 C++ Builderには遠く及ばない感じがして。。。 235 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 14:03:04 ] 230に ライセンスがうざくない OSネイティブのTKで動く も入れるとQtは却下だな。 236 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 14:41:05 ] >>235 Mac OS X 上では ネイティブ度？は Qt のほうがマシだベ。 まあ誰も wxMac をつかってなさそうでメンテされてないからだろうけど。 237 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 19:47:15 ] VCL ○C++（少しDel臭いがMFCよりはマシ） ×オープンソース ×クロスプラットフォーム ◎GUIウィジェット ◎非GUIラッパ ○ドキュメント ◎RAD ○スタティックリンク可 MFC ○C++（かなりインチキ臭いマクロとか多いが） ×オープンソース ×クロスプラットフォーム ×GUIウィジェット ○非GUIラッパ ○ドキュメント ×RAD ○スタティックリンク可 WTL ◎C++ ◎オープンソース ×クロスプラットフォーム ×GUIウィジェット ○非GUIラッパ ×ドキュメント ×RAD ○スタティックリンク可 238 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 19:47:55 ] 誤爆った 239 名前：デフォルトの名無しさん mailto:sage [2008/12/26(金) 21:23:30 ] なんでスタティックリンク可不可って問題なの？ Windows でもインストーラ書けばいいのでは？ Linux だったら .rpm とか .deb でいいし、 OS X なら .app パッケージに全部つっこめばいいよね... 240 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 00:28:37 ] ある時見つけた便利そうなソフトがインストーラしかないと知ってスルーした経験ない？ 241 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 01:14:27 ] できないよりはできたほうがいいな。 242 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 10:54:50 ] >>240 ないけど... ていうかインストーラ無いやつは Program Files 内に入らなくて 自分でフォルダ管理しないといけないからウザイ 243 名前：デフォルトの名無しさん [2008/12/27(土) 15:19:17 ] 会社とかで、さっくりと作ったアプリを もらった時とかに、インストーラーがあると逆にうざくて しょうがないときとかない？ 何で、わざわざインストールが必要なんだ？とか 244 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 15:57:20 ] そんなことより Windows Update がうざい 245 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 16:13:48 ] ちょっと試してみるだけだったり、気に入らなければすぐアンインストールする つもりのことが多いから、インストーラ無しのほうがいいな フリーウエアでインストーラ付きだと、インストールするのをやめることもある いやな予感がするときとか 246 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 16:23:45 ] インストーラが本当に必要なレベルの大型ソフトなんて個人では作らんよ 247 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 17:01:06 ] あとスタティックリンクできないと なんのライブラリつかってるかもろばれじゃん。 有用なライブラリは同業者に教えたくないし。 248 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 17:33:01 ] >>247 その発想はなかったわｗｗｗ 249 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 19:53:37 ] そうか、インストーラ拒否症のひとって多いんだな。 自分がそうでないからわかってなかったが、 今後はスタティックリンクするようにしよう... 250 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 21:50:07 ] それにしたって、実行ファイルと同じフォルダにdll詰めてzipで配布すりゃ良いんじゃないの？わざわざスタティックリンクしなくても。 >>247 さすがにそれはねーよwどんだけ情報弱者の同業者想定してんのｗ そのしょぼい独占欲で守られる利益なんて大してねーよw 251 名前：デフォルトの名無しさん mailto:sage [2008/12/27(土) 23:52:23 ] やたら巨大なライブラリの一部の機能しか使わない時なんかは、 サイズ的にスタティックリンクの方が効率いいかもしれん。 まあ、そんなにサイズを気にするご時世じゃないけどね 252 名前：デフォルトの名無しさん [2008/12/28(日) 01:48:53 ] スタティックリンク最大の利点は精神衛生上 ちょっと一端のプログラムを一人で作りあげた感を得られることだろう。 Windows慣れしてると、なんか変なdll置いてあるだけで どことなく「ライブラリ頼りのトーシロ」感がかもしだされてしまう。 それよりはやっぱり実行ファイル一つ、のほうが気持ちいい。 253 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 03:12:08 ] Windows自身がライブラリの塊じゃん 254 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 04:11:19 ] 実行ファイル一個で済む方が気分が良い 255 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 06:44:07 ] 動的リンクなら、ライブラリに脆弱性が見つかったときに そのアプリがメンテされて無くても対応できる可能性が！ いや、まずないけどね 256 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 11:10:28 ] >>252 ひとによって考え方が違うのは承知の上で聞くが、 全然わからん。プログラム書いた本人は 何のライブラリ使ったか覚えてるわけでしょ？ 見た目だけちがうだけでなんで気持ち良かったり気持ち悪かったりするの？ 257 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 13:32:06 ] windowsユーザーの意見だけど…… dll使用が嫌われるのは「俺のPCのシステムに変なの仕込むな」つうことだけでしょ？ dll hellとかも嫌だし、アンインストールするときにキレイになるか判らんし。 exeと同じフォルダに仕込んどけばシステムにインストールする必要は無くなるけど、 dllのメリット無くなるしね。 258 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 13:37:21 ] 動的リンクで後から脆弱性が直せる可能性があるなら 同じように後から脆弱性を作り出せる可能性もあるのかな？ 259 名前：デフォルトの名無しさん mailto:sage [2008/12/28(日) 14:46:08 ] 最近はサイドバイサイドとかマニフェストとか色々めんどくさい 260 名前：デフォルトの名無しさん [2008/12/29(月) 22:37:21 ] >>250 いやあ、それが気になるのですよ。 うちの場合、 「ダイナミックでいれたランタイムを他のアプリが勝手に入れ替えた場合の保証がとれない。」 という理由で、お試しに作ったソフト・出荷ソフトの区別なく 一切ダイナミックリンク禁止になってます。 ちなみに、うちでは工場系のソフト（VC6 MFC製）を扱ってます。 工場のマシンに勝手にアプリを入れる馬鹿がいるとは思えないので、 ダイナミックだろうがスタティックだろうが、関係ないはずなのですけど・・・。 もしかして、OSのサービスパックが勝手に更新する、Cランタイム／MFCライブラリ に対しての評価のことを気にしてるのか？ 261 名前：デフォルトの名無しさん mailto:sage [2008/12/29(月) 22:54:58 ] 全然素人なんだけど、工場って WIndows つかってるの？ でかい機械をコントロールしてるときに Windows がブルースクリーンになったら どうするんでしょう？危険でない？ Windows ベースのタッチパネル端末で良く異常終了して エラー画面になって止まってるのをみるんだけど... 262 名前：デフォルトの名無しさん mailto:sage [2008/12/29(月) 23:36:26 ] 監視端末(Windows)と機械のファームは別だろう。 端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず 263 名前：デフォルトの名無しさん [2008/12/30(火) 00:23:35 ] >>261 >>262 もちろん、機械のファームはWindowsではないですが、 監視端末はWindows2000です。XpやLinuxにするだけのメリットがないので。 枯れた技術(STLですら新技術扱い)・枯れたコンパイラーしか(いまだに、VC6だぜ)使わせてくれないから、ブルースクリーンになることは、まずないよ。 >端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず のように設計指示はしてるのだけど、実際に作ってるのがFSIの新人だから、 評価だけはしっかりやらせてる。 264 名前：デフォルトの名無しさん mailto:sage [2008/12/30(火) 00:43:11 ] なるほど！安心しました。まあ従業員の命がかかってるからそりゃ対処してるでしょうね。 265 名前：２６３補足 [2008/12/30(火) 01:05:15 ] EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、 同じDLL（Version違い）がWindowsディレクトリにあった場合に、 動作してしまう可能性がある。 DLLのVersionチェックとかできればいいのだけど、 Versionチェックそのものがバグってた場合や、Cランタイム／MFCランタイム に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。 Version差分によって修正されたDLLの場所に、 競合とかリークとか実装上のミスがたまたま引っかかって、 １％の確率で落ちたりしたら、だれが責任とるんじゃ？という問題があるのよ。 １００万個作る場合、１万個の不良が出てしまう。。。 だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。 リスク軽減。その辺ってかんがえてる？ 266 名前：デフォルトの名無しさん mailto:sage [2008/12/30(火) 04:29:07 ] ダイナミックリンカのバージョンが変われば問題も起こるからなぁ。 プロトコルが決まっていればいいんだが、 プロトコルが一定でない関数呼び出しみたいなものは出荷検査みたいなのに対応できない。 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毎に自然な外観提供できて 複雑なライセンス体系が無くならない限り移行はできないなあ。。

---

---

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

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