JPH06149598A - コンピュータ・ユーザ・インタフェース・システム - Google Patents

Abstract

(57)【要約】 【目的】 ユーザ・インタフェースとアプリケーション
の処理部とが完全に独立して制御されるユーザ・インタ
フェース・システムを提供する。 【構成】 オープン・ユーザ・インタフェース・システ
ム２０は、アプリケーション・プログラム１０の処理部
から呼び出され、カーネル２２は、アプリケーション・
プログラム１０から供給される命令を解し、インタフェ
ースを定義するエレメントが整理されているオブジェク
ト・ツリー２４上の対応するオペレーションを起動させ
る。該エレメントの対話状態は、それ自体の状態とツリ
ーの親エレメントの状態とに依存している。ユーザ・イ
ンタフェースの更新は、前更新および後更新の２段階に
より、エレメントの対話状態が更新されることによって
行われる。このユーザ・インタフェースの記述は、対応
するプログラムから独立した特定のファイルに格納され
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、デジタルコンピュー
タに係り、特にコンピュータを使用するユーザとコミュ
ニケートするためのインタフェースを提供するコンピュ
ータにおける少なくともディスプレイを制御するシステ
ムに関する。

【０００２】

【従来の技術】近年、パーソナルコンピュータのための
グラフィカル・ユーザ・インタフェースの開発に対し、
かなりの興味が高まっている。マイクロソフト（Ｍｉｃ
ｒｏｓｏｆｔ）社のウィンドウズ（Ｗｉｎｄｏｗｓ）が
大いに成功し広く使用されるに伴い、ユーザは、アップ
ル（Ａｐｐｌｅ）社のマッキントッシュ（Ｍａｃｉｎｔ
ｏｓｈ）のように、そういったプラットフォーム、もし
くはグラフィカル・ユーザ・インタフェースを使用する
同様なプラットフォームで作動するアプリケーション
を、期待するようになったが今ではむしろ必要としてい
る。最近のグラフィカル・ユーザ・インタフェース・オ
ペレーティング・プラットフォームは、コンピュータの
ユーザに対しあらゆる種類の対話手段、例えばテキスト
入力フィールド、ボタン、メニューのバー、メニュー、
およびメニュー項目などをサポートしている。

【０００３】

【発明が解決しようとする課題】ところで、上述したあ
らゆる種類の対話手段は、インタフェース項目の対話状
態（すなわち、ユーザとの対話の可視性および可能性）
に対し共通の制御手段を持たない。一般に、各種の対話
手段は他の対話手段とは異なる制御方法を有しており、
対話手段が異なると、用語すらも異なっている。

【０００４】更に、最近のシステムでは、アプリケーシ
ョン処理機能とインタフェース機能は混合しており、ア
プリケーションのプログラマは、処理・オペレーション
と共にインタフェース・オペレーションの操作について
考慮しなければならない。本質的に、新しいプラットフ
ォームのためにアプリケーションが作成される度毎に、
プログラマは全く新しいプログラムを作成しなければな
らない。それは、インタフェースの操作方法に共通性が
ないためである。このため、新しいプラットフォームと
オペレーティング・システムのためのアプリケーション
を作成する場合に、かなりの時間と費用がかかる。

【０００５】この発明は、根本的に、従来のコンピュー
タ・プログラミングの構造および方法の欠点を排除する
構造および方法を供給することを目的としている。アプ
リケーションがユーザ・インタフェースと全く独立して
作成され得るような方法で、コンピュータのユーザ・イ
ンタフェースの制御が供給されることが特に意図されて
いる。

【０００６】また、本発明のもう一つの目的は、ユーザ
・インタフェースがアプリケーションの処理部と独立し
て生成および修正され得るものであり、かつ、アプリケ
ーションの処理とユーザ・インタフェースとの相互コミ
ュニケーションが全く自在であり、そのためアプリケー
ションの処理部が根本的に可搬性のよい方法で作成され
得るものであるような、コンピュータ・ユーザ・インタ
フェースのシステムおよび方法を提供することである。

【０００７】

【課題を解決するための手段】請求項１に係る発明によ
るコンピュータ・ユーザ・インタフェース・システム
は、コンピュータのユーザからのコマンドを受信する受
信手段を有し、ユーザとインタフェースを行う手段と、
ディスプレイを有し、ユーザに対し情報を通信する通信
手段とを有するプログラマブル・デジタル・コンピュー
タにおいて、アプリケーション・プログラムのデータ処
理機能を実行するために要求される処理モジュール全て
を含むアプリケーション処理手段と、前記アプリケーシ
ョン処理手段と接続され、前記受信手段と感応的に接続
され、かつ、前記通信手段を制御するために接続された
オープン・ユーザ・インタフェース・システム（ＯＵＩ
Ｓ）とを具備し、前記ＯＵＩＳは、前記アプリケーショ
ン処理手段によって呼び出され、ユーザの動作によりデ
ータ処理が要求されると、前記アプリケーション処理手
段に制御を移し、前記アプリケーション処理手段は、要
求されたデータ処理機能が終了すると制御を前記ＯＵＩ
Ｓに戻すことを特徴としている。

