いつもお世話になっているWxWikiを抜粋して翻訳
元ネタ
WxWidgets Compared To Other Toolkits - WxWiki
wxWidgetsと他のツールキットの比較
いくつかの一般的な覚え書き：
- wxWidgetsはC++によってのみ動作するわけではありません、python, perl, php, java, lua, lisp, erlang, eiffel, C#(.NET), BASIC, rubyそしてJavascriptでさえバインディングがあります（バインディングについての一般的な情報を見てください）
- wxWidgetsはもっとも完璧なGUIツールキットの一つです。たくさんのユーティリティクラスがあります
- たくさんのドキュメントがあります（少し散逸気味ですが…）
- 個人使用、商用使用、どちらも自由です*1
- 可能な限り、wxWidgetsはプラットフォーム固有のSDKを使用し、システムが用意したウィジェットを使用する。*2これはWindowsでコンパイルしたプログラムがWindowsのプログラムのルックアンドフィールを保持し、LinuxのマシンでコンパイルしたプログラムがLinuxのプログラムのルックアンドフィールを保つことを意味する。
- この点におけるwxWidgetsの利点は、wxWidgets（で作ったアプリ）の見た目、動作、そして見た感じがプラットフォーム固有であるという事です。…ときどきプラットフォーム固有の特徴を取り込んでいる場合があります（例えば、OS Xではすべてのテキストエリアで組み込みのスペルチェックが使用可能であるなど）
- この点におけるwxWidgetsの難点は、アプリの動作がプラットフォームによって異なるという点です、つまりウィジェットが軽量なツールキットはプラットフォーム固有の特徴を失ってはいるが、同様にプラットフォーム固有のコードを最小化していると言える（それ故にプラットフォームごとの異なる動作によるリスクとそれによるバグを最小化できるのだ）。アプリの自然な見た目にこだわるということは、wxWidgetsがシステムのテーマの代わりにカスタマイズされた見た目のアプリを作成するのに適していないということを意味する。
- wxWidgetsはマクロの使い過ぎであるとの悪評を頂いております、特にイベントテーブルにおいて。しかし、強調しておきますとwxWidgetsの実装には常にマクロなしの代替実装も用意しています。そして特にwxWidgets-2.9(3.0)では古いマクロベースのテクニックの実装に対する代替（つまりテンプレートを使用したモダンな実装）を用意する努力を行いました。それ故、あなたがマクロを含んだ古いコードを見かけたとしても、それはwxWidgetsが提供する全てであるとあなたが確信するには足りない*3
クロスプラットフォームなGUIツールキットについては、スラドにスレが立っています。それはちょっと古いですし、所詮スラドですね（笑）、しかしそこでは有益な洞察が得られるかもしれません。
訳注１：マイナーなGUIツールキットはそもそも使われないし、訳しても無意味なので訳しません。
訳注２：また、比較は常にwxWidgets側から見たものです
Qt
- Qt (http://qt.nokia.com/) と wxWidgetsはどちらもGUIとは関係がないクラスを持ち合わせている、例えば日付/時間、コンテナ、ネットワーク、そしてOpenGLなど。
- Qt4,5はMS Windows, Mac, そしてGNU/LinuxにおいてLGPLライセンスもしくは商用ライセンスで使用出来る。一方でwxWidgetsのすべてのポートはLGPLの修正ライセンス*4で配布できる、それはつまりプロプライエタリのアプリケーションの開発と配布をライセンス費用なしに行えることを意味する。
- QtはwxWidgetsがもっているようなシステム固有ポートを持ちません。Qtはシステムが用意したウィジェットを使用せず、そのテーマをエミュレートします。これの意味するところは、Qtが実際のところどのプラットフォームでもQt自身がウィジェットを描画しているという事です。ただし、QtがMac OS XとWindows XP/VistaにおいてネイティブAPI *5 を使用した特別なスタイルを使用出来るという事は言及する価値があるでしょう。それはスクロールバーやボタンなどの標準的なウィジェットの描画を他のネイティブアプリと同様に行うことが出来る。イベントハンドリング、つまり視覚的なフィードバックの結果とウィジェットのレイアウトは常にQtによって実装される。
- Qtのこのアプローチと同様の試みがwxUniversalとしてwxWidgets内に保管されている
- KDEと組み込みLinuxについても言及すべきでしょう、QtはネイティブなGUIライブラリです
- QtはC++言語をMOCと呼ばれるもので拡張しています、MOCはQtのsignal-slotsのような機能を提供します。利点はsignal-slotを使ったイベント処理の機微です、難点はこの仕組みがあなたのビルドシステムを侵食し、言語の非標準の機能を使わされるという点です。wxWidgetsはC++言語の拡張はしないので、ビルドシステムを侵食することもなく標準的なC++を期待している開発者を驚かせることもない
- QtはフレームバッファをもったGNU/Linuxベースのすべての機能を備えた組み込み用GUI( Qt for Embedded Linux )を備えている。これが意味するところは、 /dev/fb を備えたLinuxさえあれば苦労なしにサンプルのアプリを走らせることが出来るということだ。Qt for Embedded LinuxはX11と比べてもメモリ占有度は小さい。
- QtのためのIDEは数多くある、Qt, QtDesigner, QtCreator, QDevelop, Edyukなど。また同様に、有名なIDEに統合されているもの、Visual StudioやeclipseやXCode付属の物もある。（これについてはwxWidgetsにもいくつかある）
- Qtは便利な商用サポートを提供している（しかし、それについてはwxWidgetsにもある、http://www.wxwidgets.org/support/support.htmをご覧ください）
- wxWidgetsにはQtベースのアプリケーションを動かすためのポートが準備されている（wxWidgetsのSubversionでwxQtブランチを見てください）、それはwxWidgetsのアプリケーションがGTK-Qtを利用しなくても済むようにするために、KDE固有のルックアンドフィールを提供するアプリケーションをビルドするためのものです。
FLTK
- FLTKのサイト：http://www.fltk.org/
- wxWidgetsはもっと成熟したオブジェクト指向で設計されています
- FLTKは軽量ですが、wxWidgetsはより多くの機能を備えています（wxWidgetsはネットワーク、印刷、などの機能も持ちますがFLTKはこれらの機能のサポートが限られているか存在しません）。wxWidgetsの機能リスト(http://www.wxwidgets.org/about/feature2.htm)とFLTKの機能リスト(http://www.fltk.org/documentation.php/doc-1.1/intro.html#2_2)を比較してみてください。
- FLTKは実際すごく手の混んだ、通常とは異なるウィジェットの類のものを備えています。FLTKのFLUIDでできることはwxDesignerやDialogEditでできることと比較できるでしょう。私はFLTKのアプリをwxWidgetsに移植した事がありますが、ボタンのエミュレートにとても苦しみました。
- FLTKの修正LGPLライセンスはwxWidgetsのライセンスよりも厳し目です。しかし、静的リンクする場合には例外を設けています。
- 軽量なIDEのFLUIDというものがあります(http://www.fltk.org/documentation.php/doc-1.1/fluid.html).
FOX
- FOXのウェブサイト：http://www.fox-toolkit.org/
- FOXは軽量ですが、wxWidgetsはより多くの機能を備えています
- wxWidgetsはより完璧なAPIをもちます、一方でFOXはGUI描画に主眼を置いています
- FOXはどのプラットフォームでも自分自身でウィジェットを描画します、代わりにネイティブのウィジェットを使用することもできますが(Qtのように)、wxWidgetsはすべてのサポート済みのプラットフォームにおいてネイティブのポートを提供します。FOXは前述の理由により動作が高速かもしれませんが、FOXが提供するアプリケーションのルックアンドフィールは対象のプラットフォームに馴染まないかもしれません（※例えばWIndowsXPのテーマは使用することができません）
- FOXは印刷機能とアジア系の言語に対する多言語サポートがありません
- FOXでは標準的なWindowsのダイアログボックスがサポートされていません、しかしプラットフォーム非依存の同様の機能が利用可能です
Java GUI toolkits
- wxWidgetsで書かれたアプリケーションは最終的に機械語にコンパイルされます。SWT、SwingそしてQtも同様です。しかしながら、アプリケーションのGUI以外のソースコードについては、wxWidgetsにおいては機械語にコンパイルされますが、Javaのアプリケーションにおいては中間言語に置き換えられます。（しかし、今日ではSWTはC++のバインディングもあります）*7
- ・Javaによるアプリケーションの性能については複数の問題が存在する。Javaによるアプリケーションは大抵の場合C/C++によるアプリケーションよりもメモリを多く使用する。また、Javaベースのアプリケーションの使用者はJVMをインストールしなければならない。近年では、より多くのコンピューターがJVMをインストールするようになり、このことが問題にならなくなりつつある。しかしながら、古いJVMを使用している人々は性能/セキュリティの問題に苦しんでいる。
- ・wx4jはJavaによるwxWidgetsの実装である。wx4jはJavaプログラマーが、自身のJava言語の資産を保持しつつもC++で書かれたプログラムによりその性能を維持することを許容するwxWidgetsのJavaバインディングだ。
- ・wxWidgetsは多くのプログラム言語から使用でき、その統合が容易である。一方で、JavaのGUIツールキットはJVMを使用する言語からのみしか利用できない(...例えばJava、JRuby、Jython、Javascript、BeanShellなど）
- ・JavaはJava Webstartにより簡単にダウンロード・展開できます。それ故ユーザーはアプリケーションを試用できます（例えば http://jabref.sourceforge.net/ を見てみてください）
以下の問題についてはより明確にされるべきです、どこでJavaのGUIツールキットについて議論するべきでしょうか？
- クロスプラットフォームであるがために、Javaは一般的に共通の分母が最も小さくなるように設計されています。ツールキットの機能は利用可能もしくは適切なプラットフォームの場合のみ使用できますが、そうでない場合はJavaのAPIから放置されています。例えば、Windowsのタスクバーの操作、Mac OSのメニューバー、そしてUNIXのファイルの属性などなど…
- 上記から引き出せる結論としては、wxWidgetsでは必要ならばプラットフォーム固有のコードをいつでも書ける（#ifdefによってコードを分岐させることで、あるプラットフォームでしかコンパイルされないように仕向けることができる）。Javaにおいては、#ifdefにあたるものがない。それ故あなたはAPIの外へ大ジャンプをカマさなければいけなくなる。同様に、wxWidgetsは異なるプラットフォームでは利用できない特定の機能についてはエミュレートを提供している（例えば、MDIやツリーコントロール）
SDL
- http://www.libsdl.org
- SDL(Simple DirectMedia Layer)はゲームその他のマルチメディアのために最適化されたC言語のライブラリです、望むならばすべてをカスタム可能ですが、一般的な用途のGUIのウィジェットはありません。また、SDL_プレフィックスから始まるたくさんのC言語の構造体を使用します。
- SDLはwxWidgetsと連携させることが可能です：http://code.technoplaza.net/wx-sdl/
- LGPL v2のもとに配布可能です
- 単一のウィンドウのみを開くことを許容します
- OpenGLとの統合に最適です（もしくはOpenGLでビルドされたライブラリを利用するとよい、例えばOpenSceneGraph、CEGUI）
Allegro
- http://alleg.sourceforge.net
- AllegroはSDLによく似たクロスプラットフォームなゲームプログラミング用のC言語のライブラリです（バックエンドにはかなりのアセンブラを使用しています）
- wxWidgetsと同じぐらい古いです（1993年〜）
- Giftwareライセンスのもとに配布可能です（言ってみればパブリックドメインです）
- ビルドにはGCCとアセンブラが必要です
- 開発がここ数年同じバージョンで止まっています、また中心となる開発者が不足しています（元々の開発者はもはやチームにはいません）、そして開発をフォークすべきという内部の議論があるようです
- GUIの機能が稚拙です - 一つのウィンドウに出来合いの操作しかサポートされていません - ウィンドウを動かすことすらできねえ…などなど
- Allegroは、"操作"については（多くの可変長引数を使用した関数群によってですが…）比較的サポートされています、そしてQtのようにライブラリ自身がGUIの描画を行います（しかしデフォルトではそこまで見栄えがよくありません）。ウィンドウは比較的簡単なAPIによってカスタマイズが可能です（そして、もう少しましな見た目を提供するサブライブラリもあります）
- 描画処理はwxWidgetsよりずっと早いです、そしてOpenGL用のレイヤがあります（allegrogl - http://allegrogl.sourceforge.net/）。これはOpenGLの描画をデフォルトよりも容易にするものです
- GUI抜きの処理（入力など）は低レイヤで、だいたいwxWidgetsの実装よりも早いです
- それほど労力をかけずともwxWidgetsと併用できます - Allegroはいくつかのプラットフォームにおいてウィンドウハンドルを得るためにプラットフォーム特有の機能を持っています、開発者はそのウィンドウハンドルからwxWIdgetsのウィンドウを呼び出せるし、そこからやりたいことを実行できる。一方で、wxWidgetsはプラットフォーム固有のmain/WinMainのようなものを制御するためにwxAppというクラスを使用しているので、AllegroはEND_OF_MAIN()というマクロを呼び出す必要がある。２つのライブラリを併用するのはちょっとした作業だが、決して重労働ではない。
GTK+
- http://www.gtk.org
- GTK+とはもともとはGimp*8のためのツールキットでした、それはUnix系のシステムのためのLGPLのC言語向けGUIライブラリです
- GTK+はかつてWindows、VMS*9、そして他のシステム向けに移植されました、これらは同じAPIから使用できます（MacOSXからは現在Appleの提供するX11.appから利用可能です、ネイティブ版は開発中です。どちらもビルドと、特にパッケージングが苦痛です）しかし主要な開発はUNIX向けです、というのもマルチプラットフォームでの開発とはほとんど後から考えられたものだからです
- GTK+はGNOMEのユーザーインターフェイスを構築する主要なライブラリです
- wxWidgetsとは違い、GTK+はC言語を使用します（そして同様にGTKMMというC++のラッパーがあります http://www.gtkmm.org）
- GTK+はglibという汎用的用途のためのライブラリを依存関係のトップにおいてビルドされます（…glibはC++のSTLのように使われ、いくつかの構造体、メモリ管理用関数などを提供します）
- GTK+で作成したアプリケーションは、テーマなどを使用しない限りすべてのプラットフォームで完全に同じ見た目と動作です。WindowsにおいてはWimpのテーマ(これはUxThemeを使用する)を使用することでネイティブの見た目に近づけることができます。
- GTK+はWindowsにおいて、システムが提供するウィジェットを使用しません、しかしテーマを使ってエミュレートします
MFC
- MFCはWindowsにおいてのみ無償で利用可能です
- ・マッキントッシュ版のMFCはVisual C++ Crossplatform Edition*10(最後に確認したときは800ドルした）というものが存在しましたが、バージョン4.1からのコンパイラはサポートされていない
- ・MainWin*11と呼ばれるUNIXの変種というものが存在しましたが、それは驚異的に高価で、ランタイム用のライセンスを要求した、しかも得体のしれないサポートにそれを報告しなければならなかった
- wxWidgetsもMFCもソースコードが利用できますがwxWidgetsにEULAsは関係していません*12
- MFCを使用したアプリケーションはwxWidgetsと比べて実行ファイルのサイズを小さく出来る（まともなコンパイラには無関係であるが）
- MFCは良質な商用アプリケーションのほとんどを担っている
- MFCのメッセージマップよりもwxWidgetsのイベントテーブルがより良いと言う人もいます
- wxWidgetsのクラス階層はより直観的な一方で、MFCは最上級のクラス名が類似的になる傾向にある
- .NETは問題ではありません - MFCは.NETに移植されることはありえないでしょう。しかしwxWidgetsはすでに.NETのラッパーの開発をα段階まで移行しています！
- MFCは幅広いコンポーネントを利用可能です、特にデータと連携したGUIの描画に長けています
- wxWidgetsで簡単に実現できること、例えばウィンドウ描画の特定の方式（常にトップにウィンドウを表示させるなど）がある一方で、MFCであれば簡単に実現できることもあります。例えば取り外し可能なツールバー。
- おそらくMFCを使用する最強の利点はMSVCという統合開発環境を利用できることでしょう
- クラス名とその他の点についての情報は、WxWidgets For MFC Programmers - WxWikiを見てください
Tk
- TkはTclというスクリプト言語用に設計されたGUIツールキットで、この言語の最も主要な使用法です。Welcome to the Tcler's Wiki!にもっと情報があります。
- Python, Perl, Ruby, C++のような言語にバインディングが存在します
- Tk自体はそれほどウィジェットを提供しません、しかしいくつかの拡張用ライブラリが使用可能です。例えばBWidgesはC言語もしくは純粋なTclで書かれた拡張です。
- 8.5以前のバージョンのTkは時代遅れです。ついにTkはWindowsとMac OS Xにおいてタイル拡張*14とTk 8.5でttkを追加しました。Tkは今やこれらのプラットフォームでプラットフォーム固有の見た目を提供するようになった。Linuxにおいてはいまだ昔の見た目のままです。これはだんだんと進行していますが、TkはGTKとQt用のテーマを開発中です。あなたはTkで作ったアプリケーションの見た目の向上のために、他のテーマを使用することができます
- TkはPythonにおいてデフォルトのGUIツールキットです。このバインディングはTkinterと呼ばれています。TkInter - Python Wiki
- Tkは強力なキャンバスウィジェットを持ちます。これは何でも描画できますし、カスタムのウィジェットを作成することも可能です。
- Tkは強力なイベント処理機能を持っています
- Tkはその単純なAPIと記述コードの少なさによってGUIの設計が必要ないプログラマーに使われてきました*15。そう、それでもGUIのデザイナーはいます。「Hello World!」をワンライナーで書くと:pack [ttk::label -text "Hello World!"]
- 完全なGUIのプログラムをTcl/Tkで開発すると、一個のバイナリファイル(なんと1MB程度)にまとめられます。これはStarpackと呼ばれ、すべての主要なプラットフォームで展開されています。Tclkit application runtimeにより詳細な情報があります。
- Tkはとても革新的なBSDライセンスにて商用ソフトウェア開発を許容します
- どうしてあなたはTkを使うべきか？それはあなたが無償で、成熟し、安定した、スクリプト言語を使用しているクロスプラットフォームのGUIツールキットを必要としているからです。
- どうしてあなたはTkを使うべきでないか？それはあなたがC++を使用する予定であるか、最初から大きなウィジェットを必要としているからだ。その場合はwxWidgetsを使用するべきでしょう。
==========================================================================================
総評
- Google Native Clientの評価がない ●3点
- もうJavaでいいだろ…なんでwxWidgetsなんて使ってるんだ（…元も子もない）
- Electronとかもない、古いからしゃーないか Electron | Build cross-platform desktop apps with JavaScript, HTML, and CSS.
まとめ表
| ライブラリ | クロスプラットフォーム | コーディング難度 | 環境構築難度 | ライセンス | ユーティリティの充実度 | プラットフォーム固有コード | 一言コメント |
|---|---|---|---|---|---|---|---|
| wxWidgets | YES | 普通 | 煩雑 | 修正LGPL | やれることは多いけど初心者がとっつきにくい | ||
| Qt | YES | 普通 | 煩雑 | GPL or commercial | さすがです | ||
| FLTK | YES | やや難 | 簡単 | GPL | C++のハゲが推薦 | ||
| FOX | YES | ？ | 簡単 | LGPL | よくわからん | ||
| Java | YES | 易しい | 簡単 | SWT -> EPL | んｗｗｗ商用ならJava一択ですぞｗｗｗｗｗ | ||
| SDL | YES | やや難？ | 簡単 | zlib License | ゲーム用 | ||
| Allegro | YES | ？ | ？ | パブリックドメイン | よくわからん | ||
| GTK+ | YES | 普通 | 不可能な場合あり | LGPL | 渋い、古い…（APIが） | ||
| MFC | NO | 普通 | 簡単 | プロプライエタリ | .NETに取って代わられる運命 | ||
| XUL | YES | やや難 | 煩雑 | GPL or LGPL or MPL | 最強・しかし使いにくい | ||
| Tk | YES | 易しい | 簡単 | BSD(?) | ありだと思います |
*1:wxWidgetsはLGPLからの派生ライセンスですがどちらかというとBSDとかMITライセンスに近い。自由ソフトウェアとはちょっと遠い。
*2:Mac OS XはSDKをいろいろお配りくださるので、ビルドがめんどい
*3:「ちょっとソース見たぐらいで判断すんなよ」という開発者の心が見える
*5:Appeareance Manager on Mac OS X, UxTheme on Windows XP
*6:jwxはあまり更新されてないようですね…
*7:ここの文章は怪しい。ここはJavaのアプリケーションについて話している段であり、Qtが入るのはおかしい気がする
*8:ご存知お絵かき用のアプリケーション
*9:http://ja.wikipedia.org/wiki/OpenVMS
*10:こんな開発環境が存在したんですね…たまげたなあ。邪悪なOSに邪悪なIDEが両方そなわり最強に見える、FreeBSDはカーネルパニックを起こして死ぬ
*11:それらしい資料があった MainWin® 3.3 Build 67 Release Notes - ibm.com
*12:なんかのジョーク？
*13:ここの記述は全体的に疑わしい、XULの利点はスクリプトを書けばクロスプラットフォームでウィジェットを作成できる点、またMozillaのGecko(そのJavascriptエンジン/CSSのパーサを含む)をそのまま使える点にある。ある意味最強だと思うが、Mozilla以外のツールから使いにくいことが難点。
