- - - - - - ----->

JX

他の GUI ツールキットとの比較
--------------------

多種多様の GUI ライブラリが存在します。 最良のものを選ぶのも、しばし難しい状況であります。このページでは、JX と他のライブラリとの違いについて説明いたします。.

ここに取り上げられているライブラリには、開発途上のものもあり、ここでの情報がl更新状況に追従していない場合もあります。もしくは、これらのライブラリに関するウェブサイトからの情報で、見逃してしまっているものも有るかも知れません。もし以上の点で、その様な事がありましたら、 ご連絡ください。

このページは'９９年８月３日に更新されました。.

はじめに

GUI ウィジェット群のみを提供する多くのライブラリとの違いは、JX が ドキュメント-ビュー・アーキテクチャーの設計に取り組んだ、完成されたアプイケーション・フレームワークであることです。このドキュメント とは、いろいろなファイル形式に対応したデータの集まりです。

JX は、ネットワークにも、多種多様なＸディスプレーへの接続にも対応しております。クライアント-サーバー・モデルを欲しない場合に便利であります。

JX 以外のライブラリでは、これらの機能は対応されていない場合もあり、御自身で構築される必要があります。これは、ライブラリ自身の目的をくつがえすものです。と言うのは、皆様自身で、欠けた機能を穴埋めしなければならないからです。JX のゴールは、商用ソフトウェアを書くのに必要な全ての機能とクオリティーを提供することです。そうすることで、ある特定分野でのみ必要とされる、又は、ある問題を解決する為に必要なコードを書くことに専念できるからです。 :ＪＸの最大の特長として、

 商用品質のソフトウェア を書くのにも JX であれば、ほんの少しの労力で行えると信じております。これは、プロジェクト達成時間の節約につながります。 モデル/ビュー/コントローラー・アーキテクチャー を固守する事で、相互に結びついたもの同士を失う事なく(例えバラバラに作成されたとしても)、一度作成されたプログラムの改良もメンテナンスも簡単にすることが出来ます。

もしあなたのプロジェクトに JX を採用することをお考えの場合、Cyrusoft が 採用した理由 に興味を持たれると思います。
 

--------

C++ toolkits

--------

Amulet