【０００８】請求項２に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項１に係る
発明において、前記ＯＵＩＳは、少なくとも前記ディス
プレイを制御するオブジェクト・コンテイニング・ツリ
ー手段と、前記オブジェクト・コンテイニング・ツリー
手段の構造を制御するために、前記アプリケーション処
理手段と相互に通信するカーネル手段とからなり、前記
オブジェクト・コンテイニング・ツリー手段は前記ディ
スプレイの固有の機能を制御するためにのみ設けられた
複数のオブジェクトを有し、いくつかの機能は、他の機
能の中に含まれており、前記オブジェクトは階層的に整
理されたオブジェクト・ツリーの形式で相互に関連づけ
られており、そのため他の機能に包含された機能は前記
ツリーにおいて前記他の機能の下にあり、前記カーネル
手段は、少なくとも、特定のオブジェクト・ツリーをク
ローズする際の開始および終了に使用されるコードと、
特定のオブジェクトに値を設定すると共に特定のオブジ
ェクトから値を取り出すコードと、前記アプリケーショ
ン処理手段の待機状態に影響を与えるコードとを含む数
セットの命令コードを使用することによりアプリケーシ
ョン処理手段と通信することを特徴としている。

【０００９】請求項３に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項２に係る
発明において、前記オブジェクト・コンテイニング・ツ
リー手段は、ディスプレイにおけるオブジェクトの外観
および対話状態に影響を与え、事前に定義された複数の
対話状態のいずれか１つをとるオブジェクトを含み、各
オブジェクトは事前に定義された実行可能状態を有し、
各オブジェクトの対話状態はインタフェース・ツリーに
おける状態およびその親の状態によって決定されること
を特徴としている。

【００１０】請求項４に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項３に係る
発明において、前記オブジェクトがとることのできる実
行可能な状態は、実行中、実行不能、および隠れ状態で
あり、オブジェクトの可能である対話状態は、有効、知
覚、可視、不可視、およびリンク解除であり、エレメン
トの対話状態は、以下の表によって決定されることを特
徴としている。

【００１１】請求項５に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、コンピュータの
ユーザから通信を受信する入力手段と、ユーザに対して
情報を通信する出力手段とを有し、前記出力手段は少な
くともディスプレイを含むと共に複数の出力エレメント
を有しており、それらのある出力エレメントは他の出力
エレメントに包含されているディジタル・コンピュータ
において、各出力エレメントに対応するノードを有する
インタフェース・ツリーによって前記出力エレメントを
表し、出力エレメントがサブツリー上に整理され、その
ためにツリーにおいて、他のエレメントを包含するエレ
メントが前記他のエレメントの上位にあるようにし、ユ
ーザと対話することができ、かつユーザのイベントをサ
ブエレメントに送信することができるエレメントの可能
性を定義する実行可能状態を、各エレメントに割り当
て、前記ツリーおよびエレメントの状態においてその親
の状態に従属している各エレメントに対し対話状態を決
定し、各エレメントの対話状態に応じて前記ディスプレ
イにおける当該エレメントの外観を制御することを特徴
としている。

【００１２】請求項６に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項５に係る
発明において、前記方法は、サブツリーの状態を更新す
るために、前記サブツリーのローカル・ルート・エレメ
ントから始まって、各エレメントを前更新し、その親エ
レメントが前更新されるまではエレメントは更新される
ことなく、そのサブツリーにおいて各サブエレメントが
後更新された後にのみエレメントを後更新するステップ
を含むことを特徴としている。

【００１３】請求項７に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項５に係る
発明において、前記方法は、サブツリーの状態を更新す
るために、前記サブツリーのローカル・ルート・エレメ
ントから始まって、各エレメントを前更新し、その親エ
レメントが前更新されるまではエレメントは更新される
ことなく、そのサブツリーにおいて各サブエレメントが
後更新された後にのみエレメントを後更新するステップ
を含むことを特徴としている。

【００１４】請求項８に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項７に係る
発明において、前記方法は、エレメントがサブエレメン
トを有していない時に該エレメントを後更新し、後更新
されたエレメントが同じレベルに処理が行われていない
シブリンを有している時、処理が行われていないシブリ
ンのサブツリーを前更新し、後更新されたエレメントが
処理が行われていないシブリンを有していない時、その
親に向かってツリーの上方へ処理を移しその親を後更新
するステップを含むことを特徴としている。

【００１５】請求項９に係る発明によるコンピュータ・
ユーザ・インタフェース・システムは、請求項６に係る
発明において、前記方法は、サブツリーの状態を更新す
るために、前記サブツリーのローカル・ルート・エレメ
ントから始まって、各エレメントを前更新し、その親エ
レメントが前更新されるまではエレメントは更新される
ことなく、そのサブツリーにおいて各サブエレメントが
後更新された後にのみエレメントを後更新するステップ
を含むことを特徴としている。

【００１６】請求項１０に係る発明によるコンピュータ
・ユーザ・インタフェース・システムは、請求項９に係
る発明において、前述した方法は、エレメントがサブエ
レメントを有していない時に該エレメントを後更新し、
後更新されたエレメントが同じレベルに処理が行われて
いないシブリンを有している時、処理が行われていない
シブリンのサブツリーを前更新し、後更新されたエレメ
ントが処理が行われていないシブリンを有していない
時、その親に向かってツリーの上方へ処理を移しその親
を後更新するステップを含むことを特徴としている。

【００１７】

【作用】本発明によれば、コンピュータ・アプリケーシ
ョンプログラムにおけるユーザ・インタフェース機能
は、アプリケーションプログラムによって動作する処理
機能とは完全に独立して操作され、ユーザ・インタフェ
ースはプログラムのアプリケーション処理部から呼び出
される。プログラムの処理部がユーザ・インタフェース
・コマンドと出会う時はいつでも、オープン・ユーザ・
インタフェース・システム（ＯＵＩＳ）がアクセスされ
ユーザとの対話を開始する。結局は、ユーザはプログラ
ムの処理部のアテンションを要求するオペレーションを
選択する。そして、ＯＵＩＳは、処理部にメッセージを
返し、それにより、必要な処理機能が動作する。要求さ
れた処理が終了すると、処理部は再びＯＵＩＳにアクセ
スし、次の処理の準備ができていることを示す。

