Ruby de GUI

初稿：2004-09-10

Ruby de GUI

たむらけんいち (tamura at ruby-lang dot org)

Ruby にまつわるえとせとら日記

2004 年 9 月 5 日

Ruby と GUI ライブラリ

ここでは Ruby から利用できる GUI ライブラリを紹介する。 その特徴と守備範囲を説明することで、ライブラリ選びの参考になれば幸いである。

紹介基準

Ruby のライブラリといえば、RAA だが、Library/GUI を見ると、2004-8-29 現在、31 のプロジェクトが登録されている。 この中には、RAA:fxirb のように FXRuby 用に拡張した IRB といった純粋な GUI ライブラリとは呼べないものも含まれている。他にも RAA:ruby-dialogs もコンソール上のツールなので、今回の紹介からは外させてもらった。

もちろん限られた時間でこれを書いてるので、私の興味あるモノになるというところも勘弁して欲しい。

動作環境について

今回紹介するライブラリの全てを動作確認した訳ではないことをまず述べておく。特に筆者は Macintosh 環境を持っていない。ネットで確認を依頼するなどした内容もある。

各ライブラリの紹介スペースでの動作環境だが、それぞれ

Win32
Windows 環境 :Windows9x、Windows2000、WindowsXP などを想定
X11
Linux、FreeBSD、Solaris などの Unix 系環境上での XFree86 に代表される X Window を想定
MacOSX
OSX 以降の Mac の Aqua上を想定。OSX には X Windowもあるがここでは通常のシステムのみ
MacOSClassic
OS9 以前の Mac の インターフェース上を想定

とする。もちろん環境として他にも BeOS (HAIKU) などの独自環境やフレームバッファ上 での描画などもあるので、あくまでも参考として考慮していただきたい。

既存の GUI ライブラリを利用するタイプ

このタイプは、C/C++ 用の GUI ライブラリを Ruby から利用できるようにしたものであり、ライブラリのインターフェースやクラスライブラリ (C++) が Ruby からどう見えるかがポイントである。

また、元ライブラリ自体のドキュメントが日本語対応なども含めて充実しているかなども重要である。

Ruby/Tk

  • site : 本体付属のため無し
  • RAA : 本体付属のため無し
  • needs : Tcl/Tk が必要
  • owner : Hidetoshi NAGAI (正確には現メンテナ)
  • screenshot :
  • GUI ビルダの有無 : RAA:specruby や SpecTix で Ruby のコードを出力させることが可能
  • 日本語対応 : Tcl/Tk の Version による機能を利用可能
Win32 X11 MacOSX MacOSClassic
○ ○ ○ ○

Ruby/Tk は Ruby の GUI ライブラリの中でもっとも長い歴史を持つ。最初の作者は、まつもとゆきひろ氏である。Tk は Tcl という言語から利用するための GUI ライブラリだったのだが、設計の良さと覚えることの少なさなどが相まって、他の言語からも使われる人気ものとなった。

Perl には Perl/Tk 、Python には Tkinter、と LL (Lightweighted Language = 軽量言語) なスクリプティング言語は Tk をサポートしている。ほとんどの Unix 系の OS は、Tcl/Tk がインストールされているため、ライブラリなどを別途用意しなくても良いこともメリットと呼べる。

Ruby/Tk については、「Ruby から Tcl を経由して Tk を制御している」「オブジェクト指向的じゃない」「単純な Widget しか用意されてない」「見た目が昔の X11 してる」という意見があるが、実はそれらのほとんどは最近の Ruby/Tk (あるいは、本家の Tcl/Tk にて) で対応済みだったりする。現在 Ruby/Tk のメンテナである永井氏はかなり精力的に上記問題に対してコミットしている。

Ruby/Tk については 1.8.2 に含まれる Tcl/Tk 拡張サポートまで 含めてもらえると嬉しいです。 これは、これまでの Ruby/Tk への批判の一つである「ウィジェット不足」への 回答の一つであると思ってます。

Tcl/Tk 拡張は各個にインストールしてもいいですが、ActiveTcl 版の バイナリパッケージをインストールしてそちらのライブラリをリンク するようにすれば大部分はすぐに使えるはずです。 一部のライブラリには ext/sample/tkextlib/ 以下にサンプルスクリプトも ありますので、ぜひ試してみてください。

なお、「外観が古くさい」という点は、Tcl/Tk8.5 以降で改善への動きがあります。 8.5a1 で、まず radiobutton と checkbutton での改善が行われたようです。