Amulet は、Ｃ＋＋上に構築され、バインドされた言語です。Objective C (Apple's Rhapsody) と比較されると良いでしょう。テイブル機能、３Ｄグラフィック、ネットワークはサポートされておらず、簡単なテキストエディタのみサポートされております。

1997年11月21日付けの 報告 によりますと、開発は終了したもようです。
しかしながら、Brad Myers によりますと OpenAmulet がユーザー・グループによりサポートされてる模様です。

fltk

fltk は、アプリケーション・フレームワークと言うよりも ウィジェット群の集まりです。メッセージの伝達方法は、仮想関数によるものではなく、callback と void* を使用しており、Ｃプログラマーにより設計された、Ｃ ツールキット と呼んで良いでしょう。テンプレートも多重継承も用いない事が、このライブラリの特長だとされています。 XForms ライブラリとの互換性を重視したのは明らかであり、以下の様な説明がされます。

彼らの主張は、このライブラリは小さく軽いものであります。 利用可能なウィジェット. は不足しており、それぞれの単一のウィジェットに内蔵されたイヴェント・ハンドラ関数が、整数値を受け渡すようになっており、それぞれの関数から呼び出されるイベントは、(マウスの位置やキーが押されたかなど)多くのパラメータを必要とします。イベントのパラメーターは、効果的にグローバルデータとして扱われますが、これは必要なものでなく、、既にリエントラントされているイベントをイベントループから阻止する事になります。ネットワーク、テイブル機能、プリント、テキスト編集等はサポートされておりません。 

FOX

FOX は、アプリケーション・フレームワークと言うよりも ウィジェット群の集まりです。Microsoft Foundation Classes (MFC) をベースにしており、そのターミノロジーから仮想関数の代りにメッセージマップを使用しているところまで、ドップリと漬かっています。

FOX と ＪＸ とでは、メーセージ伝達方法が同じではありません。FOXでは、ターゲット側をメッセージとして定義しており、それに対するそれぞれのソースと対をなしております。それぞれのソースは、それに対するターゲットからの適切なメッセージを知らなければならないのですが、ＪＸでは、ソース側をメッセージと定義し、ソース側は単純にメッセージをばら撒き、メセージとの連結を失うようにみえますが、ターゲット側がそれが何であろうとも適切な処置をします。.

FOX のメッセージは整数群であり、どちらにしても、void* に対しても、個々の関数呼び出しにしても、キャストが必要です。 JX では、オブジェクトをメセージとして送信するため、メセージを処理する場合、そこには全てが備わっています。 

Galaxy

Galaxy は基本設計からして優れたものでした。オブジェクト指向で、豊富は機能を持ち、クロスプラットフォーム対応のアプリケーションフレームワークでした。残念な事に、供給もとの会社は 消滅 してしまいました。 幸運なことに、JX は、 Galaxy が有するほぼ全ての機能を提供します。クロスプラットフォーム対応(Windows 95/98/NTバージョンを 開発中 です)、ディスプレー・ポストスクリプト対応、Unicode対応の３点だけ JX には欠けております。 Galaxy のある特定機能について興味があれば、 JX, が提供しておりますので、 問い合わせて下さい 。

Gtk--

Gtk-- は、 GTK+. 上のC++ラッパーです。他のライブラリとは違って、メセージシステムはC++ のオブジェクトです。

Qt

 Qt にあって JX にない機能とは、 JX にあって Qt にない機能とは、 JX を書き上げる前に、 Qt を使おうと考えたと思いますか? 

toad

toad は、アプリケーション・フレームワークと言うよりもウィジェット群の集まりです。幾つかのウィジェットを提供しますが、ドキュメント-ビュー・アーキテクチャー、ネットワーク、プリント、テイブル機能等はサポートされておらず、非常に限られた機能のテキスト編集がサポートされております。READMEファイルに述べてある"作者は、オブジェクト指向パラダイムに負担をかけたくない"と言う点には混乱させられます。Ｃ＋＋ライブラリを使用してるのに、非常に奇妙な感じがします。 

V

V はクロスプラットフォーム対応ですが、最小公約数的なアプローチなため、OS の基本的に必要とされる機能のみインプリメントされた状態です。 ある一定のルック・アンド・フィールに固守させられます。このためグラフィック・ウインドウ用のレイアウト・エディターを提供してません。ルック・アンド・フィールを変更する選択すら無いようです。

イベント・モデルは非常に原始的なもので、すべてのオブジェクトは、整数値のイベントとして直接的にメイン・ウインドウへ伝えられます。これらは、膨大な switch ステートメントとして処理されます。再利用可能なウィジェット グループの開発を妨げます。何故なら、そのウィンドウが全ての処理をしなければならないからです。

限られた機能のテキスト編集がサポートされておりますが、テイブル、ジオメトリ管理やスクロールですら、それぞれのウィジェット毎に、書き加えて行かなければなりません。メニューですら、その項目数に制限があります。

V は、教材用に設計されました。しかし、コーディング・スタイルは、メンテナンスが大変なものであり、生徒達がどれだけ有用なものを学んだかは、計り知れません。 

wxWindows

wxWindows は、非常に強力な、クロスプラットフォーム対応のアプリケーション・フレームワークです。Microsoft Foundation Classes (MFC)のプログラム・モデルとターミノロジー(分類)をベースにしております。

他のライブラリ上で実行可能な様に設計されたクロスプラットフォーム対応です。色々なライブラリ機能の重複点を基盤とする事から、最小公約数的なものに強いられてしまいます。この様に何層にも重ね合わされた結果、Xlib.上に直接構築されたライブラリと比べると、潜在的に重苦しく遅いものとなってしまったようです。

事実、はじめは  XForms 上に JX を構築する事から始めました。結局は、壁に突き当たりました。何故なら、イベント・ループすら所有できないからです。この様な多層ライブラリは、何かを強制的に保守しようとした時に、必ず壁に突き当ると思います。 

XVT

XVT は商用アプリケーション・フレームワークです。多くの点で、 JX は、XVT に似ていると言えます。しかし JX はより多くの機能を提供します。 (テイブルは別のアドオン・パッケージに含まれますが、XVT はコア・ライブラリに含まれておりません)。 JX は、オブジェクト指向言語の機能をフルに活用しておりますが、 XVT はタイプセイフ・オブジェクトの代りに、void* 経由でオブジェクト間のメーセージ転送を行います。 XVT にはサードパーティーのアドオン・ライブラリが存在し、非常にコスト高となりますが、JX は全てが一つのパッケージの中に集結しております。 

YACL

YACL はクロスプラットフォーム対応ですが、最小公約数的アプローチのため、ＯＳの提供する機能しか利用することができません。

Zinc

Zinc は、最小限のＡＰＩ機能を提供する商用、クロスプラットホーム・ライブラリです。OS上で提供する機能のみ使用可能です。 単に widget群のあつまりであり、アプリケーション・フレームワークではありません。
 

--------

C toolkits

--------

一般的には、違った言語で書かれたツールキットを比較するのはあまり妥当なことではありません。何故ならば、言語自体の特質にツールキットの設計が深く関わっており、ある特定のプロジェクトに使用される言語は、ツールキット以前に、長い期間使われているからです。しかしながら、それらが持っているありのままの機能を比較する事は出来ます。

個人的には、オブジェクト指向言語以外の言語を用いて、アプリケーションを書こうとは思いません。クラス、オブジェクト、インヘリタンス等の数え切れない程の御利益があるためです。 JX を書くのに、C++を選んだのは、既に明白な事ですが。

GTK+

GTK+ はアプリケーション・フレームワークと言うより ウィジェット セットの集まりです。非常に驚く程の ウィジェット群を提供してくれます。しかし直接的には、ドキュメント・ビュー・アーキテクチャーをサポートしてはくれません。３Ｄグラフィック、ネットワーク、プリント関連はサポートされておらず、テーブルも限られた機能でのみサポートされています。

Motif

Motif は商用 ウィジェット セットで、赤ん坊が取り扱う道具のようなルック・アンド・フィールです。非常にシンプルなウィジェットを提供しますが、ドキュメント・ビュー・アーキテクチャー、スタイル・テキスト、テーブル、プリント、３Ｄグラフィック、ネットワークはサポートれておりません。ウィジェット 属性を設定したり、取り出すためのインターフェースは驚く程、ギクシャクして扱いづらいものです。

LessTif は、ＧＰＬのもと Motif のインターフェース実装を目指したものです。 

XForms

XForms は、アプリケーション・フレームワークと言うよりも ウィジェット 群の集まりです。ドラッグ・アンド・ドロップ、３Ｄグラフィック、ネットワーク、プリント等はサポートれておらず、限られた範囲のテーブルとテキスト編集機能のみがサポートされています。
 
 

--------

Scripting languages

--------

スクリプト言語は、ある特有の仕事を容易にすることを目的とします。スクリプトは一般的にインタプリタ型であり、実行速度は、遅い場合が多く、たいていの場合、コンパイラ言語で書かれなければならないような、実行スピードを問題とされる要素が無い限り、GUI プログラミングに対しては問題はないと言えます。

スクリプト言語は、変数型のチェックが弱い事から、多くのエラーは、コンパイル時に、コンパイラによってチェックされるのではなく、実行時にプログラマーによってチェックされる事になります。これが小さなプログラムであれば、問題はないのですが、特にオリジナルの作者の代りに、ほかの誰かがそれをメンテナンスする場合、その大きなプログラムは悪夢となります。 

Tcl/Tk

Tcl/Tk は、 ウィジェット・セットであり、アプリケーション・フレームワークではありません。Drag&Drop、テーブル、ネットワークに対するサポートはありません。 Tcl/Tksend 命令は、 JX の JMDIServer によるサービスと同等のものです。Tcl/Tk は、自動的なジオメトリ・マネージャーを有せず、また、グラフィカルにウィンドウのレイアウトを行なう機能も提供されてません。それに加えて、スクロールすることも自動ではありません。

Tcl/Tk は、その Canvas ウィジェットを非常に売り物にしていますが、JX は、JXLayout ウィジェットにより、より強力な機能を提供します。JXLayout は、独自の形態を与えます。あなたが、 256色に限定されない各々のウィジェットを描画するコードを書くのなら、ペイント(bitmap)とドロー(オブジェクト)を提供します。Tcl/Tk Canvas のタッグシステムは、 JPtrArray<JLayoutWidget の派生クラス>を使うことで、同等なことが可能です。これは理論的には全く便利なものではないと思われるでしょう。オペレーター new のオブジェクトを作成した後、すぐに適切なリスト(s)に、単に各々のオブジェクトを加えることは、実際には、問題を引き起こしません。各々のリストに対し、ベースクラスは、そのリストの中の全てのオブジェクトによって要求される共通の機能を定義する為に作られます。

Brian Kernighan は、Tcl/Tk のメリットを強調すると同時に、そのデメリットについても 批評 を書いております。

JX Features Page へ