【００１８】ユーザ・インタフェースの記述は、対応す
るプログラムと独立して特別のファイルにストアされ
る。そして、インタフェースは、アプリケーションプロ
グラムの論理的な機能に影響を与えずに、かつ、プログ
ラムの修正を行う必要なしに、修正されることが可能で
ある。

【００１９】プログラムのユーザの視点から見れば、Ｏ
ＵＩＳで作成されたプログラムは、プラットフォーム
（例えば、マッキントッシュもしくはマイクロソフト社
のウィンドウズ）のために作成された他のプログラムと
同じように動作する。しかしながら、アプリケーション
のプログラマの視点から見れば、ＯＵＩＳは、他のユー
ザ・インタフェースのマネージメントシステムとはかな
り異なっている。それは、ＯＵＩＳが、統一され、かつ
簡易であるユーザとの対話方法を提供しており、アプリ
ケーションコードの処理部から独立したプラットフォー
ムであるからである。インタフェースの設計者の視点か
ら見れば、ＯＵＩＳは、プログラムの処理部およびイベ
ント操作の細部から独立して、ユーザ・インタフェース
を高いレベルで設計する方法を提供するというメリット
を供給する。

【００２０】ＯＵＩＳにおいて、オブジェクトもしくは
インタフェース・エレメントは、ツリー型構造に整理さ
れている。これらのオブジェクトは、メニュー、メニュ
ー項目、ウィンドウ、テキスト・フィールドおよびボタ
ンのように、グラフィカル・ユーザ・インタフェースに
おいて見受けられるエレメントの種類を表す。これらの
各エレメントは、限られた数の実行可能状態のうちのい
ずれか１つを示す。例えば、それらの状態は、隠れ状
態、実行不能、および実行中として定義され得る。更
に、各インタフェース・エレメントは対話「状態」を有
し、それはその状態、およびツリーのルートに向かって
上部に位置する親エレメントの状態に従属している。そ
れにより状態は、派生されていると見なされる。例え
ば、リンク解除、不可視、可視、知覚、および有効とい
うように定義される５つの状態がある。どんな瞬間で
も、インタフェースの全エレメントの派生した状態は、
そのインタフェースのその瞬間の状態を表す。

【００２１】ユーザ・インタフェースを更新するための
サブツリー全体の更新は、２つの段階、すなわち前更新
および後更新で行われる。ユーザ・インタフェース・ツ
リーは、全エレメントが後更新されるまで更新されな
い。前更新は、ツリーの上から下へ順に行われる。すな
わち、たとえあるにしても前更新がその親エレメントに
対してなされるまで、どのエレメントも前更新されるこ
とがない。また、後更新は、ツリーの下から上へ順に行
われる。すなわち、サブツリー全体の全エレメントが後
更新されるまでは、どのエレメントも後更新されない。

【００２２】「コンテクスト」は、インタフェース・エ
レメント間の（適合および不適合の）制御に使用される
特別なオブジェクトである。コンテクストは、２つの状
態を有する。どんなインタフェース・エレメントも、そ
れが有効となる時、あるコンテクストのセットを適合さ
せ、それが有効でなくなる時、それを適合させなくす
る。あるインタフェース・エレメントは、コンテクスト
に従属されているように登録される。これら従属エレメ
ントは、コンテクストが適合となるか不適合となるかが
知らされ、従属エレメントはコンテクストが変更される
ことによりそれら自身を実行させるか、実行不能とさせ
るか、もしくは隠すことができる。

【００２３】

【実施例】以下、図面の詳細について述べる。図１は、
本発明によるオープン・ユーザ・インタフェース・シス
テム（ＯＵＩＳ）が、オペレーティング・システム（例
えばＭＳＤＯＳ）の下で、かつ特定のプラットフォーム
（例えばマイクロソフト社のウィンドウズ）上で動作す
るコンピュータにおいて、いかに利用されるかを示す機
能ブロック図である。本発明によれは、アプリケーショ
ン・プログラム１０は、ユーザ・インタフェース・オペ
レーションを含まない。ユーザ・インタフェース・オペ
レーションは、ＯＵＩＳ２０に保持されている。アプリ
ケーション・プログラム１０が実行されるコンピュータ
のオペレーティング・システムを通して、ＯＵＩＳ２０
は、システムのディスプレイ３０およびシステムの音声
出力装置４０を制御する。オペレーションにおいて、ア
プリケーション・プログラム１０はユーザとやりとりす
る必要のある場合はいつでも、ＯＵＩＳ２０に制御を移
す。そして、ＯＵＩＳ２０は、ディスプレイ３０および
音声出力装置４０を通じてユーザと通信する。ＯＵＩＳ
２０は、ユーザが処理を要求する動作を起こすと、通信
を終了する。この時点で、ＯＵＩＳ２０は、制御をアプ
リケーション・プログラム１０へ戻す。

【００２４】ＯＵＩＳ２０は、広義には、カーネル２２
と、オブジェクト・ツリーとも呼ばれるインタフェース
・エレメントのツリー構造をとるインタフェースの記述
とを含む。このインタフェースの記述については、後述
する。アプリケーション・プログラム１０とカーネル２
２との間のアプリケーション・プログラム・インタフェ
ース（ＡＰＩ）は、コンピュータに採用されているプラ
ットフォームおよびオペレーティング・システムに関わ
り無く、同じインタフェースがアプリケーションとカー
ネルとの間に存在するという意味で、「一様な」インタ
フェースである。これにより、アプリケーションが全く
可搬性のよいものとなる。それは、Ｃ言語のような従来
のプログラミング言語によって設計およびプログラムさ
れ得るためであり、また、オペレーティング・システム
に対応したコンパイラによってコンパイルすることによ
り、アプリケーションを最小量の修正でどんなプラット
フォームにも使用することができるためである。