(永井氏の今回の執筆に対する反応より)

Ruby/Tk の魅力としては、何より構成が単純なため習得がある程度容易であることだろう。これは反対に Widgets の数の少なさや構成がオブジェクト指向的でないということの裏返しでもあるのだが。そして、日本語化されたドキュメントが豊富な点も挙げておきたい。その歴史の長さにより Tcl/Tk の書籍もたくさんある上、永井氏による Ruby/Tk256 本および Ruby アプリケーションプログラミングで、かなり詳細に解説されている。

また日本語 (多国語) の扱いについても永井氏にコメントをいただいたので、紹介しておく。

日本語対応については、現在の Ruby/Tk では環境の推定結果に基づいた コード変換処理が組み込まれてます。 ですから、日本語表示可能な Tcl/Tk (日本語版でも UTF-8 によるものでも) を使っているなら特に気にせずに表示可能なはずです。 逆に、例えば Tcl/Tk のデフォルトエンコーディングが euc-jp の 環境で直接 UTF-8 の文字列を与えるとかえって文字化けしてしまいます。

なお最新の Ruby/Tk では、エンコーディングが異なる文字列を混在させて 用いることができるような仕組みも組み込んであります。 もちろん、エンコード情報がなければどうしようもありませんから、 文字列クラスのサブクラスとしてエンコード情報付き文字列クラスを 作成し、それを扱うことができるようにしているわけです。

# 通常の文字列に @encoding というインスタンス変数を持たせ、 そこにエンコード情報を文字列で設定しておくだけでも OK です。

こうした文字列を扱う場合にはエンコーディングが何かを 気にする必要はありません。 そのまま Tk に渡してもらえればコード変換して表示します。

Ruby/Tk は現在進行形で進化中の GUI ライブラリであり、決して過去のものではないのだ。

Ruby-GNOME2

Win32 X11 MacOSX MacOSClassic
○ ○ × 1 ×

2

Ruby-GNOME2 は、主に X11 上でのデスクトップ統合環境である GNOME2 を構成する各ライブラリを Ruby から使うためのものである3。

GIMP 開発が始まりだった画面描画ツールキットである GTK の最新版である GTK+2.4 および GLib2 などの基本的なライブラリの Ruby ライブラリパッケージを ruby-gtk2 パッケージ、高性能キャンパスの Ruby/GnomeCanvas2、マルチメディアを扱う Ruby/GStreamer、HTML レンダリングエンジンである Ruby/GtkHtml2、パラメータデータの扱いをカプセル化する Ruby/GConf2 、GNOME パネルのための Ruby/PanelAppletなどまで含めたものを ruby-gnome2 パッケージと呼ぶ。豊富なライブラリ群に関しては、site にて内容を確認して欲しい。単に画面を作りたい程度であれば、ruby-gtk2 パッケージより Ruby/GTK2 を使えば OK である。

Ruby/GTK も、最初の作者はまつもとゆきひろ氏である。GTK+ 自身が C 言語によるオブジェクト指向的ライブラリとなっているので、Ruby と相性が良い。Widget の種類も たくさんある。

最近の Unix 互換環境では GNOME2 がデスクトップとなってる場合も 多くインストールに必要なライブラリも揃っていて、利用するのが比較的簡単だ。

Windows 環境においても、MS Windows 向けのバイナリがプロジェクトチームによって用意されているため、比較的簡単にインストールは可能だ。この場合、インストールする GNOME2 の環境によって、Ruby から利用できる部分は制限される。

また地域化 (L10n) や国際化 (I18n) に対するアドバンテージについて、プロジェクトリーダーであるむとう氏よりコメントをいただいたので、紹介しておく。

Ruby-GNOME2 では、Ruby-GetText-Package との併用で L10n が実現 可能ですし、UTF-8 で I18n の表示を可能にしています。 特にビルダーがあるものに関しては L10n がうまくできないものがあるんじゃ ないでしょうか。

# ビルダーがないものは Ruby-GetText-Package を使うことで きっと L10n できるでしょうけど

最後にライブラリとプロジェクトチームとの対応について説明しておこう。2002 年 11 月を最後に、Ruby/GTK および Ruby-GNOME はメンテナンスされていない (ruby-list:37857)。実は現在 Ruby-GNOME2 についての書籍は存在せず、すべてが Ruby/GTK に関するものなのである。GTK および GNOME は、Ver1.2 の次に Ver2.x となり GNOME2 で大幅な機能強化を行い関連ライブラリが増えた経緯がある。一例として現在の Linux ディストリビューションでは GTK+1.2x 系と GNOME2.x 系は並存しているが、メインは GNOME2 (GTK+2) へと移っている。

