wxWidgetsを選んだ理由

mosh

Gaucheでも、GTkだとどうしてもクロスプラットフォームが面倒なので、wxの方がいいかなあということは前から思ってるんだけど、GUIツールキットとしての使い勝手はどうなんだろう。

個人的には10年ちかくWin32をやってるので、Win32感覚の命名規則やイベント機構はなじみやすい気がする。ただ、一般的に見たときは微妙。多くの仕事をマクロでやっていて、通常の人間には使いづらいと感じられそう。
(以下は　http://0xcc.net/pub/uu-2004-08/　の内容と近い気がする。）
というわけで、選択の理由の大部分は政治的理由で :

  • ライセンス

wxWidgets自体はLGPLだが、ライセンスに例外条項をつけて独占的アプリケーションに利用できるようにしている。
今後の方向性として、HSPのように、スクリプトを実行可能形式で配布することを考えているのでこの条件が選択の上で最重要だった。ゲームのようなアプリケーションをGPLでライセンスする(ことを許可する)とリソースの２次利用を制限できない。

  • 静的リンクの積極的なサポート

wxWidgetsは静的リンクしても殆どのプラットフォームで適切に動作する。GtkやQtは(特にWin32で)静的リンクに対して良い考察が無い。

  • CMakeのサポート

wxWidgets自体はCMakeではビルドできないが(bakefileを使っている)、CMakeにはwxWidgetsのサポートが組み込まれている。
nmoshはCMakeでビルドできるようにしているので、wxWidgetsをリンク対象に加えるのはとても簡単だった。

  • ネイティブのWidgetを利用する

個人的にはFLTKのような軽量widgetキットを使いたいけれど、世間的には"ネイティブアプリケーションのような外観"というのがとても重要なポイントでもあるので。。
ちなみにLinuxやBSDではGtkの外観となる。

地味に重要なポイント。WideStudioやFLTKはここで脱落した。もっとも、wxWidgetsもWindows以外のサポートは最近だったりする。

vs. Gtk

もちろんGtkがWin32やCocoaで安定しているならGtkを採用したいところだが。。(ライセンスの問題はおいておくとして)

  • LinuxやBSD上では、wxWidgetsがGtk上に実装されるため、機能性がどうしてもgtkのサブセットになってしまう。
  • どちらもフォームデザイナ(Gtkのglade、wxWidgetsのwxFormBuilder)を持つ。格納形式はどちらもXMLで、適当なライブラリを用いてロードできる。
  • wxWidgetsは、プロセス間通信やZIPのロードのような細かい便利ライブラリを備えている。しかし、言語処理系的にはそのようなライブラリはGUI版以外でも使うのであまり大きなメリットで無い。。
  • wxWidgetsはC++の言語機能を使えるので、ネイティブアプリケーションを書く分には少々書きやすい。しかし、Gtkにもgtkmmがあるし、Valaのようなネイティブ言語さえある。
  • 逆にC++前提のコードになるため、言語バインディングを書く側からするとあまりうれしくない。GtkはC言語でインターフェースできるためScheme界隈ではよく実装される。

moshでの利用予定

wxブランチではwxPythonのようなwxWidgetsの完全なバインディングを提供する予定は無くて、次の目的に使う。

  • REPLにMathematica風のnotebookインターフェースを付ける

Racket(PLT Scheme)が既にこの目的のためにwxWidgets(の古いバージョン)を使っている。つまり手続きの結果をグラフやビットマップで可視化するために利用する。
残念ながらwxWidgetsのrich textはこの手のインタラクティブな作業には向かないので、多くは自前で実装することになりそう。

  • データエディタ

wxWidgetsは、表のエディタ(wxGrid)を既に備えているので、そのまま流用することで"ログファイルを表形式にしてGUI上に表示する"ようなスクリプトをCSVファイルやexcelを使わずに実現したい。
書いたスクリプトを他人に使わせる上で、データ入力は大きな問題なので。。
...平たく言えば、将来wxWidgetsをやめてもユーザが困らない程度の抽象化を行う。どちらにせよmoshはshellであるという宿命があるので、これらをTTYで実装する時期が来るように思える。