【００２５】上記ＡＰＩは、わずかな命令しか含んでお
らず、それらは全てアプリケーションからＯＵＩＳへの
呼出となっている。本実施例においては、以下に示す６
つの命令のみＡＰＩに供給されている。 ＯＰＥＮ（オープン） ＣＬＯＳＥ（クローズ） ＷＡＩＴ ＦＯＲ ＡＣＴＩＯＮ（待機） ＦＩＮＤ ＥＬＥＭＥＮＴ（エレメントの取得） ＧＥＴ ＶＡＬＵＥ（値の取得） ＳＥＴ ＶＡＬＵＥ（値の設定） 「ＦＩＮＤ ＥＬＥＭＥＮＴ」は、ウィンドウ、メニュ
ー、もしくはボタンのように、操作される特定のディス
プレイ・オブジェクトの位置を指定する。「ＯＰＥＮ」
および「ＣＬＯＳＥ」は、各々、コンピュータのユーザ
とのＯＵＩＳによる通信のセッションを開始および終了
する機能である。「ＷＡＩＴ ＦＯＲ ＡＣＴＩＯＮ」
は、ユーザによって何等かの応答があるまで（例えば、
ユーザがスプレッドシート上の再計算を要求するま
で）、休止状態とする。「ＧＥＴ ＶＡＬＵＥ」および
「ＳＥＴ ＶＡＬＵＥ」は、各々、エレメントから値を
呼び出したり、エレメントに値を格納したりする。

【００２６】オブジェクト・ツリー２４は、完全なユー
ザ・インタフェースの十分な定義を有する。これらの記
述は、オペレーティング・システムおよびプラットフォ
ームにおいて有効なインタフェース・オブジェクトによ
って、定義されている。例えば、オペレーティング・シ
ステムおよびプラットフォームがウィンドウのために用
意されるとすると、ウィンドウはオブジェクトとして有
効なものとなる。カーネル２２は、アプリケーション・
プログラム１０から供給される命令を解し、ユーザとの
画像および音声のコミュニケーションを行うために、オ
ブジェクト・ツリー上の対応するオペレーションを起動
させる。ユーザが計算等のような処理の要求を行うと、
カーネル２２は、通常処理の結果を格納する位置を示し
て、アプリケーション・プログラム１０に制御を戻す。
上記格納位置は、処理の結果を受信すべきインタフェー
ス・エレメントに独自に対応している。

【００２７】上述した記述より、本発明によって、アプ
リケーション処理から完全に独立したユーザ・インタフ
ェースを設計することが可能となることが分かる。カー
ネル２２とオブジェクト・ツリー２４は、特定のオペレ
ーティング・システムおよびプラットフォームによって
動くよう設計されているため、ＯＵＩＳと接続されたア
プリケーションは、対応するオペレーティング・システ
ムおよびプラットフォームのルックアンドフィールを有
する。更に、アプリケーションから全く独立してユーザ
・インタフェースを修正することが可能であるため、イ
ンタフェースは、アプリケーション・プログラムの処理
部から切り離され、かつイベント操作の細部を考慮する
ことなく、設計されることができる。

【００２８】図２は、本発明によるＯＵＩＳにおいて作
動するコンピュータの画面を示す図である。これは、ア
ップル社のマッキントッシュコンピュータの画面であ
り、ＯＵＩＳが、オペレーティング・システムおよびプ
ラットフォームの特有のルックアンドフィールを保持す
ることを示している。この画面には、最上部にマッキン
トッシュ特有のメニューバー５０が示されており、この
場合、４つのセレクション５２，５４，５６，および５
８からなる。これらは各々選択されると、プルダウンメ
ニューの画面が表示される。上記４つのメニュー選択の
うち、セレクション５８（「ｓｃｒｉｐｔｓ（スクリプ
ト）」）のみ高輝度で表示されずに、選択として有効で
ないことを示す。図２に示す画面にはまた、１組のウィ
ンドウ６０，７０が表示されており、（前景の）ウィン
ドウ６０は実行中であり、（背景の）ウィンドウ７０は
休止中である。マッキントッシュの特徴として、ウィン
ドウ６０は、エンファシス・バンド６２と共にそのタイ
トルが高輝度となることにより、実行中であることが示
される。図示されているように、ウィンドウ６０はテキ
スト入力フィールド６５およびボタン６４を有してい
る。また、ボタン６４は実行中である。それはそのテキ
ストが高輝度で表されているからである。休止中である
ウィンドウ７０は、フレーム７２に囲まれたテキスト・
エントリ・フィールド７６と、フレーム７４に囲まれた
テキスト出力フィールド７８とを有している。

【００２９】エレメント５０，５２，５４，５６，５
８，６０，６４，６５，７０，７２，７４，７６，およ
び７８は、本実施例のＯＵＩＳにおいて、「オブジェク
ト」とみなされる。この発明によれば、制御されるイン
タフェース・オブジェクトは全て、ツリーのノードとし
て整理され、そこではそれらは表示という同じ形式で相
互に関連づけられる。この実施例においては、インタフ
ェース・オブジェクトを表すノードの階層関係は、画面
上のオブジェクトの包含関係と同様である。