GNOME2 環境が一般的になるに従い、Ruby-GNOME2 で実装されたアプリケーションは増えてきており、これからも GUI 作成の定番として目が離せないと言えるだろう。

QTRuby

Win32 X11 MacOSX MacOSClassic
○ ○ × ×

QTRuby は GNOME と双璧をなす統合デスクトップ環境である KDE の基本ライブラリである。 RAA:ruby-qt2 (Qt.2.x) / RAA:ruby-qt (Qt.1.4x) は前のバージョン用のものなので、注意のこと。シャープの Linux Zaurus 上の Qt embedded で動く RAA:ruby-qte もある。

QTRuby は、Smoke (Scripting Meta Object Kompiler Engine) という Qt/KDE 用フレームワークに用意された仕組みを利用しているようだが、残念ながら筆者は触った経験がないので、これ以上何も書けない。

Ruby/Qt2 などの開発者である堀江氏よりコメントをいただけたので紹介する。

qt1,qt2 のラッパーを作成していた関係で少しいじってみたのですが、大変完成度が高くほぼ実 用レベルに達していると思います。

主な特徴としては、

1.Qt ライブラリーの豊富なクラスがほぼ全て利用できる (みたい)。

  1. 日本語も $KCODE=”EUC” とすると、問題なく使用できる(何も指定しないときは UTF-8)。

3.Qt がもともと C++ のライブラリーなので Ruby との相性もそんなに悪くない (と思う) 。

