Category: OOPSLA88, UI
Bibtype: InProceedings
Booktitle: Proceedings of the 1988 ACM Conference on Object-Oriented
        Programming Systems, Languages and Applications (OOPSLA88)
Month: aug
Author: Pedro A. Szekely
        Brad A. Myers
Pages: 36-45
Title: A User Interface Toolkit Based on Graphical Objects and Constraints
Year: 1988
Comment1: 
        階層的グラフィックオブジェクト、制約、入力/出力/アプリケーション
        の間に位置する「active value」を活用したユーザインタフェース
        ツールキットである。この論文の中で特に述べられてはいないが、
        ユーザインタフェースには「直接操作」と「意味フィードバック」が
        不可欠であることが最近広く信じられている。
        オブジェクト指向を使ってこれらを実現しつつ入出力とアプリケーションを
        分離することができるということを主張している。
        本システムはCommon Lisp+CLOS上に作られている。
        \\
        本システム「Coral」は入力部(Interactors)、表示部(Graphical objects
        + constraings)、Active Value、アプリケーションに分かれている。
        Interactor(入力操作オブジェクト)については本論文では述べられていない。
        \\
        表示部は(よくある?)階層的グラフィックオブジェクトとそれらの間の制約
        で構成されている。
        \\
        Active Valueは入力またはアプリケーションにより操作され、
        その結果表示が影響をうける。またActive Valueが変化すると
        アプリケーションに通知される。Active Valueにより他の部分が分離されて
        いるわけである。
        \\
        例えばマウスをドラッグして回路図のノードを移動させる場合、
        マウスの移動によりInteractorを通じてActive Valueの値が変化し、
        それを参照する制約条件により表示が刻々変化していくといった具合である。
        \\
        グラフィックオブジェクトは図形を階層的なクラスで定義してあるもので、
        描画関数、位置、ある点がそれに含まれるかどうかを知る関数、
        などを含んでいる。また図形を集合として扱う機能も持っている。
        \\
        制約及び表示オブジェクトは宣言的、手続き的の両方で指定できる。
        宣言的記述は手続き的記述に変換される。
        オブジェクトに手続きをattachして定義するといった感じである。
        制約がくずれるとシステムが定義に従って再び制約を
        満たすように動いていく。
        制約は１方向に限られるが、それによって問題は特に生じず効率は
        良くなっている。
        \\
        疑問点.....
        \\
        制約でうまく記述できれば確かに美しいが、本当に複雑なインタフェースを
        それだけで記述できるのであろうか。例示によるインタフェースの場合
        でもそうであるが、ある特定のインタフェースしか扱えないのでは
        ないか？
        状態をもたせたいときなどどうするのかしら？
        また並列性、例外処理などについて何も言っていないが実際に
        問題になるのはそのあたりではないのか？
        モデルはすっきりしていて気持ちが良いと感じる。わけのわからない
        図を書く日本人が多いので....
        やっぱりLISPの方がこういうのを書きやすいのであろう。
Keyword: user interface, object oriented, UIMS, Coral, constraints
Super: OOPSLA88