wxWidgetsのススメ

wxWidgetsのススメ

この記事ではwxWidgetsを紹介するわけだが、さて書こうとして、その書き出しに困ってしまった。あまりに色々な切り口の紹介が可能で、魅力的すぎるからだ。ここは素直に、特徴を箇条書きにしてしまおう。

• 洗練されたAPIを持つGUIライブラリである。
• 実装言語はC++だが、Python, Perl, C#(.NET)等へのバインディングがある。
• Win32, MacOS X, GTK+, X11, Motif, WinCEなどのマルチプラットフォーム対応。
• 基本はネイティブコンポーネントへのラッパであり、OS固有のLook&Feelを保つ。
• 文字列クラス等の基本的なものを含め、GUI以外の豊富なクラス群を持つ。
• 無料かつオープンソースであり、LGPLを非常に緩和したライセンスで商用利用も容易→参考。
• 15年以上もの歴史(since 1992)があり、非常に安定している。
• wxWidgets Featuresで紹介されているその他の要素
  • 印刷
  • デバッグ
  • Visual C++, gcc, その他多数のコンパイラ対応
  • データベースサポート(ODBC)
  • ドキュメント・ビューアーキテクチャ
  • ドラッグ＆ドロップ
  • マルチスレッド
  • 設定保存のAPI
  • ネットワーク(TCP/IP, HTTP, FTP)
  • HTMLクラス
  • OpenGL統合
  • OLEオートメーション対応
  • 多言語（国際化）対応

多い、多すぎる…。筆者はこれほど充実したGUIライブラリを他に知らない。

 サンプル画面

非常に簡素なもので申し訳ないが、画面を例示しよう。

リストボックス、コンボボックス、カレンダーコントロール、プログレスバーなどの一般的なGUI部品が使用できるのがわかるだろう。

しかし重要なのは、これがWindows以外のOSでも同等の表示が可能で、かつ非常に安定しており、なにより日本語が通ることだ。この3条件だけで、他のGUIライブラリを圧倒している。特に日本語に関しては、条件の合うライブラリは少数だ。

画面をよく見てほしいのだが、右上のスタティックテキストには「表示能力」と書いている。勘の良い方ならお気づきかと思うが、「表」と「能」はいわゆるダメ文字で、Shift_JISコードで0x5Cを含んでいる。多言語対応がきちんと行われていないライブラリではこの部分は文字化けするのだ。これがまともに表示できるのは大きい。

自分が使用するだけのソフトなら英語のみでも構わないのだが、人に使わせるソフトはやはり日本語表示をしたいものだ。wxWidgetsなら、これに応えてくれる。

 wxWidgetsの弱点

wxWidgetsは非常に魅力的な特徴を備えたライブラリであるが、弱点も存在する。以下に羅列しよう。

1. ライブラリの大きさ。一般的なアプリケーションで数MBになる。
2. 主要な開発言語がC++であること。C++はGUIを記述する言語としては既に古い。
3. 各プラットフォーム固有の処理には弱い。結局直接OSのAPIを呼ぶことはある。
4. 大分普及したが、それでもユーザ数は多いとは言えず情報が少ない。
5. 日本語での情報が少なく、使いこなすには英語力が必要な状況である。
6. サポートするIDE/RADが発展途上であり、商用製品に比べかなり見劣りする。

しかし後半は、改善されてきている。そろそろ、ブレイクする頃ではないだろうか。

なお、wxWidgets (wxWindows) 日本語ドキュメントプロジェクトが存在するが、作業は停滞しているっぽい。

 なぜ今、wxWidgetsなのか？

実は、筆者はwxWidgetsがwxWindowsという名前だった頃から注目していた。なのになぜ、今になって紹介する気になったのか。これは、環境がそうさせたと言っていい。

筆者がwxWindowsを知った頃、gccはまだ2.9xが主流であり、VisualStudioは6.0だった。MinGWはまだまだ発展途上でCygwinが優勢だったし、Javaが話題をさらっていた。ちょうどeclipseがオープンソースになるちょっと前の話だ。

当然wxWindowsに関する情報はまだまだ非常に少なく、日本語ではほぼ皆無。RADツールはなかったか、あっても「タグを挿入するHTMLエディタ」レベルだった。

簡単に環境を整えられたこと、ドキュメントが整備されており情報があったこと、Javaはもっと発展すると思われたことから、当時の筆者の選択はSwingだったのだ。加えて速度が必要なもの、Windows固有のものはVisualStudio6.0でこなしていた。

その後は就職したこともあり開発自体をあまり行わず、VisualStudioの暴走っぷりを横目に見て、wxWindowsのことも忘れかけていた。

が、今は2008年。Javaの速度・GUI関係は思ったより改善されず、逆にMinGWはかなり育った。gccは4.x.x系列が利用されるようになり、VisualStudioはMFCを含まない無料版(Express)が出た。今や開発環境は無料で揃えられる時代だ。ちょこちょこと、HTAやXUL、MinGWで遊びだす。