【００３０】図３は、図２に示す画面に対応するインタ
フェース・ツリーを示す図である。説明の便宜上、メニ
ューバー５０に対応するノード８０、およびウィンドウ
６０，７０に対応するノード８２，８４は、各々ルート
・ノード８６のすぐ下に示されている。ノード８８，９
０，９２，および９４は、エレメント５２，５４，５
６，および５８の表示に各々対応しており、ノード８０
からすぐ下に枝分かれして発生している。ボタン６４お
よびテキスト入力フィールド６５に対応するノード９６
および９７は、ノード８２のすぐ下に発生しており、フ
レーム７２および７４に対応するノード９８および１０
０は、各々ノード８４のすぐ下に発生している。テキス
ト・エントリ・フィールド７６およびテキスト出力フィ
ールド７８に対応するノード１０２および１０４は、各
々のフレームのノードの下にある。

【００３１】図２の説明から、ＯＵＩＳのインタフェー
ス・オブジェクトは、異なる対話状態を想定することが
できなければならないことが明かである。例えば、ウィ
ンドウ６０およびそのボタン６４は、ユーザとの対話が
完全に可能であり、ウィンドウ７０は不可能である。こ
の実施例によれば、オブジェクトは５つの対話状態のい
ずれかを想定することができる。すなわち、有効状態、
知覚状態、可視状態、不可視状態、およびリンク解除状
態（対話がなくなることによる）である。

【００３２】「有効」状態を有するオブジェクトは、対
話の最も高いレベルにある。この状態では、ユーザのあ
らゆるイベントもしくはメッセージを受けることがで
き、ユーザがディスプレイで見ることができ（少なくと
も可能性として状態を変えることなく）、ユーザのイベ
ントもしくはメッセージをそのサブエレメントに伝える
ことが可能である。

【００３３】「知覚」状態にある時のオブジェクトは、
ユーザのメッセージもしくはイベントをそのサブエレメ
ントに伝えることは出来ないが、ユーザとのコミュニケ
ーションに関わる限りは、有効エレメントと同様に対話
型である。「可視」状態にあるエレメントは、コンピュ
ータのディスプレイに表示されることはできるが、ユー
ザと通信することはできない。「不可視」状態にあるユ
ーザ・インタフェース・エレメントは、コンピュータの
ディスプレイに表示されることはできず、かつ、ユーザ
と通信することができない。「リンク解除」状態にある
インタフェース・エレメントは、現在のインタフェース
・ツリーの一部ではない。それはより高い（前述した）
対話状態をとり得る前に、リンクされなければならな
い。言うまでもなく、このエレメントは見ることはでき
ず、かつユーザのイベントを受信することもできない。

【００３４】この発明によれば、各インタフェース・エ
レメントもまた実行可能状態を有しており、それは、対
話状態の１つをとることができることを示している。以
下により詳しく説明するように、エレメントがその実行
可能状態に匹敵する対話状態に達することができるか否
かは、その親エレメントの状態によって決定される。こ
の実施例においては、３つの実行可能状態、すなわち、
実行中、実行不能、および隠れ状態が定義されている。

【００３５】実行中の状態におけるインタフェース・エ
レメントは、十分な有効状態に対する準備ができてお
り、ユーザおよびそのサブエレメントとの充分なコミュ
ニケーションを含み、その親エレメントが十分に高い状
態を有していることを示している。実行不能状態におけ
るインタフェース・エレメントは、知覚状態と同様に高
い状態をとる可能性を有しており、その親エレメントは
少なくとも有効状態と同様に高い状態となっている。隠
れ状態におけるインタフェース・エレメントは、不可視
状態よりも高い状態をとることはできないが、それを含
むサブツリーが実行中のツリーにリンクされなければ
（例えばその親エレメントがリンク解除状態であるなら
ば）、リンク解除状態となる。

【００３６】表１は、エレメントの状態が、エレメント
の状態とその親エレメントの状態とによりいかに決定さ
れるかを示す。エレメントの状態が、その親の状態によ
り限定されるということが示されている。それにより、
親が不可視状態もしくはリンク解除状態であるエレメン
トは、各々不可視状態もしくはリンク解除状態となる。
同様に、親が可視状態にあるエレメントは、その状態に
係わらず可視状態よりも高い状態をとることはなく、隠
れ状態にあるエレメントは、その親がリンクされている
ならば、不可視状態を有する。親エレメントが知覚状態
にある時は、それはそのサブエレメントと連絡すること
ができない。そのため、サブエレメントは可視状態より
も高い状態をとることができない。最後に、エレメント
の親が有効状態であるならば、そのエレメントはその状
態に対応した状態をとることとなる。

【００３７】エレメント状態が定義され、エレメントの
状態およびその親の状態から状態の派生が説明されたこ
とにより、対話状態の視点から図３に示すツリーを再び
見ることにより詳細を説明する。ノード８０および８２
はユーザおよびそれらのサブエレメントとのコミュニケ
ーションを行うことが可能であるため、それらは全て有
効状態を有する。メニューバー５０のサブエレメントの
うち、ユーザはエレメント５８と通信を行うことができ
るが、ノード９４は単に知覚状態である。一方、メニュ
ーバー５０の残りのサブエレメントは全て有効である。
それは、それらがユーザに対し応答することができるか
らであり、また、それら各々のプルダウンメニューもま
た、図示されていないが、応答することができるからで
ある。ユーザは、ウィンドウ６０、そのボタン６４、お
よびそのテキスト入力フィールド６５を完全に利用する
ことができる。更に、これらエレメントの全てが下方に
連絡することが可能であり、そのためこれら全てのエレ
メントが有効である。

【００３８】技術に熟練しマッキントッシュに精通して
いる人は、ウィンドウ７０が休止状態であっても、ユー
ザがその上をマウスでクリックすることにより、いつで
も起動させることが可能であることを知っている。しか
しながら、ウィンドウは実行不能状態であるので、ノー
ド８４の状態は知覚状態であり、そのサブエレメントは
可視状態である。

