[C4.1]グラフィカルユーザインターフェース
グラフィカルユーザインターフェース(GUI)はユーザが実際に操作する環境を
提供するクラスです。KONOEではこの部分をJavaのアプレットとして
実装することにしています。KONOEのフロントエンドとしては使い慣れた
任意の計算機からNETSCAPEなどのWWWブラウザを通してアクセスできる
メリットは非常に大きいでしょう。
もともと、Javaをフロントエンドの処理言語に選んだのはマシンに依存しない
処理系であること以外に、GUIとネットワーク通信の標準的なクラスを
装備していることによるものです。
1.GUIの構成
GUIをサポートするクラスを考える場合、大きく分けて二つの面から見ていく
ことが出来ます。
- 下から見ていく場合。GUIはメニューやボタンなどのウィジェットと呼ばれる
画面上の部品の集まりと、マウスの操作やキーボード入力など様々なイベントと
呼ばれる事象の集まりの二つの処理を、より合理的に扱えるように考えていく
ことが必要です。
- 上から見ていく場合。例えばヒストグラムというオブジェクトを考えると
それを操作するために必要な様々な機能をGUIで実装しなければなりません。
これは色々なプログラムに現われても同じオブジェクトは同じ操作で扱える
というGUIの重要な側面を実現します。
以下、順に見ていきましょう。
2.標準的なGUI部品
GUIのモデルは現在かなり定着しています。X11/X-toolkitの設計は、C言語で
書かれてはいますがしっかりとしたオブジェクト指向技術が採用されています。
例えば画面の部品であるウィジェットはクラスオブジェクトであり、親の
ウィジェットクラスの機能を継承してより細かいウィジェットを実現しています。
当然ですが、JavaのAWTでもその考え方がそのまま採用されています。そこで
我々はより使いやすいウィジェットを継承によって実装していくことが出来ます。
残念ながらJDK1.1までの段階ではウィジェットの機能はそれほど優れたものと
いうことはできません。
GUIのプログラミングを考えたときのもう一つの重要な側面はイベント駆動型
プログラミングが必要ということです。ウィジェットであるボタンやメニュー
ごとにそれが押されたときどうするかという手続きをあらかじめ記述し、
イベントが発生する度に対応する手続きを呼び出すという形になります。
第一義的にはこういったプログラミングになりますが、この方法は必ずしも
このましいものではありません。本当にイベントを受け取りたいのはボタンや
それが書かれたパネルオブジェクトではなくて、よりアプリケーションに近い
側のオブジェクトのはずです。JDK1.1ではここが改善されています。
さて、問題はそれらを使ってどのようにGUIを構築していくかです。出来るだけ
色々なプログラムで同じ感じの操作が出来るようになっていることは重要です。
そういう意味でAWTが提供するレベルより上のレベルで標準的なGUI部品を
用意し、次に述べるKONOEオブジェクト毎のGUIを実現するように考える
必要があります。逆にいえばKONOEオブジェクトへのGUIを実装するのに
必要な部品の解析により標準部品を決定していくことになるかも知れません。
3.KONOEオブジェクトに対応したGUI機能
KONOEのオブジェクトの多くのものがGUIへ渡され、操作されることになります。
それらについて順番に見ていきましょう。

[class/gui.html] Last Modified : 09-Apr-1997.
KONOEコラボレーション
konoe-req@konoe.kek.jp