|
|
Standard Widget Toolkit は通称 SWT と呼ばれ、Java 言語のためのグラフィカルユーザインターフェイスツールキッド(graphical-user-interface(GUI) toolkit)です。EclipseプロジェクトにはEclipse全共通のツールプラットフォームをホストするオペレーティングシステムのネイティブユーザーインターフェイスファシリティ(native-user-interface-facility)に対するアクセスを提供するものがありますがその開発者たちによってこのSWTは創生されました。さらに知りたい場合にはhttp://www.eclipse.org/ を参照。
Eclipse本家のページ(http://www.eclipse.org/) のSWT component home pageには以下のようにSWTについて書かれています。
『SWT component is designed to provided efficient, portable access to the
user interface facilities of the operating systems on which it is implemented.
』
（SWT コンポーネントはそれを実装するオペレーティングシステムのユーザインターフェイスファシリティに対して効果的かつ移植性のあるアクセスを提供できるよう設計されています）
これはどこにでも見られるSWTのデザインフィロソフィ（設計に対する哲学）を表したものですがまさにそのとおりです。
確かになぜSWTは効果的なのかを表している理由の一部として基礎となるオペレーティングシステムのユーザインターフェイスファシリティの最上位に位置する圧倒的に互換性にあるレイヤーだからです。このリアルな作業の大部分はオペレーティングシステムのベンダー（マイクロソフト、アップル、ＩＢＭなど）が実装したプラットフォームに独特のコードを高度に最適化して行われます。しかしSWTにはそれ以上にすごいことがあります。それはランニングプログラムとオペレーティングシステムの間の余分なオーバーヘッドを置くことを可能な最大限まで減らしているということです。例えばSWTはAWT同等のレイヤーで見られるような分かれた内部の実装の階層を持っていません。これはすべてのpublic
なエントリーポイントから無目的のレイヤーを取り除きライブラリのサイズを飛躍的に減らします。しかしこの戦略をとってしまったことでSWTの実装（通称
： ports といわれる）は全てのプラットフォーム上に同じ実装の階層の形を持ちportsの内部間で共有できるところはほとんどないという矛盾点が生まれました。これはSWTの内部設計に何かしら挑戦を突きつけましたがその後、実際にはこれが重大な問題でないということがわかりました。
SWTの実装はメジャーなデスクトップのオペレーティングシステムの全ておよびあるハンドルされたデバイス（マウス、モニタ、プリンタ、キーボードなど）に対して利用することができます。時間がたつにつれそのプラットフォーム独特ゆえにSWTのフル装備を妨げているプラットフォームの中でも欠落した機能性の領域はその機能のエミュレートしたもの（エミュレート版）を提供することによってカバーされています。このエミュレート版を用いるとSWTのランニングの最初のportを取得するタスクが簡略化されますがそのようなエミュレートは細部まで徐々に増えています。
SWTが効率の良さを維持しているもうひとつの手段があります。それは基礎となるオペレーティングシステムでの固定された根本的な制約に対して試みようとする罠を避けていることです。SWTではこれが目に見える形で現れている3つの重要なことがあります。
| 1. |
SWT API はモダンなオペレーションシステムすべてに共通な制約を考慮して設計されています。この例としてウィジェット(Widget)へのアクセスが制限つきなのか許可されているのかといった標準的なオペレーティングシステムの制約をモデル化する優れたユーザインターフェイススレッドの概念があげられます。 |
| 2. |
SWT API はそのプラットフォームに特別な制約があった場合にはできるぎり多くのアプリケーションが接触しない範囲内でそれを許可します。例えば、多くのオペレーションシステムは単一のテキストの描写呼出しに対してパスすることができるテキストの量について制限を持っています。あるプラットフォームではこれは文字数に基づいています。またあるプラットフォームではそれは描写された結果で占められるピクセル数に基づいています。このリミットは一般的にかなり大きく例えばあるプラットフォームでは32768ピクセルもあり多くのアプリケーションは影響を受けることはまずありえないくらいです。それゆえ、SWT
はパスされるテキストの量を制約することもないしリミットあたりで動かそうとすることもありません。 |
| 3. |
SWTが提供する機能のいくつかはすべてのプラットフォームでは利用することができません。これはSWTが優れた移植性を歌っているのでにカウンターを食らったように聞こえますが、SWTの設計者はSWTが各プラットフォームに共通した最大限の機能の特徴以上のものを提供することが重要だと考えたからです。このため、API はプログラマーがプラットフォーム独特の機能の特徴を使用することができるようにしています。このケースでは、SWTの実装をプラットフォーム独特の機能の特徴を使用せずにより一般的なものにしたいときにはそれのみを行うこともできます。さもなければそのリクエストは無視されます。例えばあるプラットフォームではボタンを３次元の外観あるいは２次元のFlatな外観で描写することができます。SWTはもし利用できるのであればこれらの２つのスタイルへのアクセスを提供しています。プラットフォームの中にはその能力がないものもあるのでその場合にはSWTは単にデフォルトのスタイルを用いてすべてのボタンを描写します。 |
このように潜在的なプラットフォームに特殊な振舞いのあるソースにもかかわらず、複数のオペレーションシステム上で動くSWTアプリケーションを書くことは難しくありません。これはEclipseがuniversal
-tool-platform （全てのプラットフォームで動作可能なツール）であることが非常にわかりやすい例です。SWTは簡単なテキストエディタから開発環境およびバーティカル・マーケットアプリケーション(特定産業あるいは業界団体のニーズに合わせて作られたアプリケーションをいう)
まで幅広い範囲でアプリケーションに使用されます。プラットフォームに特別な機能(それを使用することをプログラマーが要求していない）へのアクセスを許可することによって、プログラマーが特別に重要視しているプラットフォームを最適化したものを提供するのかあるいは、どのプラットフォームでも同じ能力をもったものを提供するのかを選択することができます。
|
■ Look and Feel (ルック＆フィール ： 操作画面の見た目や操作感）
|
SWTの本質的にネイティブなウィジェットでビルドされたアプリケーションはそれを動かすプラットフォームでの外観と振舞いをとります。それはウィジェットの実装がオペレーションシステムのベンダーが書いたプラットフォーム独特のコードによって提供されているからです。SWT
API を用いれば簡単にサポートされたプラットフォーム上で動くアプリケーションを作成することができますが、搭載しようしているそれぞれのプラットフォーム上でアプリケーションをテストすることは重要なことです。アプリケーションのルック＆フィールの基準は以下の方法でのいづれかあるいは全てでありこれを満たすためにウィジェットが変化して期待どうりのルック＆フィールを持ったアプリケーションになります。
| ○ |
ウィジェットの標準的なサイズはさまざまです。すべてのプラットフォームはプログラミングガイドに沿って、あるいはAPIで提供されるものに沿って、それぞれのウィジェットに適したサイズを指定しています。SWTはウィジェットに対して好ましいサイズ(prefered
size) を計算するときにはこの情報を使用します。 |
| ○ |
あるいくつかの場合においては、プラットフォームに特別なサイズの制約が適用されます。例えば、Microsoft-Windows ではアプリケーションはcombo
box (コンボボックス）の高さを変更することはできませんが、ＳＷＴもまたWindows上では表示されればこのように振舞います。 |
| ○ |
標準のユーザインターフェイスエレメント（メニューなど）の中には位置(location)が変化する可能性があるものもあります。これにもっとも当てはまる例としてメニューバーがあります。メニューバーはマッキントッシュではスクリーンのトップに現れますが、他のすべてのプラットフォームではそれぞれのアプリケーションウィンドウ内に現れます。 |
| ○ |
実際には、ウィジェットの振舞いでさえ変化する可能性があります。例えばMicrosoft-Windowsのラジオボタンのケースです。ラジオボタンはフォーカスを与えられればいつでもユーザインターフェイス内で選択されたようになる
『特徴(feature)』 があります。SWTはあたかもユーザが明示的にボタンを選択したかのようにアプリケーションが振舞うようWindows上でマッチングした選択イベントを発生させます。プログラマーはこのことに関して特別なコードを書いてハンドリングする必要はまったくありません。 |
一般的に、プラットフォーム独特の振舞いの程度の差はSWTの実装で、すなわちプラットフォーム独特の外観を移植性のあるAPI（上記に述べたWindowsのラジオボタンで行われるようなもの）の立場でモデリングするのか、あるいは違いを表現するために新規に導入した抽象化されたものを用いるのかでハンドルされます。例えば、SWT.MenuDetect
イベントはポップアップメニューをリクエストするためにユーザが適切なアクションを行うよう指示するため導入されました。この操作のために要求されるボタンやキーのためのシーケンス（順序）はプラットフォームによって実にさまざまですが、移植性のあるSWTアプリケーションでは単純にSWT.MenuDetect
イベントを検知するコードを書けばこれができてしまいます。
サイズの違いやサイズの制約、位置(location) での違いといった外観でのプラットフォーム独特の差をハンドルするためにSWTはレイアウトに基づきダイナミックに位置決めやサイズ変更を行うパワフルなフレームワークを提供しています。レイアウトをウィジェットのコレクションと関連付けることにより、それらをさまざまな種類の抽象的な立場でアレンジできるようになりました。これらの制約内では、レイアウトとウィジェットは特別にコードを要求することなしに協力して期待どおりにプラットフォームの外観が維持されるよう保証しています。
|
■ Custom Widget (カスタムウィジェット）
|
Eclipseの開発途上で、SWTの性質に影響を与える2つの問題がカバーされなくなりました。
| 1. |
モダンな開発ツール(modern-development tools) のユーザインターフェイスで人々が期待する特徴のなかのいくつかはどのプラットフォームでも利用できるあらゆるネイティブなウィジェットを用いても提供することができない。 |
| 2. |
Eclipseをよりはっきりしたものにしてすべて独自のスタイルを与えられるように、ユーザインターフェイスエレメントのいくつかはすべてのプラットフォームで同じ外観を維持するために必要である。 |
これらの問題はどちらもSWTのネイティブウィジェットをベースとした能力については扱っていません。そこで custom-widgets-package （カスタムウィジェットパッケージ）と呼ばれるセットのサポートクラス群がEclipseの特別な必要性からデザインされました。これらのクラス群は何もほかの新たなルーティンを必要とせず既存のSWT
APIと全く同じ立場で実装することができます。これらは org.eclipse.swt.custom パッケージで見ることができます。
カスタムウィジェットパッケージ はEclipseのユーザインターフェイスの基礎とはなっていないことに注意することが重要です。Eclipseで見るものの多く・・・Shells,
trees, tables, lists, textフィールド, labels menu-bars, menus, tool-bars, dialogs,
scroll-bars, progress-bars, などはネイティブウィジェットから作成されます。したがってEclipseは大体はそのプラットフォームのルック＆フィールをとります。そこに着氷してカスタムウィジェットパッケージはEclipse
らしくするためのユーザインターフェイスを提供します。
カスタムウィジェットクラスはEclipseのために作成されたという事実にもかかわらず、それらは一般的に役に立つように設計されています。もしもプログラマーがネイティブウィジェットが提供しない特徴(feature)
を探していてウィジェットの外観の結果が必ずしもプラットフォームのルック＆フィールにマッチしなくてもよいのであればカスタムウィジェットパッケージのクラス群をチェックしてみる価値は十分にあります。カスタムウィジェットパッケージのクラス群の中には以下に述べるようなものを含んでいるものがあります。
| ○ |
パワフルなテキストエディタフレームワーク（StyledText) |
| ○ |
tableやtreeに対して編集可能なフィールドを加えることに対するサポート(ControlEditor) |
| ○ |
プラットフォームのウィジェットベースとしたLabels, combo-boxs, tabbed-viewsのある機能の限界を超えることができるそれぞれ、CLabel,
CCombo, CTabFolder |
| ○ |
一般のコーディングパターンを単純化するためのツール、たとえばresizing(SashForm), Scroll-subviewers(ScrolledComposite),
アクティビティの表示（BusyIndicator), ユーザインターフェイスの同じ領域を占めるウィジェットの『stack(スタック）』の作成(StackLayout) |
上に述べたように、カスタムウィジェットパッケージは既存のSWT APIと全く同じ立場で実装することができます。
SWTはIBMのRational Division内のグループ・・・IBMのVisualAge/Smalltalk の製品のためのユーザインターフェイスを実装することに対して責任を担っていた、Ｏbject
Technology International, Inc.(OTI)によって作成されました。SWTのデザインフィロソフィはVisualAge/Smalltalkのワークでの本質的なものを持っていて順を追ってこのことについて手短に話をしていきます。
VisualAge/Smalltalkの作成時には、多くのSmalltalkの実装はただ単にグラフィックの原始的なもの(BitBlt)でドローされるユーザインターフェイスを使用していました。これを行うことによってSmalltalkの環境はユーザのプレゼンテーション用での完全なコントロールを持っていてそのその当時としては究極の傑作品とも言える能力をもっていました。しかし別の面を見てみると
Smalltalkプログラムは他のネイティブなプラットフォームのアプリケーションに比べ見た目で違和感があり、また連携も何もありませんでした。それぞれのプラットフォーム上でネイティブなウィジェットの外観をエミュレートすることができるようにするため、Smalltalkのコードが書かれるように、『プラグできる』
標準のSmalltalkのユーザインターフェイスを拡張しようとする試みが行われました。これらはある程度は功を奏しましたがユーザが違いを区別できないポイントにに関しては全然うまくいきませんでした。ユーザインターフェイスを使用してビルドされたアプリケーションは少なくとも以下の３つの手段で失敗してしまいました。
| 1. |
スクローリングやタイピングといったよく行われる相互作用がSmalltalk のアプリケーションではネイティブなアプリケーションに比べ違和感を感じました。これをみたユーザはアプリケーションが際立って違和感があったときよりもアプリケーションがネイティブなアプリケーションもどきのときによりいらいらしてしまいました。 |
| 2. |
相互作用に依存するネイティブなオペレーションシステムの特徴(fatures) ・・・ 例えばドラッグ＆ドロップのサポート、文書の埋込み、国際的な多言語サポート が利用できないかあるいは完全にはサポートされないままでいました。 |
| 3. |
ネイティブオペレーティングシステムの新たなリリースがでると、Smalltalkは古いルック&フィールのためのコードのままで走らせていたので外観が変わってSmalltalkが時代遅れのアプリケーションのように感じました。 |
Smalltalk の開発者たちは、ピュアなオブジェクトと起源としたプログラミング、garbage-collection, pointer-safety(ポインタの安全性）、プラットフォームを横断する移植性、統合された開発およびそのデバッギング（サポートの代わりとなるhotなコード付）、ごくわずかだが命名できること、といった多くの先進的な能力のある環境が提供されているのにもかかわらず、これらのユーザインターフェイスの問題があるのははより大きなソフト開発者たちのコミュニティ内でのSmalltalkの受け入れを著しく制限してしているからだと声を高めました。この問題を解決するために、エミュレートではなく、ネイティブウィジェットのコードを用いたSmalltalk
ユーザインターフェイスの創作が必要とされました。
この最初の具現化はSmalltalk/V Mac product のためのユーザインターフェイスをベースにした簡単なネイティブウィジェットを実装してOTI
で行われました。用いた実装のための戦略はできるだけMacintoshのオペレーションシステムに近づこうとし、ネイティブウィジェットおよびほかのAPIのセットは既存のSmalltalk/V
でのGUIでの要求に制限するといったものでしたが、ネイティブなウィジェットからSmalltalkのユーザインターフェイスをビルドすれば実用的なものになるということがはっきりと示されました。OS/2やWindowsに対しても同様のことが行われました。
VisualAge/Smalltalk のユーザインターフェイスは、Common Widgets と呼ばれ、Smalltalk/V で用いられたのと同様の戦略を用いて実装されましたが、少なくとも次の2つの興味深いことでSmalltalk/Vのときと異なるものでした。
| 1. |
Common Widgets API は歴史的なSmalltalk ユーザインターフェイスよりもむしろその日の最初のGUIライブラリでモデル化されました。これはAPIがより広範囲の開発者に対してもっと慣れ親しんでもらうこと、およびSmalltalk
ユーザインターフェイスクラス群と基礎となるネイティブウィジェットとの間のマッピングがより単純化されたことを意味します。 |
| 2. |
Common Widgets はどのようにオペレーティングシステムのAPI に対してインターフェイスがj実装されるべきかの一貫性のある、明確に定義されたルールがあります。これらはオペレーティングシステムのAPIの機能と構造、およびそれらをモデル化したSmalltalkのコードが同じネーミングと引数を持つことを保証することを含みます。 |
VisualAge/Smalltalk はすべてのサポートされたプラットフォーム（Microsoft Windows 3.11, 95, NT3.51
および NT 4.0, OS/2 Wrap 3.0 , 4.0を, X/Motif) を横断するすぐれた移植性を提供しました。MacOS や
OpenLookに対する実装もまた始まりましたが完全ではありませんでした。その当時、OTIはそれらに対して製品化する価値のあるようなビジネスケースを一つも持っていませんでした。
X/Motif でないさまざまな実装関連のタスクを単純化するために、全く別のレイヤー、いわゆる OSWidget レイヤーがよりいっそうWindowsやOS/2のプログラミングのためのモデルにマッチするように構築されました。Common Widgets APIはこのレイヤーの観点から実装され、各プラットフォーム上で次々と実装されていきました。
Java が日に日に勢いが増して知れ渡るころまでには、VisualAge/Smalltalk は堅牢で成熟したプロダクトになっていました。しかし、最初は完全に理にかなっているように思われていた設計段階で決定したことが疑いもなく時代遅れになっていることを示していました。とりわけ、Microsoft
Windows が圧倒的に支配的なデスクトッププラットフォームになっているのに、APIのための基礎としてX/Motif を選択することはいまや目に余って第三者にとって理解しがたいものになっていました。
どんなケースであれ、世界はJavaに移行しつつあることははっきりしていました。OTI は受賞したVisualAge/Java 開発環境（Common
WidgetsからのGUIビルドを備えている）を作成するまでの十分長い間、継続して内部的な開発のためにSmalltalk を使い続けました。しかし、それを超える何らかの新たな開発がJavaできっと行われるであろうということを確信していました。
OTIから次のプログラミング環境上で・・・Javaで組み込みシステムを開発するためのツール
でのワークが始まると、Javaは期待通りに実装言語として選択されました。開発者たちは最初、AWT/Swing を用いたユーザインターフェイスのプロトタイプをビルドしました。しかしそのプロセス過程でたくさんの外観とパフォーマンスの問題があることに気がつきました。開発者たちはこの問題をなんとかしようと試みましたが最後にはその当時には、商用のアプリケーション開発のための基礎として使用する準備がAWT/Swingにはできていないという結論に達しました。加えて、Swingのエミュレートされたウィジェットは『エミュレートされたlook&feel』
Smalltalkのユーザインターフェイスがそうだったようにすべてマイナス要素になりやすい。
この点では、質問に答える必要がありました。VisualAge/MicroEditon が仮に市場に出るとしたらそれまでにAWTとSwingは成熟して十分に速い、これらを用いて商用目的でのアプリケーションをビルドできるほど使えるものになっているだろうか？
たとえそうできたとしても、エミュレートというアプローチでは要求の厳しいデベロッパらにアピールできるほどのツール群の実装を効果的に行えるだろうか？かなり内部で議論をした後に、異なるアプローチが必要いうことが決定されました。
過去にCommonWidgetに投資した努力の量を考えると、次にとられる選択は明らかで既存のSmalltalk のコードをJavaで書き換え、あらたなツールキット(toolkit)のための基礎として用いるというものでした。しかしAPIのモデルとしてX/Motif
を用いることはもはや理にかなっていませんでした。さまざまな非 X/Motif 実装間での移植性を提供するために使用されるOSWidget レイヤーが一様にパワフルになり、よりシンプルなAPIを持つようになりました。それからこれは新たなプログラミング言語の制約を通じてフィルタされ、何個かの次善の設計での決定をクリーンアップするために取り入れられた機会を持ちました。しかしオリジナルのフィロソフィや全体的な構造は維持しており、それがSWTのための基礎となりました。
それから、SWTは継続して進化を続け、オープンソースへと生まれ変わり、それはEclipseやその付随的なカスタムウィジェットパッケージ中で使用され、Windows
CE , GTK 2, Macintosh OS X, へのSWTを用いた実装もできるようになりました。新たな多くのほかのフィーチャー(features)も加わました。新たな能力があるにもかかわらず、フィロソフィ（哲学）は同じままです。プラットフォームの能力を利用できるようにして、レイヤーをできる限り薄くして移植性のある方法でリアルなプラットフォームアプリケーションを作成することができるようにしたツール群がSWTです。
|
リンクフリーです。任意のページに直接リンクしてください。
|
|
|
|