【００３９】図４は、ユーザが起動するためにウィンド
ウ７０上でマウスをクリックしたときの画面を示す。そ
れにより、ウィンドウ７０は有効な状態となり、ウィン
ドウ６０は知覚状態となる。ウィンドウ６０が知覚状態
であるため、ボタン６４は良くても可視状態であり、そ
のため「ボタン」という文字の高輝度は消えて、選択す
ることができないということが示される。メニュー７０
の最上部にある高輝度のバンド７３は、メニューが現在
有効であることを示す。更に、エレメント７２，７４，
７６および７８もまた有効であり、ユーザがテキスト・
エントリ・フィールド７６に入力を行うことができる。
ツリーの全エレメントの状態は、以下に詳細を示すプロ
シージャの影響を受けて変更される。

【００４０】図４に示すメニューバー５０は図２に示す
メニューバーとは異なっている。なぜならエレメント５
８は図４において有効であるが、図２においては有効で
ないからである。更に、メニューバー５０の変化は、ユ
ーザがメニューバーに対して動作を行うことによってで
はなく、ウィンドウ７０の起動によってのみ起こる。言
い替えると、ウィンドウ７０が起動される時は、ユーザ
はスクリプトを実行することができるが、ウィンドウ６
０においては、不可能である。この発明によれば、ＯＵ
ＩＳは、「コンテクスト」と呼ばれる追加オブジェクト
を利用することによって、複雑なコンディションに基づ
くインタフェース・エレメントの状態を制御することが
できる。コンテクストは、インタフェース・ツリーの状
態により、「適合」および「不適合」と言われる２つの
状態をとることができ、内部的に保持されるオブジェク
トである。新しいエレメントが作成されると、そのエレ
メントは、１つ以上のコンテクストと共にそれらに従属
するものとして登録される。コンテクストが適合性を変
更すると、登録された全エレメントに対しコンテクスト
の変更が知らされ、エレメントはそれに従って自身の状
態を修正する。実施例のユーザ・インタフェースには、
スクリプトに関わるコンテクスト・オブジェクトがあ
る。このコンテクストは、ウィンドウ７０と同じタイプ
のウィンドウが有効である時には適合し、そうでない時
は不適合となる。そして、ウィンドウ７０が有効となっ
た時、スクリプト・コンテクストは適合性を変更する。
エレメント５８は、コンテクストの変更が知らされ、そ
れに応答して実行状態および有効状態に変化する。ウィ
ンドウ６０が再起動されウィンドウ７０が実行不能状態
となると、コンテクストは再び不適合となり、エレメン
ト５０は実行不能状態となる。コンテクストを使用する
ことにより、複雑なコンディションに基づくエレメント
の修正が特に効率的になる。

【００４１】エレメントが状態を変化させる時はいつで
も、それが親エレメントに新たにリンクされる時、新た
にリンク解除される時、使用中のインタフェース・ツリ
ーのルートとなる時、もしくは、使用中のインタフェー
ス・ツリーのルートでなくなる時、そのエレメントが設
定したルートのサブツリーにつき、状態が更新されなけ
ればならない。本実施例によれば、このような更新は、
「チェンジ・ステータス」というプロセス・モジュール
よって行われる。

【００４２】図５は、プログラム・モジュールである
「チェンジ・ステータス」の動作を示すフローチャート
である。「チェンジ・ステータス」が最初に呼び出され
ると、変数εの値が供給される。これは、更新されるべ
きサブツリーのローカル・ルートの識別を示す。このエ
レメントから始まり、サブツリーの各エレメントは、
「前更新」および「後更新」と言われる２つの段階にお
いて、更新される。実際の更新は、全エレメントが後更
新されるまでは、終了しない。

【００４３】エレメントεから始まり、更新される必要
のあるエレメントは、ツリーの左端のブランチを上から
下へ向かって前更新される。サブエレメントを持たない
エレメントが取得された時は、そのエレメントの右側
に、ツリーの同一レベルのエレメント（ここでは右側の
「シブリン（ｓｉｂｌｉｎｇ）」）が存在しないなら
ば、そのエレメントは後更新される。もし右側にシブリ
ンがある場合は、更新処理は、シブリンのサブツリーお
よび右側に更に続けて追加されたシブリンのサブツリー
に対して続けられる。もし右側にシブリンがない場合
は、処理は親に向かってツリーを上昇し、親を後更新
し、更に親の右端のシブリンに対して更新を続ける。最
終的に、エレメントεは後更新され、「チェンジ・ステ
ータス」のルーチンは終了する。

【００４４】図５において、「チェンジ・ステータス」
のルーチンはブロック２００で呼び出され、開始エレメ
ントεの識別が行われる。ブロック２０２において、変
数「エレメント」にεが設定され、ブロック２０４にお
いて、表１に従ってその状態およびその親の状態に基づ
き、現在のエレメントの状態が計算される。

【００４５】ブロック２０４は、ブロック２０４，２０
６，２０８，２１０および２１２からなるループ２０５
の最初のブロックであり、ここで、サブツリーの左端の
ブランチにおけるエレメントは全て前更新される。ブロ
ック２０６において、現在のブロックの現在の状態が、
新たに計算された状態と等しいか否か（例えば、ブロッ
クの状態が変更されるべきでないか否か）を判断する。
この判断結果が「ＹＥＳ」の場合は、制御はループ２０
５を抜けてブロック２１６へ移される。現在のエレメン
トの状態が変更されるべきであると判断されると、ブロ
ック２０８においてその新たな状態に前更新される。そ
して、ブロック２１０において、現在のエレメントにサ
ブエレメントが存在するか否かを判断する。この判断結
果が「ＹＥＳ」の場合は、左端のサブエレメントが現在
のエレメントとなり、制御がブロック２０４に移されて
ループ２０５が繰り返される。このようにして、新しい
状態が計算され、ブロック２１０において現在のエレメ
ントがサブエレメントを持たないと判断されるまで、ツ
リーの左端のブランチにおける各サブエレメントに、前
更新の影響が与えられる。この時点で、現在のエレメン
トはブロック２１４において後更新される。