ふと、そういえばwxWindowsはどうなったのかと気づく。調べてみると、wxWindowsに対応するIDE/RADツールがいくつか出ている。どれもそこそこの機能を備えているが、日本語対応がまだ弱い。しかし、ついに見つけた、日本語の通るwxWindowsのIDE/RAD環境。これが今回wxWidgetsについて書いた理由である。（当該RAD環境に関しては別途掲載予定）

wxWidgetsの位置づけを考える

以下は勢いに任せて書いてしまったのですが、ダルい文章になってしまっているので興味のある方だけどうぞ。

他にもGUIライブラリというのは星の数ほどあるので、その全てと比較することは現実的ではない。筆者はこれまでMFC, Java(Swing), XULでGUIアプリを作成してきているので、このあたりと簡単に比較してみたい。

 vs MFC（.NETも含む）

MFCは天下のマイクロソフトがVisual C++のGUIツールキットとして提供するGUIクラスライブラリだ。しばらく前まではこれが王道であり、多くの商用アプリケーションもMFCで書かれてきた。特にVisual Basicが対応できない細かな実装や速度が必要な部分はほとんどの場合Visual C++で書かれていただろう。

これと比較した場合のwxWidgetsはどうか。wxWidgetsが提供する機能群は、大まかな部分ではMFCに劣らない。というより、ほとんどMFCのリプレースじゃないかと思うほど、両者の使用感は同じだ。

しかし、MFCはプロプライエタリなライブラリである以上、Visual C++を購入しなければ使用できない。最近のマイクロソフトはVisual StudioのExpress版を無償で配布しているが、この中のVisual C++ ExpressはターゲットをC++/CLI（.NETをC++から利用するもの）にしており、MFCは含まれない。.NETは現状のハードウェア情勢ではまだまだ実行速度的につらいものがあり、特に起動速度はかなり厳しい。クラスライブラリを諦め、Win32APIでの記述はできるのだが、MFC, wxWidgetsを使用する場合との生産性は比較にならない。

MFCは完全にWindowsプラットフォーム向けであり、対するwxWidgetsは完全なマルチプラットフォーム仕様だ。このアドバンテージは大きい。wxWidgetsはMFCのほぼ完全な代替として動作する上に、大きな変更なく他のOSで動く可能性がある。プログラマとして心を揺さぶられる特徴だ。ただし、Windows固有の仕様に即したプログラミングでは、やはりMFCに軍配が上がるであろうことは間違いない。

なお、.NETに関して、マイクロソフトはその仕様をオープンにしてWindows以外のプラットフォームでも利用できるものにする意向があるようだが、その進展はさっぱり聞かない。現状では.NETもWindowsプラットフォーム限定と見るほうが良いだろう。比較的簡単に入手できるとはいえ、大きなランタイムライブラリが別途必要である点がユーザに不便であることも看過できない。

 vs Java(Swing)

SwingはJava向けの軽量なGUIライブラリとしてメジャーな存在だ。まだ現在ほど無料のGUIライブラリの選択肢が多くない2001〜2003年頃、筆者はGUIアプリの開発にこれを使用していた。当時としてはドラッグ＆ドロップや画像処理、ネットワークプログラミングまで統合的に行える安定した環境が魅力で、C/C++使いであった筆者が言語の壁を越えて利用してみたくなるものであった。

現代において比較してみると、やはり.NETと同様の欠点が目立つ。当時から問題ではあったが、改善されたとは言え実行速度（特に起動）が遅いこと、別途ランタイムライブラリが必要なことは気軽に使用してもらえないことを意味する。

さらに、Swingの問題点はそのLook&Feelにある。気軽にその見た目を変更できることは魅力と言えば魅力ではあるが、見方を変えるとSwingアプリは不自然に見えるということだ。一応各OSと似通ったLook&Feelのセットが用意されてはいるが、細かなところで不整合はあるし、例えばWindows2000→WindowsXP(Luna)→WindowsVista(Aero)とOS側の見た目が大きく変わった場合に、Swing側で追従し切れていない。GUIコンポーネントを全て自前で用意していることの弊害だ。

当初の設計思想としては、WindowsではないOSでWindows的表示ができることが逆に売りになることを想定していただろうし、実際、逆に便利である環境もあるにはある（組み込み系など）のだが、一長一短だったということになる。SwingではなくSWTではこのあたりがかなり改善されていたが、Javaの特徴であるWrite once, run any where（だっけ？）をわざわざ潰してまで採用するには中途半端に感じる。であれば、後述のXULを使用する方がいっそ思い切りがよい。

対してwxWidgetsは、ベースがC++で直接実行可能なことから、速度的にはまず十分だ。ライブラリは一般的なアプリケーションで数MBを要するため、小さいとは言えないが、Javaのように10MBを超えるというほどでもなく、ギリギリ同梱を許容できるレベルだろう。スタティックリンクしてしまえば、.exe１つに全て収まる点もメリットと言っていい。そして何より、Look&FeelはOSのコンポーネントを利用するために全くのネイティブアプリケーションと同等である。