なお、QT Ruby の Web サイトにある Korundom は www.kde.org の kdebinding の cvs パッケージの中にあります。 (ftp://ftp.kde.org/pub/kde/unstable/snapshots/ ; こちらもお薦めです。)

また Windows での状況もコメントしていただけた。

なお、QT Ruby の Win32 対応ですが、私の見た限り公式な表明はないようです。

Qt の Windows 版は一応商用で (しかもかなり高い)、ver 3 については本の付録として non-commercial version が入手できます。これを用いて以前 Qt Ruby を コンパイルしたことがあるのですが、完全にはうまくいきませんでした (一部は動いたのですが。ま たやってみます)。 もっとも、cygwin や qt-win32 のような GPL 版 qt を Windows に移植しようというプロジェクトもかなり動いてきたので、比較的簡単に移植できる ようになるかも知れません。ちなみに、MacOSX で x なのですが、X Window System をいれると KDE も動いてしまうようなので、QT Ruby も動くような気が……

(これは対応と言わないのかも？) ほかの Unix 系 GUI もそうですよね。

上記コメントの本とは C++ GUI Programming with Qt3 ,Pearson Education, Inc., 2004 (amazon.com) である。

FXRuby

Win32 X11 MacOSX MacOSClassic
○ ○ × ×

FXRuby はあまり日本ではなじみがないかも知れないが、海外では Windows 用パッケージとして定番の One-Click Ruby Installer (旧 Ruby Installer for Windows) に含まれている4。外見が Windows ライクということも手伝って、かなり敷居が低い。

特徴としては、C++ で構築されたライブラリを上手に Ruby で wrap しているところか。クラスの継承やメッセージの投げ方などを上手に利用すると短いコーディングで GUI が書ける。

もっとも、FXRuby が利用している FOX が多国語化を現状で対応していないため、表示に関しては、UTF-8 でコーディングすれば大丈夫だが、仮名漢字変換などではパッチを当ててコンパイルする必要がある。

fox-unicode 開発および、FXRuby に詳しい、ひだか氏からのコメントを紹介する。

FOXは、X11でもWindowsでも同じ外観・操作感のアプリケーションを 作ることができる高機能なツールキットです。

FXRubyによって、Rubyから呼び出して利用することができます。 日本語対応についてですが、FOX + FXRubyは、UNICODEベースで動作する ので、日本語の表示だけであればそれなりに可能ですが、日本語の入力に ついては対応していないので、非公式パッチが必要です。

私はそのパッチを管理していることになっているのですが、忙しくて ここのところ全く更新できていなくて申し訳ないです。

Ruby/FLTK

Win32 X11 MacOSX MacOSClassic
○ ○ × ×

実は、Ruby/FLTK は現在メンテナンスされていない。 作者である立石氏からのコメントを紹介しよう。

Ruby/FLTK の開発動機は、もともとは C++ で拡張ライブラリを作ろうという漠然と したもので、特に C++ の抽象仮想関数などをうまく Ruby 側で扱いたいという目的 がありました。

そのため、Ruby/FLTK では、C++ における抽象仮想関数を含む抽象クラスを、Ruby 側で継承して、抽象仮想関数の実装を行うことができます。また、同様の仕組み で、Ruby 側で継承したクラスも、あたかも C++ のレベルで継承を行ったように FLTK の処理に反映されるようにしていて、かつ、FLTK とのクラス階層も一致させてい ます。苦労したのは、開発当初に C++ での拡張ライブラリ作成の実績がほとんどな いことでした。現在は、開発を行っていません。

FLTK 自体が日本語の扱いに難があることなどからも現在 Ruby/FLTK を選択する機会は 少ないかもしれない。ただ上記 C++ での Ruby 拡張ライブラリ実装や抽象クラスの Ruby 側 からの扱いなどは、FXRuby などに受け継がれていると思われる。

そもそも FLTK 自体がかなり軽量なライブラリであり、規模の小ささと構成のシンプルさは、これから GUI ライブラリに取り組もうと考える人への良い題材となるのではないだろうか。

wxRuby

Win32 X11 MacOSX MacOSClassic
○ ○ ○ △ 5

wxRuby は、現在の GUI ライブラリの中では動作環境が一番多い。その理由は、wxWidgets の構造にある。wxWidgets は実際の画面描画を、それぞれの環境の native ライブラリに任せている。Windows では、Win32API、X11 では、Motif や GTK+、Macintosh では、Quartz、Cocoa である。

wxWidgets のクラスライブラリが膨大なことから、wxRuby はいまひとつ安定性には欠ける部分や多国語の扱いなどで難があるのも事実だ。同じ LL として先行している Python の wxWidgets binding である wxPython の screenshot や wxPython で実装されている GUI ビルダの wxGlade の完成度にいつか追いつけるのだろうか。

wxRuby としては、日本語の資料は皆無なため、C++ から wxWidget を使う資料を読み解いていくしかないのもツライところである。

マルチプラットフォーム環境を利用するタイプ

このタイプは既に別言語 (C など) にて、マルチプラットフォーム対応ができている統合環境をそのまま Ruby から利用するものである。

Apollo

  • site : http://www.moriq.com/apollo/
  • RAA:apollo
  • needs : 動作させるのに Runtime が必要
  • owner : moriq
  • screenshot :
  • GUI ビルダの有無 : Delphi のフォームデザイナで作ったデータが使える
  • 日本語対応 : 特に意識する必要なし
Win32 X11 MacOSX MacOSClassic
○ × × ×

6

Apollo のサイトにて作者のもりきゅう氏は、こう述べている。

Delphi と Ruby を結びつける機構全体を総称して Apollo と呼んでいます。

Apollo の機能は GUI だけに留まらない。DB アクセスなど Delphi が利用できるものの全てを Ruby からも利用できるのである。Delphi の VCL からサードパーティのコントロールまで例外はない。

Apollo の面白い点は以上の逆側の機能も用意している点である。つまり Delphi からも Ruby の機能が利用できるようになっている。Phi 拡張ライブラリを書くためには、Delphi <-> Ruby 間の値変換などが必要である。

Apollo は、MS Windows 版の Ruby 自体を含むパッケージも提供されるので、インストールなどの手間はあまりかからない。 Linux 上の Delphi 互換環境である Kylix が発表されて数年経つが、環境を作ったり安定して動作させるのは難しいようだ。その理由として、もりきゅう氏は次のように述べている。

VCL (Delphi のライブラリ。Win32 に依存している) と CLX (Delphi と Kylix で共通な ライブラリ。Qt のラッパー) に完全な互換性がないことと、Kylix 自体が安定して いなかったことがあります。

Delphi から Kylix へのプログラムの移植は、VCL から CLX への移行後、Windows から Linux へ移行する、という二段階の手順を踏まなければならないのですが、VCL 版 の開発が続く現状では Kylix への移植に時間をかけられないのが実情です。また、 Kylix には共有オブジェクトの扱いに不具合があり (最新版では改善されていると 思いますが)、Kylix2 での開発では原因の切り分けと対応に苦労しました。 時間をかければ Kylix 版 Apollo も実現できるので、対応していく予定です。でも、 今後対応するならやっぱり Lazarus というか FreePascal がいいのかなあ。

WideStudio

  • site : http://www.widestudio.org/
  • RAA : なし
  • needs : 動作させるのに Runtime が必要。
  • OS : Unix、Windows
  • owner : Shun-ichi Hirabayashi
  • screenshot : site のチュートリアルなどを参照
  • GUI ビルダの有無 : アプリケーションビルダにより可能
  • 日本語対応 : 独自のマルチエンコーディング対応
Win32 X11 MacOSX MacOSClassic
○ ○ × ×

7

WideStudio の特徴に説明があるが、一番の特徴はやはり、「統一されたデスクトップアプリケーション開発環境」だと思われる。OS に依存せずWideStudio独自の外観が提供され、開発時もほぼ同じ環境で作業が可能となる。C/C++、Perl、Python、Ruby に対応しているが、これも外観同様各言語の特色よりも WideStudioとしてのスタイルを優先させている。(set_hoge/get_hoge といった Java/C++ 系のプロパティアクセスなど)

各 OS / 言語の特徴を抑えて、共通のスタイルで開発しマルチプラットフォームで動作させる必然性があるような場合 WideStudio は、かなりの威力を発揮するだろう。

OS の基盤 API 上のライブラリを利用するタイプ

このタイプは、OS が備えている API を利用するので、見た目が通常のものと変わらないという利点がある。ただしクラス構成などがオブジェクト指向的でなかった場合、Ruby 側のライブラリがそれをどう吸収しているかという問題がある。

VisualuRuby

Win32 X11 MacOSX MacOSClassic
○ × × ×

Windows 上では、ほぼ定番と呼べるライブラリ。swin はイベントなどのための拡張ライブラリ、vruby はクラス群の Ruby ライブラリである。VisualuRuby 自体で作られたフォームデザイナで画面が作れ、Exerb (RAA:exerb) を利用すると、複数ファイルと Ruby 実行ファイルである ruby(w).exe + msvcrt-ruby18.dll を一つの実行ファイルにまとめることができるのも大きな特徴。

それなりに利用され、ドキュメントも探しやすいなど環境を Windows に限れば8使いやすいライブラリである。

RubyCocoa

Win32 X11 MacOSX MacOSClassic
× × ○ ×

上記サイトには、RubyCocoa の説明としてこう書かれている。

RubyCocoa は、オブジェクト指向スクリプト言語 Ruby での Cocoa プログラミングを可能とする、Mac OS X のフレームワークです。

OS 固有の API を利用できること自体は、Windows における VisualuRuby 同様だが、Cocoa の場合オブジェクト指向がそこにあり、Objective-C をスクリプト内に一緒に書けるらしい。

残念ながら、筆者は Macintosh に嫌われてる身で、手元にも環境がないため、これ以上のことは書くことができない。

番外編

ここまでの範疇に収まらないものを紹介する。

rjb

Win32 X11 MacOSX MacOSClassic
○ ○ ○ ？

rjb とは Ruby Java Bridge の略である。arton 氏の ruby-list への投稿 (ruby-list:39755) より引用する。

rjb という ruby と Java のブリッジを作ったので RAA に登録しました。 既に RAA には rjava というブリッジが登録されていますが、rjb は JNI を利用して同 一プロセス内で行き来するところが特徴です。なお Java 側の異なる複数のスレッ ドから Ruby を呼び出すことはできません。

rjb は開発開始から日が浅いということもあって、まだこなれていない部分もあるが ActiveScriptRuby の arton 氏が創っているという点でも注目のプロジェクトである。Ruby + WIN32OLE + COM という組み合わせだが、Ruby + rjb + JavaClass と置き換えることが可能だと思う。

作者の arton 氏からコメントをいただいたので紹介する。

アピール

  1. JDBC 知っているから今更 DBI 覚えるよりも、JDBC が使いたいなぁとか

  2. JUnit 使っていて、別に同じ言語でユニットテストを書かなくても良いのでは (Ruby なら楽だし) とか

  3. どうも ASR が Win32 でしか動かないのは気に食わんとか

  4. Java のビジネスロジックのクラス (static void main を持たない) をシェル から使いたいとか

もろもろの欲望を満たすために始めたプロジェクトです。 しかし、3. の野望は早くも Mac と Linux の前に脆くも崩れ落ちてしまいました (AWT/Swing を使わなければ OK なわけですが)。

苦労話

最初、Win32 で JNI の呼び出しをすべてオフセットを元にした一つの呼び出しにま とめていて、我ながらすっきり書けたと思っていたら、ビッグエンディアン (SPARC) とか gcc とか (VC++ とスタックの戻し方が異なる) が出てきて結局、 switch 文の嵐になってしまったりとか、が苦労した点かな。

でも、個人的にはきれいなソースだと思うので、是非見てやってください。

現状の rjb は、フィールドにアクセスできないという点と Java の GUI ライブラリである Swing を利用する際に環境を選ぶということが報告されている。9 もし軽量な SWT 辺りが他の OS の JVM 上でもブリッジできるようになれば、Ruby と Java を適材適所に使うといったハイブリッドな開発が可能になるかもしれない。

Ruby/WebDialogs

Ruby/WebDialogs はいろいろな意味でユニークな GUI ライブラリである。まず拡張ライブラリではない。

ではどうやって GUI を表示させるかというと Web ブラウザと HTTP でやりとりすることによって、表示は HTML + CSS、イベントは Javascript 経由で受け取る。ある意味簡易 CGI なのである。仕組みとしては、DIV RAA:div が近いといえるだろう。ただし、Ruby/WebDialogs は localhost だけに限定したフレームワークでファイルアクセスなどもカプセル化している。そして依存ライブラリが必要ない。

部品の表示やイベントは XML で記述し、メソッドと結びつける方式である。Windows 環境では実行すると自動的に Web ブラウザが起動し画面が表示される。Linux だとコンソールに URL が表示されるので、そこにアクセスする必要がある。

発想のユニークさ、仮想化されたモデル、実行環境を選ばないなど他とは違うライブラリである。上記サイトは英語だが図式された仕組みやサンプルコード、snapshot があるので一読をお勧めする。

終わりに代えて

本稿は、Ruby GUI ライブラリに inspire されたことをまず記しておく。

MacOSX 上での最新の Ruby/Tk の状況が判らないとぐちっていたら、救いの手を差し伸べてくれた mput 氏にも感謝する。

それから本稿に対するコメントをいただいた GUI ライブラリの関係者の方々、勝手なスケジュールで押し付けてしまってごめんなさい。

その他の GUI ライブラリについて解説しているページもここで紹介しておこう。

次回予告

本稿は結構なボリュームになったが、それでもひとつひとつのライブラリの紹介としては、満足な内容ではない。次回 (があれば) からは、二つずつくらい取り上げてコードも含めた掘り下げた内容にしたいと考えている。

もちろん「俺が使った経験で書いてやるぜ」とか「俺が作ったライブラリは俺が一番詳しいぜ」という申し出は大歓迎である。次回はこれを読んだあなたの番かも知れない。

本稿に対する質問や感想を是非、ご自分の Weblog で表明したり、Wiki に書き込んだりして欲しい。

著者について

tamura.jpg たむらは、なんちゃって IT 企業に生息する退役エンジニアです。最初に Ruby と出会ったのは、1996 年で、NIFTY-Serve (現 @nifty) の会議室でした。それ以降、こっそり仕事で使ったり、雑誌などに寄稿したり、 えとせとらという日記に 6 歳になる長男と 3 歳の双子のことを書いたりしています。本当は、仮面ライダーブレイドよりもデカレンジャーの方が好きです。

著者の連絡先は tamura at ruby-lang dot org です。

  1. OS X での native 実装としては、http://gtk-osx.sourceforge.net/ があるが動作未確認 ↩

  2. GTK は X11 を介さずに例えば FrameBuffer 上でも動作するのでそのような環境でも理屈では Ruby/GTK2 は動くはず ↩

  3. Ruby/GNOME2 だと libgnome などの拡張ライブラリを指すため、Ruby-GNOME2 なのである。って私もよく間違える ↩

  4. ちなみに、Tcl/Tk (8.3) 込みで、Ruby/Tk も使える ↩

  5. wxWidgets、Ruby どちらもあるが、wxRuby が動くかは未確認 ↩

  6. Linux 上の Kylix が Delphi 互換環境なので対応中 ↩

  7. Linux 上のエミュレータ上で開発し、BTRON/T-Engine 動作可能だが、Ruby で開発可能かは不明 ↩

  8. 筆者は、遊びで WINE 上で動くのを確認したことがある ↩

  9. 具体的には Win32 と Solaris でしか動作しない ↩