【００４６】ブロック２１６において、後更新されたば
かりのエレメントがローカル・ルート・エレメント、す
なわちエレメントεであるか否かを判断する。この判断
結果が「ＹＥＳ」の場合は、サブツリーが全て後更新さ
れ、プロシージャ・モジュールの「チェンジ・ステータ
ス」はブロック２２４において終了する。現在のエレメ
ントがエレメントεでないならば、プロセスは続行さ
れ、ブロック２１８において現在のエレメントが右側に
シブリンを有するか否かを判断する。この判断結果が
「ＮＯ」である場合は、ブロック２２２において、プロ
グラムは現在のエレメントの親に対する処理を開始し、
ブロック２１４に制御を戻してそのエレメントの後更新
を行う。すなわち、ブロック２１４，２１６，２１８お
よび２２２は、もう１つのループ２１５を構成してお
り、このループ２１５において、処理はエレメントを後
更新しながらツリーを逆進する。

【００４７】ブロック２１８において現在のエレメント
の右側にシブリンが存在すると判断された場合は、右側
のシブリンが現在のエレメントとなり、処理はブロック
２０４に戻る。ループ２０５を繰り返し通過することに
より、右端のシブリン・エレメントがローカル・ルート
であるサブツリーの左端のブランチを前更新する。

【００４８】前述したように、最終的に全エレメントが
上記のように前更新され、最終的に後更新され、ループ
２１５を経由して到達したツリーを上方向に移動するこ
とにより、エレメントεは結局後更新されて、プログラ
ム・モジュールの「チェンジ・ステータス」はブロック
２２４において終了する。

【００４９】プロシージャの「チェンジ・ステータス」
を用いた実施例では、左端のブランチを前更新し右側の
シブリンに進んでいるが、これは発明にとって本質とな
るものではない。実際には、プロシージャは、二重処理
を避けるために、ブランチおよびシブリンが処理される
軌道を絶えず認識している限りは、無作為にブランチを
下ると共に、無作為にシブリンに処理を進めることがで
きる。

【００５０】本発明の実施例は、実例という目的で公開
されているが、技術の熟練者は、添付の特許請求の範囲
によって定義された発明の範囲および特質を離れること
なく多くの追加、修正、および代入が可能であることを
認識する。

【００５１】

【発明の効果】以上説明したように、この発明によれ
ば、アプリケーションがユーザ・インタフェースと全く
独立して作成され得るような方法で、コンピュータのユ
ーザ・インタフェースの制御が供給される。また、ユー
ザ・インタフェースがアプリケーションの処理部と独立
して生成および修正され、アプリケーションの処理とユ
ーザ・インタフェースとの相互コミュニケーションが全
く自在となり、そのためアプリケーションの処理部が根
本的に可搬性のよい方法で作成され得るという効果があ
る。

【図面の簡単な説明】

【図１】この発明の一実施例によるユーザ・インタフェ
ース・システムを用いたコンピュータの機能上の構成を
示すブロック図である。

【図２】同実施例においてユーザ・インタフェース・シ
ステムがどのように動作するかに関わる基本的な概念を
説明するためのコンピュータの表示画面を示す図であ
る。

【図３】図２に示すコンピュータ画面を表すオブジェク
ト・ツリーを示すスキーマ図である。

【図４】同実施例において修正が行われた後のコンピュ
ータの表示画面を示す図である。

【図５】同実施例においてオブジェクトの状態の修正処
理を示すフローチャートである。

【符号の説明】

１０ アプリケーション・プログラム ２０ オープン・ユーザ・インタフェース・システム
（ＯＵＩＳ） ２２ カーネル ２４ オブジェクト・ツリー ３０ ディスプレイ

Claims (10)

【特許請求の範囲】
1. 【請求項１】 コンピュータのユーザからのコマンドを
   受信する受信手段を有し、ユーザとインタフェースを行
   う手段と、ディスプレイを有し、ユーザに対し情報を通
   信する通信手段とを有するプログラマブル・デジタル・
   コンピュータにおいて、 アプリケーション・プログラムのデータ処理機能を実行
   するために要求される処理モジュール全てを含むアプリ
   ケーション処理手段と、 前記アプリケーション処理手段と接続され、前記受信手
   段と感応的に接続され、かつ、前記通信手段を制御する
   ために接続されたオープン・ユーザ・インタフェース・
   システム（ＯＵＩＳ）とを具備し、 前記ＯＵＩＳは、前記アプリケーション処理手段によっ
   て呼び出され、ユーザの動作によりデータ処理が要求さ
   れると、前記アプリケーション処理手段に制御を移し、
   前記アプリケーション処理手段は、要求されたデータ処
   理機能が終了すると制御を前記ＯＵＩＳに戻すことを特
   徴とするコンピュータ・ユーザ・インタフェース・シス
   テム。