余談だが、wxWidgetsはウィンドウやフレームといったどうしてもOSに依存せざるを得ない部分以外の部分（ボタンなどのコントロールコンポーネント）を、Swingのように自前で描画・処理する形態を備えている。これをwxUniversalと名づけているが、通常のアプリケーション開発者にはあまり恩恵はないだろう。OS側が高度なUI機能を備えない場合に役立つと思われ、上記にも書いたように組み込み系などに応用されると思われる。wxUniversalはGTK+もMotifも使用しないX11向けのポーティング(wxX11)や、SciTech社の基本的描画ライブラリであるMGL向けのポーティング(wxMGL)に利用されている。実はwxUniversalとwxMGLの開発は、SciTech社のスポンサードであるとのことだ。

 vs XUL

XULは、Mozilla Firefoxのベースとなっている技術体系だ。XMLでGUIコンポーネントの配置を行い、JavaScriptで操作するのが基本となっている。XULアプリケーションはFirefoxをランタイムライブラリとすることもできるし、XUL Runnerという単独実行環境を使用することもできる。

XULの特徴は、XMLもJavaScriptもテキストベースであり、インタープリタ処理になるため、気軽に開発できる点にある。書けばすぐ試せるものであるし、HTML+JavaScriptを書いたことがある人であれば、やってみようかと思えるほど敷居が低いだろう。この点、比較的ルールの厳しい言語を前提とするwxWidgetsは不利だ。

コンポーネントは基本的なものが用意されており、一般的なアプリケーションなら必要十分だ。Look&FeelはほぼOSネイティブになる。実際Firefoxの画面はXULで構成されており、各種アドオン（拡張機能：エクステンション）もXULのみで書かれているものが非常に多数だ。技術者として、XML+JavaScriptでここまでできるのか、と感嘆せずにはいられない。これら拡張機能は簡単に追加することが可能で、そのための仕組みまで用意されている。これはスクリプト系のインタープリタ処理を最大限に生かす動的設計であり、コンパイルされたバイナリ（静的なもの）に比重があるwxWidgetsは不利である。

一方でXULの弱点は、まずその大きなランタイムライブラリ(XULRunner-1.8.1.3で15MB程度)にある。圧縮すれば5MB程度まで縮むためJavaに比べれば小さく、可搬性もよいが、若干大きめである。また、処理はJavaScriptが担当するため、軽量な作業以外は難しい。例えばバイナリデータの取り扱いや音声・画像処理はJavaScriptには向かない。これを解決するためにXPCOMというバイナリとのインターフェース仕様が規定されており、ランタイムライブラリにも実はバイナリが多く含まれている。

しかし、この設計は目的に特化した結果のものであり、これはこれで合理的だ。現代のプログラミングの煩雑さはGUIに起因することが多々ある。しかし、実はGUIそのものには、処理速度はそれほど必要ない。ボタンを秒間30回も押す人間はいないし、動画でもない限り秒間30回も画面を更新する必要もない。つまりJavaScriptは33ms程度で１アクションが行えればよいのであり、これは現代のコンピュータにとって十分長い時間だ。また特別なGUIコントロールは作成しづらいとは言え、XULのランタイムライブラリで使用できるGUIコントロールは一般的に十分なものだ。

こう考えれば、速度、サイズ、用途、開発性などの全てに対して中途半端だと感じられるJavaに対し、XULは思い切った「表層への特化」を行っているといえる。

XULで手軽にGUIを作成できれば多くの開発者を引き込むことができ、ユーザビリティを向上することが容易になる。ユーザ自身でのカスタマイズ性が高いともいえる。一方でXULで処理できない重い処理、またはプラットフォーム固有の処理はXPCOMに投げれば、機能性・処理性能も維持できる。現代のプログラミングでは、目的に応じてツールを変更するのが賢いのであって、XULの採用する方式は正しい。

この形で考えるならば、他にXULの弱点としては「オープンソースが基本」であることと、まだ新しい技術であるため情報が若干不足していることくらいだ。XML/JavaScript共にテキストであるため、内部の処理は用意に知ることができるため、プロプライエタリなソフトウェアの開発には向いていない。

とすれば、wxWidgetsとXULは共存する形が最も最適であるともいえる。コア部分はwxWidgets/C++によるバイナリで実現し、一般的なUI部分はXULで効率的開発を行う。ユーザコミュニティができれば、使い勝手はユーザ側でも改良してもらえるだろう。これにより開発者は機能コアに集中することが可能で、ソフトウェアはより洗練されていく。筆者の考える理想的なソフトウェアの開発環境だ。

いっそのこと、MozillaはXULの動作環境をwxWidgetsベースのランタイムライブラリで構築すれば良いんじゃないかとさえ思う。