2. 【請求項２】 前記ＯＵＩＳは、 少なくとも前記ディスプレイを制御するオブジェクト・
   コンテイニング・ツリー手段と、 前記オブジェクト・コンテイニング・ツリー手段の構造
   を制御するために、前記アプリケーション処理手段と相
   互に通信するカーネル手段とからなり、 前記オブジェクト・コンテイニング・ツリー手段は前記
   ディスプレイの固有の機能を制御するためにのみ設けら
   れた複数のオブジェクトを有し、いくつかの機能は、他
   の機能の中に含まれており、前記オブジェクトは階層的
   に整理されたオブジェクト・ツリーの形式で相互に関連
   づけられており、そのため他の機能に包含された機能は
   前記ツリーにおいて前記他の機能の下にあり、 前記カーネル手段は、少なくとも、特定のオブジェクト
   ・ツリーをクローズする際の開始および終了に使用され
   るコードと、特定のオブジェクトに値を設定すると共に
   特定のオブジェクトから値を取り出すコードと、前記ア
   プリケーション処理手段の待機状態に影響を与えるコー
   ドとを含む数セットの命令コードを使用することにより
   アプリケーション処理手段と通信することを特徴とする
   請求項１記載のコンピュータ・ユーザ・インタフェース
   ・システム。
3. 【請求項３】 前記オブジェクト・コンテイニング・ツ
   リー手段は、ディスプレイにおけるオブジェクトの外観
   および対話状態に影響を与え、事前に定義された複数の
   対話状態のいずれか１つをとるオブジェクトを含み、各
   オブジェクトは事前に定義された実行可能状態を有し、
   各オブジェクトの対話状態はインタフェース・ツリーに
   おける状態およびその親の状態によって決定されること
   を特徴とする請求項２記載のコンピュータ・ユーザ・イ
   ンタフェース・システム。
4. 【請求項４】 前記オブジェクトがとることのできる実
   行可能な状態は、実行中、実行不能、および隠れ状態で
   あり、オブジェクトの可能である対話状態は、有効、知
   覚、可視、不可視、およびリンク解除であり、エレメン
   トの対話状態は、以下の表によって決定されることを特
   徴とする請求項３記載のコンピュータ・ユーザ・インタ
   フェース・システム。
5. 【請求項５】 コンピュータのユーザから通信を受信す
   る入力手段と、ユーザに対して情報を通信する出力手段
   とを有し、前記出力手段は少なくともディスプレイを含
   むと共に複数の出力エレメントを有しており、それらの
   ある出力エレメントは他の出力エレメントに包含されて
   いるディジタル・コンピュータにおいて、 各出力エレメントに対応するノードを有するインタフェ
   ース・ツリーによって前記出力エレメントを表し、出力
   エレメントがサブツリー上に整理され、そのためにツリ
   ーにおいて、他のエレメントを包含するエレメントが前
   記他のエレメントの上位にあるようにし、 ユーザと対話することができ、かつユーザのイベントを
   サブエレメントに送信することができるエレメントの可
   能性を定義する実行可能状態を、各エレメントに割り当
   て、 前記ツリーおよびエレメントの状態においてその親の状
   態に従属している各エレメントに対し対話状態を決定
   し、 各エレメントの対話状態に応じて前記ディスプレイにお
   ける当該エレメントの外観を制御することを特徴とする
   コンピュータ・ユーザ・インタフェース・システムの制
   御方法。
6. 【請求項６】 前記エレメントがとることのできる実行
   可能な状態は、実行中、実行不能、および隠れ状態であ
   り、エレメントの可能である対話状態は、有効、知覚、
   可視、不可視、およびリンク解除であり、エレメントの
   対話状態は、以下の表によって決定されることを特徴と
   する請求項５記載のコンピュータ・ユーザ・インタフェ
   ース・システムの制御方法。
7. 【請求項７】 前記方法は、サブツリーの状態を更新す
   るために、 前記サブツリーのローカル・ルート・エレメントから始
   まって、各エレメントを前更新し、その親エレメントが
   前更新されるまではエレメントは更新されることなく、 そのサブツリーにおいて各サブエレメントが後更新され
   た後にのみエレメントを後更新するステップを含むこと
   を特徴とする請求項５記載のコンピュータ・ユーザ・イ
   ンタフェースシステムの制御方法。
8. 【請求項８】 前記方法は、 エレメントがサブエレメントを有していない時に該エレ
   メントを後更新し、 後更新されたエレメントが同じレベルに処理が行われて
   いないシブリンを有している時、処理が行われていない
   シブリンのサブツリーを前更新し、 後更新されたエレメントが処理が行われていないシブリ
   ンを有していない時、その親に向かってツリーの上方へ
   処理を移しその親を後更新するステップを含むことを特
   徴とする請求項７記載のコンピュータ・ユーザ・インタ
   フェースシステムの制御方法。
9. 【請求項９】 前記方法は、サブツリーの状態を更新す
   るために、 前記サブツリーのローカル・ルート・エレメントから始
   まって、各エレメントを前更新し、その親エレメントが
   前更新されるまではエレメントは更新されることなく、 そのサブツリーにおいて各サブエレメントが後更新され
   た後にのみエレメントを後更新するステップを含むこと
   を特徴とする請求項６記載のコンピュータ・ユーザ・イ
   ンタフェースシステムの制御方法。
10. 【請求項１０】 前述した方法は、 エレメントがサブエレメントを有していない時に該エレ
    メントを後更新し、 後更新されたエレメントが同じレベルに処理が行われて
    いないシブリンを有している時、処理が行われていない
    シブリンのサブツリーを前更新し、 後更新されたエレメントが処理が行われていないシブリ
    ンを有していない時、その親に向かってツリーの上方へ
    処理を移しその親を後更新するステップを含むことを特
    徴とする請求項９記載のコンピュータ・ユーザ・インタ
    フェースシステムの制御方法。