JPS63174122A - コンピユーターヒューマンインタフエース - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 技術的分野 本発明は一般的にはデジタルデータ処理に関するもので
あシ、特に抽象的なデバイス依存性ピクチャ上のユーザ
が調整できるウィンドーによって情報が少なくとも１つ
のそのようなピクチャに表すレるヒユーマンインタフェ
ースシスチムニ関シ、多重アプリケーションに対応する
イメージを同時に且つ互いに独立して適当な出力装置に
表示することができ更新することができるヒユーマンイ
ンタフェースシステムに関し、１実”入力を仮想入力に
変換する手段および仮想出力を“実”出力に変換する手
段を提供するヒユーマンインタフェースシステムに関し
、多重アプリケーションが１つまたは複数の独立したピ
クチャにおいてアクティブであシ、それらのアプリケー
ションを同時に且つ互いに独立して更新することができ
、単一スクＩＪ−ン上の多数の独立した“ライプ（ｌｉ
ｖｅ）”ウィンドーに表示することができるヒユーマン
インタフェースシステムに関ｆる。

発明の背景 一つまたは複数の”ウィンドー″が情報をピュア（ｖｉ
ｅｗｅｒ　）に提示する出力表示装置を備えることはデ
ータ処理技術上周知である。そのようなウィンドーによ
シューブはいくつかくアプリケーション（例えばワード
処理、スプレッドシートなど）の部分を同時に見ること
ができる。しかし、周知の“ウィンドーインク技術にお
いては各ウィンドーは必ず同一サイズでなければならな
い。各ウィンドーを独立して任意の所望する寸法に作る
能力は現在のところでは知られていない。

従って、データ処理オペレーティングシステムのヒユー
マンインタフェース内に互いに独立して多重ウィンドー
のサイズを調整する能力を備えることができるようにす
ることが大いに必要である。

多重アプリケーションからのイメージを表示できる出力
表示装置を備えることもまたデータ処理技術上周知であ
る。例えば、スズレッドシートの一部をディスクにプリ
ントしそのような部分をワード処理アプリケーションフ
ァイルの所望する場所に読込むことも知られている。こ
の方法にょシ、１つのアプリケーションからの情報は別
のもう１つのアプリケーションに取入れられる。

しかし、２つまたはそれ以上のアプリケーションから情
報を統合する周知の方法においては、ひとたびアプリケ
ーションの出力がディスクにプリントされると、それは
１死んだ′情報となシ、もはやそのアプリケーションの
アクティブな部分ではなかった。

上述した例を用いると、スプレッドシート部分は時間的
に固定され、もはやそのセルのうちの１つの変化ととも
に変化しない。そのような変化を反映するためには、ス
プレッドシートは再びディスクにプリントされワード処
理ファイルに再び読込まれなければならない。

従って、データ処理オペレーティングシステムのヒユー
マンインク７エース内にお込て、多重アプリケーション
ソースからの情報を同時にライブ状態で表示できるよう
にする能力を備えることが大いに必要である。

適当なヒユーマンインタフェースを備よるために多種類
の入力および出力装置をデータ処理システムに結合する
こともデータ処理技術においては周知である。そのよう
な装置は色々な作シのキーボード、′マウス、タッチパ
ッド、ジョイスティック、ライトペン、ビデオスクリー
ン、聴視完信号、プリンタなどの形をとってもよい。

ヒユーマン／コンピュータインタフェースニ利用できる
Ｉ１０装置が多種類におよぶため、ヒユーマンインタフ
ェースソフトウェアを特定の装置型から分離することが
極めて望ましい。このＩ１０装置はいかなる個々の“実
”装置からも独立していなければならない。

従って、個々の”実”装置から独立して抽象的な意味で
Ｉ１０オペレーションを行つコンピュータヒューマンイ
ンタフェースが必要とされている。

１つまたは複数の１ウィンドー”がピュアに情報を提示
する出力表示装置を備えていることもまたデータ処理技
術では周知である。そのようなウィンドーによシューブ
はいくつかのアプリケーション（例えばワード処理、ス
プレッドシートなど）の部分を同時に見ることができる
。しかし周知の“ウィンドーインク技術においては、一
時に１つだけのウィンドーが“生きている（ｌｉｖｅ）
”（即ち、アクティブアプリケーションに応答しそのア
クティブアプリケーションを表示する）。従って、多数
の“ライブ”ウィンドーを同時に表示する機能をデータ
処理オペレーティングシステムのヒユーマンインタフェ
ース内に備えることができるようにする必要が大いにあ
る。

発明の簡単な要約 従って、本発明の目的は改良されたヒユーマンインタフ
ェースを有するデータ処理システムヲ提供することであ
る。

本発明のもう１つの目的は、ユーザがビデオ表示装置ま
たはプリンタのような出力装置に現れる複数のウィンド
ーのサイズを独立して調整できるようにする改良された
データ処理システムヒユーマンインタフェースを提供す
ることである。

本発明のもう１つの目的は、多重アプリケーシヨンから
の情報を単一の宍示装置上に１ライブ”状態で統合でき
るようにする改良されたヒユーマンインタフェースシス
テムを提供することである。

本発明の更にもう１つの目的は、いかなる特定のＩ１０
装置からも独立して抽象的な意味で入力／出力オペレー
ションを行う改良されたヒユーマンインタフェースシス
テムを提供することである。

本発明のもう１つの目的は、いかなる型の１実”入力お
よび出力装置も使用でき、処理オペレーションを妨げず
にＩ１０装置をデータ処理システムに接続しデータ処理
システムから切シはなすことがテ＠　ル改良すレタとュ
ーマンインタフェースシステムを提供することである。

本発明の更にもう１つの目的は、別個の１ライプ″ウィ
ンドーを同時に表示できる改良されたヒューマンインタ
フェースシステムヲ提供スルコトである。

本発明の更にもう１つの目的は、別個のピクチャによっ
て表される多重アプリケーションを同時にアクティブに
できるヒユーマンインタフェースシステムを提供するこ
とである。

上記の、およびその他の目的は、データ処理システムの
ヒユーマンインタフェース、即チ少すくとも１つの抽象
的なデバイス独立性ピクチャに情報を表す手段、サイズ
情報を含む第１メツセージを発生させる手段、および第
１メツセージに応答しその１つのピクチャにウィンドー
（このウィンドーのサイズは第１メツセージに含まれる
サイズ情報によって決定される）を作るコンソールマネ
ージャプロセスとを含ムヒューマンインタフェースを備
えることによって本発明の好ましい実施例によって達成
される。

発明の概要 コンピュータヒユーマンインタフェースにおいて、ユー
ザは調整可能な１ウィンドー”によって情報の抽象的な
デバイス独立性゛ピクチャ″記述を見ることができる。

２つ以上のウィンドーｔ　一時に開くことができる。各
ウィンドーはそのウィンドーに実行されているアプリケ
ーションには関係なく互いに独立してそのサイズを決め
ることができる。ヒユーマンインタフェースはアクティ
ブな各ピクチャごとく、またアクティブな各ウィンドー
ごとに（プロセスによって表される）別個の１つの“目
的＃を作成する。ピクチャは互いに完全に独立している
。多重ピクチャを同時に更新することができ、ウィンド
ーをスクリーン上で移動させることができ、他のウィン
ドーおよび／ｌたはピクチャと関係なしにウィンドーを
サイズを変えることができる。いずれかのアプリケーシ
ョンまたは総てのアプリケーションの部分を表すウィン
ドーを含むイメージを出力デバイスに同時に、互いに独
立して表示し、更新することができる。

このオペレーティングシステムを備えた総てのヒユーマ
ンインタフェースは仮想人力／出力デバイスにより行わ
れ、システムはいかなる形の実入力または出力デバイス
も受は入れることができる。

コンピュータシステムの概要 本発明は単一〇ＰＵデータ処理システムにおいても、或
はまた分散型データ処理システム、即ち独立して機能す
ることができるが互いにメツセージを送受信するように
結合している２つまたはそれ以上のデータ処理システム
（各システムは少すくとも１つのプロセッサを有する）
においても冥施することかできる。

構内通信ネットワーク（ＬＡＮ）は分散型データ処理シ
ステムの１例である。代表的なＬＡＮは多数の自律的デ
ータ処理１ノード″を含み、各ノードは少なくとも１つ
のプロセッサおよびメモリを含む。各ノードは独立して
データ処理オペレーションを行うことができる。

第１図を参照すると、構内通信ネットワーク（ＬＡＮ）
１によって緩く結合した複数ノード２−７（ノード）を
含む分散型コンピュータ構成が示されている。このネッ
トワークに結合されるノードの数は任意であシ、ユーザ
アプリケーションによって決まる。各ノードは下記の第
２図に関連して更に詳細に述べるように少なくとも１つ
のプロセスとメモリを含む。更に、各ノードはプリンタ
８゜オペレータ表示上ジュール（ＯＤＭ）９　、大容量
メモリモジュール１３およびその他のＩ１０装置１０な
どの他の装置を含んでいてもよい。

さて第２図を参照すると、多重ネットワーク分散型コン
ピュータ構成が示されている。第１構内通信ネットワー
クＬＡＮ　１は数個のノード２，４および７を含む。Ｌ
ＡＮ　１は知能交信モジュール（工ＣＭ）５０によって
第２構内通信ネットワークＬＡＮ　２に結合している。

この知能交信モジュールはこのＬＡＮとその他のネット
ワークおよび／または（プログラマブルコントローラの
ような）遠隔プロセッサとの間のリンクを提供する。

ＬＡＮ　２は数個のノード（図示されていない）を含み
、本発明と同じＬＡＮプロトコルで操作してもよく、ま
たはＥｔｈｅｒｎｅｔ＋　ＭＡＰ　（ゼネラルモターズ
社の製造自動化プロトコル）　、　ＩＢＭ社のシステム
ズ・ネットワーク・アーキテクチュア（８ＮＡ）。

８ＥＣ８−ＩＩなどの市販されているいくつかのプロト
コルのうちのどれかで動作してもよい。各ＩＣＭ刃は上
記の特定のプロトコルのうちの１つを実行するためにプ
ログラムすることができる。更に、ノード自体の基本処
理モジュールは専用装置のための知能周辺装置コントロ
ーラ（ＩＰＣ）として使用できる。

ＬＡＮ　１は更にＩＣＭ５２を介して第３構内通信ネッ
トワークＬＡＮ　３に結合している。プロセスコントロ
ーラ団はまたＩＣＭ５４を介してＬＡＮ　１に結合して
いる。

代表的なノードＮ（第２図の７）はプロセッサ冴を含み
、そのプロセラサスは好ましい実施例においてはモトロ
ーラ６８０００のプロセッサ群のうちの１つのプロセッ
サである。各ノードは更に固定メモリ（ＲＯＭ）２８お
よびランダムアクセスメモリ（ＲＡＭ）　２６を含む。

更に、各ノードはネットワークインタフェースモジュー
ル（ＮＩＭ）２１を含み、このＮＩＭ２１はノードｔ　
ＬＡＮとパスインタフェース四に接続し、バスインタフ
ェース四はそのノードをノード内の追加装置に結合する
。最小ノードはオペレータ表示モジュール（ＯＣＭ　）
　４１やＩ１０ノジュールＩのような２つの周辺装置を
支援できるが、（プロセッサγのような追加プロセッサ
を含む）追加装置をノード内に備えることができる。そ
の他の追加装置は例えばプリンタ４２．およびハードデ
ィスクやバックアップ装置（フロッピィディスクまたは
ストリーミングテープ駆動機構）を支援する大容量記憶
装置モジュール４３を含むことがある。

オペレータ表示モジュール４１は、オペレータが情報を
入力し視覚情報を受は取ることができるようにするため
にキーボードおよびスクリーンを備えている。

このシステムは事務所または工場自動化、データ収集お
よびその他の実時間アプリケーションのために統合され
た解決策を与えるように％に設計されている。そのよう
なものとしてこのシステムはグラフ出力、ウィンドー、
メニュー、アイコン。

動的表示ｉ電子郵便、事象記録およびファイル管理など
の十分なサービスを含む。

ソフトウェアモデル 本発明のコンピュータオペレーティングシステムは、プ
ロセス、メツセージおよび文脈について動作し、これら
の用語はここに定義されている通シである。従って、こ
のオペレーティングシステムはプログラマにデータまた
は制御抽象ではなくてハードウェア抽象を与える。

本発明において用いられる１プロセス”とはデータおよ
びそのデータに対して動作する実行可能な手続の内蔵パ
ッケージと定義され、これは他の周知のシステムの１タ
スク”に匹敵する。本発明においてはプロセスはそのサ
イズ、複雑さおよびそれが用いられる方法の点からサブ
ルーチンに匹敵すると考えることができる。プロセスと
サブルーチンとの違いは、プロセスは動的に作成し破壊
することができ、そのクリエータおよびその他の１サブ
ルーチン”と同時に実行できるという点にある。

本発明に用いられているプロセス内ではデータは完全に
専用であシ、外から、即ち他のプロセスによってアクセ
スすることはできない。従って、プロセスは１目的”、
′モジュール”またはそのセスを介して、多分多重プロ
セッサについて実行することによって達成される。

本発明の分散型データ処理システムにおけるどのプロセ
スも一意名（ＰＩＤ　）を有し、この−意名によってそ
のプロセスを参照できる。ＰＩＤはプロセスが作成され
た時にシステムによって割当てられ、プロセスの位置を
物理的に突きとめるためにシステムによって用いられる
。

総てのプロセスはまた可変長文字列である一意でない記
号１名′を有する。一般的にいってプロセス名はシステ
ム全体に知られている。名の範囲を制限するために本発
明は“文脈”の概念を用いる。

“文脈２とはその名が文脈の外に知られていない関連プ
ロセスを集め九ものにすぎない。文脈は名のスペースを
よシ小さい、より管理しやすいサブシステムに区分する
。文脈はま九名を”隠し”。

文脈に含まれているプロセスが意図的でなしに他の文脈
中のプロセスと確実に矛盾しないよ５にする。

成る１つの文脈内のプロセスは他の文脈内のプロセスと
明示的に交信することはできず、そのプロセスにつ込て
知ることはできない。文脈境界を１遇する総ての対話は
゛文脈プロセス″を介さなければならず、従って成る程
度の機密保護を与える。文脈プロセスは入力メツセージ
のための交換機として動作することがしばしばあル、そ
れらの入力メツセージをその文脈内の適洛なサブプロセ
スへ再び送る。

文脈プロセスは他のプロセスと同様な挙動をし、更にそ
の文脈プロセスが作成するいかなるプロセスもその文脈
プロセスにのみ、そしてお互いくだけ知られているとい
う性質を持っている。そのプロセスを作成することはそ
のプロセスと同じ名を持った新たなプロセスを定義する
ことと事実上同じことである。

１メツセージ′はデータを含むバッファであシ、このバ
ッファはプロセスに何をなすべきかを告げた夛、または
プロセスがそのオペレーションを実行するのに必要な情
報をプロセスに供給する。各メツセージバッファは相異
なる長さく最長で伺キロバイト）ｔ−有することができ
る。協定によ）メツセージバッファの第１フイールドは
メツセージの型（例えば”読取″、゛印刷″、“状態″
、゛事象″）などを定義する。

メツセージは名またはＰＩＤによシ１つのプロセスから
他のプロセスのキューに入れられる。待合せは起きる可
能性のある同期問題を回避し、セマフォ、モニタなどの
代わ〕に用いられる。メツセージのセンダはメツセージ
が送られた後も継続する自由がある。レシーバがメツセ
ージを得ようとする場合には、そのメツセージは、待ち
行列のなかにすでに待機しているメツセージがなければ
１つのメツセージが到着するまで中断される。オプショ
ンとしてセンダは、それが返事を待つことを希望し特定
のメツセージが到着するまで中断されることを指定でき
る。他のいかなる資源からのメツセージもそのことが起
きてしまうまではキューから外されない。

本発明においては、メツセージは２つのプロセスがデー
／を交換する唯一の方法である。

１メツセージ”はプロセス間に情報を運ぶ（プロセッサ
の物理メモリサイズによってのみ制限される）可変長バ
ッファである。プログラマにアクセスできないヘッダは
宛先名とセンダのＰＩＤを含む。協定によ）メツセージ
の第１フイールドはメツセージの盤（例えば“読取”、
“状態”など）を定義する空白終了列である。メツセー
ジはそれが送られ今と受戒メプロセスのキューに登録さ
れる。

待合せは逐次アクセスを保証し、セマフォ′、モニタな
どに優先して用いられる。

メツセージはそれによってハードウェア透過性が達成さ
れる機構を備えている。システム内のどこかの場所にあ
るプロセスはプロセス名を知っていれば、（たとえ別の
プロセッサにつ込ても）システム内の他の場所の任意の
他のプロセスへメツセージを送ることができる。このこ
とは、プロセスは任意の時にシステム全体にわたって動
的に分散し、それらを参照するプロセスを変更せずに最
適のスループットを得ることができることを意味する。

宛先の分解（ｒｅｓｏｌｕｔｉｏｎ　）はプロセス名ス
ペースを探索することによって行われる。

オペレーティングシステム 本発明のオペレーティングシステムは核ト、プロセス作
成および終結１時間管理（時間のセツティング、ａ’報
のセツティングなど）を行いノード起動および構成を行
う１組のプロセスとからなる。

デバイス用のドライバもまた上述したようにプロセス（
ＥＥ８Ｐ’ｓ　）として実施される。このことはシステ
ムサービスおよびデバイスドライバの両方の追加または
置換を容易にする。このオペレーティングシステムはま
たスワツピングおよびベージングを支援するが、そのス
ワツピングおよびベージングはいずれもアプリケーショ
ンズソフトウェアには見えない。

周知の分散型コンピュータシステムとは異なシ本発明の
分散型コンピュータシステムは名を分解するのに別個の
１名サーバ１プロセスを使用しない。名探索は核に限定
され、このことは遥かによシ早いという利点を有する。

一般的にいうと、システムの各ノード用の初期ソフトウ
ェアおよびハードウェア全記述するテンプレートファイ
ルが存在する。このテンプレートはノード起動直後に計
画される１組の初期プロセス（通常は１つのサービスに
ついて１つのプロセス）ｔ一定義する。次にこれらのプ
ロセスはそれぞれのサブシステムを起動させる。各ノー
ドに対するノード構成サービスは、各サブシステムが初
期設定されるとそれへ構成メツセージを送シ、そのサブ
システムが持つデバイスについて知らせる。

その後、新たなデバイスがノードに追加されるか、また
はデバイスが故障するか、またはデバイスがノードから
除去されると、同様なメツセージが送′られる。

従って、１システムアツプ”または１システムダウン”
についての明確に定義された意味はなく、いずれかのノ
ードがアクティブである限シは、そのシステム全体とし
ては”アップ“であると考えてよい。ノードはネットワ
ークの他のノードに影響を与えることなしに動的に停止
または起動させることかできる。これと同じ原理は限定
された意味で周辺装置にも適用される。型、モデルナン
バーなどについて自己を識別できるデバイスはオペレー
タ介入なしに追加または除去することができる。

第３図は本発明を組入れた塑の分散型データ処理システ
ムにおけるメツセージの標準書式を示す。

このメツセージ書式はメツセージ識別部分１５０゜１つ
または複数の１トリプル”　１５１　、１５８および１
５５、およびメツセージ終結部分１６０を含む。各１　
トリプル”はフィールド１５６−１５８のよりな３フイ
ールドからなるフィールド群を含む。ＰＣＲＴフィール
ドと指定されている６トリプル１１５１の第１フイール
ド１５６は作成されるプロセスの名を表す。１トリプル
ｍ１５１の第２フイールド１５１はデータフィールドの
サイズを与える。第３フイールド１５８はデータフィー
ルドである。

ＰＮＴＦと指定されている１トリプル”１５３の第１フ
イールド１５９は、ＰＣＲＴフィールドにおいて指定さ
れているプロセスが作成された時を知らせるプロセス名
を表す。

メツセージは任意の数の１トリプル”を有することがで
き、ＰＣＲＴおよびＰＮＴＦフィールドを含む同一メツ
セージに多数の１トリプル”が存在する可能性がある。

という訳は、同一資源のために数個のプロセスが作成さ
れなければならない（即ち上述したように文脈を形成す
る）ことがあるからである。

ここに述べたように実施した場合には、部分１５０の長
さは１６バイトであ）、フィールド１５６は４バイト、
フィールド１５７は４バイトであシ、フィールド１５８
は長さが可変であシ、ＲＯＭ部分１６０は４バイトであ
る。

ヒユーマンインタフェース−概論 本発明のヒユーマンインタフェースハ、ユーザがそれを
用いてユーザのアプリケーションズ要求にとって特定の
パッケージを構成できる１組の手段を備えている。その
ようなパッケージはシステムについてのユーザの特定の
見解（マｉｅｗ）ｔ−反映するので１メタフオ”と云わ
れる。多数のメタフオを同時に支援することができる。

１つの代表的なメタフオは例えばソフトウェア開発環境
である。

ヒユーマンインタフェースの目的ハ、システム内におい
て利用可能なデータおよび機能に対する首尾一貫した。

統合され九アクセスを可能くすることである。システム
についてのユーザの認識結果はユーザがそのシステムと
対話する方法に主として基づくので、ユーザが気持ちよ
く感じるインタフェースを備えることが重要である。こ
のヒユーマンインタフエース内、エンドユーサニキって
馴染み深い目的とそれらの目的に適用できる１組の動作
とからなるモデルをシステムズデザイナーが作成できる
ようにする。

ヒユーマンインタフェースの基本概念ハ”　ピクチャ″
の概念である。総ての視覚指向情報は解釈とは関係なく
ピクチャによって表される。（ダイアグラム、報告、メ
ニュー、アイコンなどの）ピクチャは、ヒユーマンイン
タフェース内の総てのプログラムおよびヒユーマンイン
タフェースを用いる総てのプログラムによって認識され
操作されるデバイス独立性書式で定義される。ピクチャ
はぎつしシ詰めて記憶することができプロセス間を効率
的に転送できる“線、゛弧”　および゛テキスト“のよ
うな”画素″からなる。総ての画素は色およびフィルパ
ターンのような共通の属性を有する。大部分の画素はま
た活字の字面およびテキストスタイルのような塁固有の
属性を有する。ピクチャは”仮想画素”からなる大きな
”ワールド座標系で描かれる。

総てのデータはピクチャに形になっているので、データ
のセグメントはアプリケーションズの間で、例えばライ
ブ（１ｉｖｅ）表示装置からワードプロセッサへ自由に
コピーすることができる。中間的な書式または変換は不
必要である。このことの１つの結果はエンドユーザまた
はもとの機器メーカ（ＯＥＭ　）　ハウインド−、メニ
ュー、アイコン、エラーメツセージ、ヘルプページなど
の書式を定義するうえで完全な融通性を有するというこ
とである。

総てのそのようなピクチャはソフトウェアに組込まれる
のではなくてライブラリに記憶されるので、再びプログ
ラミング金石わずに何時でも変更することができる。ピ
クチャをオンラインで定義し修正するために包括的なエ
ディタを利用できる。

ユーザの環境との総ての対話は“仮想人力１または°仮
想出力”デバイスを介して行われる。仮想入力デバイス
はキーボード、マウス、ライトペン、アナログダイアル
、ブツシュボタンなどを受取シ、それらをテキスト、カ
ーソル位置指定、動作、ダイアル、スイッチおよびナン
バーメツセージに翻訳する。総ての物理入力デバイスは
その１組の標準メツセージにマツプしなければならない
。

１つのプロセスだけが、即ち特定のデバイス用の入力マ
ネージャだけがこの翻訳を行う責任を有する。従って他
のプロセスはその資源に依存せずに入力を処理すること
ができる。

同様に、仮想出力メツセージを特定のデバイス（スクリ
ーン、プリンタ、プロッタなど）に適した物理表現に翻
訳する。任意の端末装置に描かれた、またはプロセスに
よって描かれたピクチャはデバイスの物理的制約を条件
としてデバイス上に表示またはプリントすることができ
る。

第４図を参照すると、２つのピクチャ、即ちピクチャΔ
（１７０）およびピクチャ１１　（１７４）が示されて
いる。

’　ｋ’　ニー　（ｖｉｅｗ　）”の概念はピクチャの
特定の矩形領域を特定のデバイスにマツプするのに用い
られる。第４図において、ピクチャＡは少なくとも１つ
のビュー１７１ヲ含むものとして示されておシ、ピクチ
ャ旦は少なくとも１つのビュー１７５を含む。ビューは
例えば多重アプリケーション用のスクリーンを分割した
り、またはピクチャのページ大サブセットを印刷のため
に抽出するために用いることができる。

ビューがスクリーン上に現れると、それは１ウィンドー
“に含まれる。再び第４図を参照すると、ピクチャΔの
とニー１７１はウィンドー１７７としてスクリーン１７
６にマツプされ、ピクチャＢのビュー１７５はウィンド
ー１７８としてマツプされる。

ヒユーマンインタフェースはユーザがウィンドーの大き
さを動的に変更し、スクリーン上でウィンドーを移動し
、ピクチャの相異なる部分を見るためにウィンドーの下
のピクチャを移動する（即ち、任意の方向にスクロール
する）ことができるようにする。１つまたは複数のウィ
ンドーにマツプされたピクチャが変化すると、総てのス
クリーン上のそのピクチャの総ての影響を受けたビュー
は自動的に更新される。１つの特定のスクリーン上のウ
ィンドーの数およびサイズに論理的限界はない。このシ
ステムは分散型であるので、当然のことながらピクチャ
およびウィンドーは相異なるノード上にある。例えば、
数個の警報表示装置が単一の共通ピクチャを共用するこ
とができる。

ヒユーマンインタフェースと対話するための主要な機構
は、キーまたはボタンを押してカーソルを所望する目的
に移動させそれを選択することである。選択することに
よシ、または更に対話を行うことによって動作を自動的
に行ってもよいが、これにはメニューがしばしば用いら
れる。例えばアイコンの選択は通常は対応するアプリケ
ーションを直ちに起動させる。テキストの一部の選択後
には１カツト”または１アンダーライン”のようなコマ
ンドの選択が続くことがしばしばある。動作はキーボー
ド上の機能キーに動的にマツプすることができるので、
キーを押すことはアイコンまたはメニューアイテムを選
択することに相当する。

一定の１組のカーソル（カーソルは１つのアプリケーシ
ョンピクチャから別のアプリケーションピクチャに移動
すると変化する）、ウィンドー、メニュー、アイコンお
よび機能キーは１メタフオ”を定義する。

８５図はヒユーマンインタフェースの相異なるレベルと
それらのレベルを通るデータの流れを示す。矢印２０１
−２０９は最も一般的な経路を示すが、矢印２１０−２
１３１＠追加経路を示す。このインタフェースは不必要
な層をカスタムアプリケーションのためＫとっておくよ
うに構成することができる。

ヒユーマンインタフェース設計の背後にある考え方は、
１つの目的に１つのプロセスということを命じている。

即ち、１つのプロセスがアクティブウィンドー、ピクチ
ャ、入力または出力装置などのために作成される。この
結果、プロセスは簡略化され、殆ど任意にノード全体に
わたって分散させることができる。

多重独立ピクチャおよびウィンドー ピクチャはいかなる特定のデバイスとも関連性がなく、
そのサイズは殆ど無制限である。１ウィンドー”ピクチ
ャ情報の指定された矩形領域（これは“ビニ−″と呼ば
れる）全ピクチャから抽出し、このデータを仮想出力マ
ネージャへ送るのに用いられる。

ピクチャは互いに完全に独立している。即ち、どのピク
チャも他のピクチャの存在を知らず、どのピクチャも他
のピクチャを参照せずに、そして他のピクチャに影響を
与えることなしに更新することができる。これと同じこ
とはウィンドーについても言える。

従って、スクリーン上に見える視覚エンティティは２つ
の目的、即ち（そのフレームタイトル。

スクロールバーなどによって区別される）ウィンドー、
およびそのウィンドーのフレームの境界内に（部分的に
）見えるピクチャによって実際には表される。

この自律性の結果として、多重ピクチャを同時に更新す
ることができ、ウィンドーをスクリーン上を移動させる
ことができ、それらのウィンドーのサイズは他のウィン
ドーおよび／またはピクチャとかか）合いを持たずに変
えることができる。

また、そのようなオペレーションはウィンドーを更新し
つつあるアプリケーションとかかシ合いを持たずに行わ
れる。例えば、ウィンドーのサイズを大きくしてそのピ
クチャのよシ広込領域を見る場合には、このことは完全
にヒユーマンインタフェース内で処理される。

ヒユーマンインタフェース−主要機能 ヒユーマンインタフェースの目的は、機械可読データを
人間可読データに変換し、人間可読データを機械可読デ
ータに変換することである。このことを行うためにヒユ
ーマンインタフェースは多数のキーサービスを備えてお
シ、これらのキーサービスはユーザが自然で、首尾一貫
した方法でシステムと対話できるように統合されている
。

これらの機能を下記に説明する。

テハイス独立性。このヒユーマンインタフェースは総て
のデバイス（スクリーン、プリンタなど）を”仮想デバ
イス”として扱う。システムのテキスト、図形などはど
の特定のハードウェア構成にも結び付いていない。その
結果、そのような表現はどの“入力”デバイスからでも
入力することができ、変更せずに任意の“出力″デバイ
スに表示することができる。特定のハードウェアに特有
の性質の詳細は低レベルデバイスマネージャに隠されて
おシ、それらのマネージャは総てヒューマンインタフ二
一スソフトウエアに対する同一のインタフェースを有す
る。

からなる１ピクチヤ”、およびユーザが定義した任意の
形を描くことができる。ピクチャは殆どあらゆるサイズ
にすることができる。ヒユーマンインタフェースからユ
ーザへの総ての出力はピクチャ全弁して行われ、ユーザ
からヒユーマンインタフェースへの総ての入力はピクチ
ャとして記憶されるので、ヒユーマンインタフェース内
にはデータ表現は１つしかない。

ウィンドーインク。ヒユーマンインタフェースはユーザ
が所望する情報を見るのに必要なだけの数の１サブスク
リーン”または１ウィンドー”にスクリーンを分割でき
る能力をユーザに与える。

このヒユーマンインタフェースはそのようなウィンドウ
の内容に制限を加えず、総てのウィンドーは任意の数の
同時実行プログラムからのデータを用いて実時間で同時
に更新することができる。どのピクチャも任意のウィン
ドーに表示し、作成することができ、任意のウィンドー
において修正する（１ｍ集する”）ことができる。また
、どのウィンドーも拡張または縮小することができ、ま
たはスクリーン上の新たな位置へ何時でも移動させるこ
とができる。

現在のピクチャが現在のウィンドーよシ大きい場合には
、ウィンドーは通常は１線”または１ベージ”単位でピ
クチャ上をスクロールすることができる。ウィンドーの
寸法を変えずに、また実際のピクチャを変えずにピクチ
ャの見える部分を一時的に拡張したシ、または縮小した
シする（”ズームイン“または１ズームアウト”する）
こともできる。

対話管理。ヒユーマンインタフェースはいかなる特定の
言語または視覚表現からも独立している。

即ち、システムと対話するための組込タイトル。

メニュー、エラーメツセージ、ヘルプテキスト。

アイコンなどはない。総てのそのよりな情報は工／ドユ
ーザの要求に合うように変更できるピクチャとして導入
前または後に記憶することができる。

ユーザは供給された対話を何時でもユーザ自身の対話で
修正することができる。

データ入力。ヒユーマンインタフェースはユーザとユー
ザからのデータを要求する（データベースマネージャの
ような）プログラムとの間に汎用インタフェースを備え
ている。このサービスは”形式管理”と呼ばれる。とい
う訳は、一定のデータ構造が記述ラベルを持った多数の
修正可能なフィールドからなる空白を埋める型の１形式
“として表示されるからである。このヒユーマンインタ
フェース形式は対話型であるので、データが入力される
につれてそのデータを確認することができ、システムは
（！！求によυまたはエラーの結果として）そのことが
適当と思われる場合には説明のテキス）を表示すること
によってユーザを助けることができる。

ヒユーマンインタフェース−基本コンポーネントヒュー
マンインタフェースハ下記の基本コンポーネントを含む
。

コンソールマネージャ。コンソールマネージャはコンソ
ール文脈の中心コンポーネントであ〕、その結果その特
定の１コンソール”について総てを知っている唯一のマ
ネージャである。従って、コンソールマネージャは総て
のスクリーンおよびキーボード、総てのウィンドー、お
よび総てのピクチャを知っている。その主な責任は文脈
のアクティビティを調整することである。このことはコ
ンソールを起動させ（デバイスマネージャなどを初期設
定し）、ピクチャを作成し破壊し、ヒユーマンインタフ
ェース内およびその他の場所にあるプロセスのためにウ
ィンドーを割轟て制御することからなる。従って、コン
ソールへの総てのアクセスは関連したコンソールマネー
ジャを介して行われる間接的なアクセスでなければなら
ない。

コンソールマネージャはまたメニュー、プロンプトなど
を介してヒユーマンインタフェース対話の第ルベルを実
施するので、アプリケーションプロセスはそうする必要
はない。組込テキストおよびフオコンを用いるのではな
く、コンソールマネージャはシステムの見える機構をそ
れに備えるために対話マネージャに依存する。従って、
（言語のような）総ての文化的特質およびユーザの特質
ハヒューマンインタフェースの残部から隠されている。

コンソールマネージャは下記のプロセスを知っている。

その文脈内の出力マネージャ、その文脈内の入力マネー
ジャ、その文脈内のウィンドーマネージャ、その文脈内
のピクチャマネージャおよびその文脈内の対話マネージ
ャ。下記のプロセスはコンソールマネージャを知ってい
る。それを希望する任意のプロセス。

コンソールマネージャが開始されると、コンソールマネ
ージャは起動および１サインオン＃するためにユーザと
交信する必要のある基本プロセスを待つ。もしこれに成
功すると、コンソールマネージャはユーザおよびその他
のプロセスと話す（即ち入力マネージャおよびその他の
プロセスからメツセージを受取る）準備ができたことに
なる。

文脈内の総てのその他の永久プロセス（対話ナト）はシ
ステム起動手続くよって起動されるものと想定されてい
る。′イン”および１コンソール′プロセス（下記の“
入力マネージャ″および“出力マネージャ”参照）はこ
の時にコンソールマネージャによって作成される。

コンソールマネージャはスクリーンが空白（未使用）ス
ペース、ウィンドーおよびアイコンで構成されるにつれ
てそのスクリーンを見る。入力文字を受取るとコンソー
ルマネージャは、下記のようにカーソルの位置および入
力の型に応じてその入力文字をどのように扱うかを決定
する。

人、ウィンドーを作成または除去する要求はコンソール
マネージャ内で扱われる。

ウィンドーはスクリーン上の何処にでも、別のウィンド
ーの上にでも開けることができる。その結果新た表ピク
チャマネージャ、そして多分ウィンドーマネージャを作
成してもよく、１つまたは複数のメツセージを発生させ
てそれらのマネージャへ送ってもよく、またはそれらの
マネージャに中止するように告げてもよい。

Ｂ、アイコンはそれを選択し、次に移動させまたは開く
ことだけが可能である。

コンソールマネージャは選択および移動を直接に扱う。

コンソールマネージャは“開”の通知を対話マネージャ
へ送力、対話マネージャはそのアイコンに関連したアプ
リケーションプロセスへ通知を送力、そして多分それの
ための省略時ウィンドーを開く。

Ｃ，ウィンドー依存性動作については、カーソルが総て
のウィンドーの外にある場合には入力は違法であシ、コ
ンソールマネージャはユーザに知らせるが、さもなけれ
ばその入力は受入れられる。

（１スクロール”または１ズーム”のような）ウィンド
ー自体に影響を及ぼす要求はコンソールマネージャによ
って１接に扱われる。１選択”要求は事前にチェックさ
れ、関連画素は（メツセージを関連ピクチャマネージャ
へ送ることによって）選択され、そのメツセージは現在
そのウィンドーに責任があるプロセスへ送られる。他の
総ての入力は事前チェックなしく責任のあるプロセスへ
直接に送られる。

カーソルがウィンドーのフレーム上にあると、唯一の有
効な動作はそのウィンドーを移動させ、閉鎖し、または
そのウィンドーの寸法ｔ−変え、まタハ（メニューまた
（寥スクロールバーのような）フレーム内の目的を選択
することである。

新たなウィンドーマネージャプロセス’を作成Ｌ、それ
にウィンドーの寸法およびスクリーン上のその左上角の
位置を告げることによって新たなウィンドーが開かれる
。そのウィンドーマネージャプロセスにはピクチャマネ
ージャのＰＩＤおよび表示しようとするピクチャの部分
の座標、ならびにもしその情報が利用可能であれば１ク
リツピングポリゴン″の寸法を与えなければならｒ４い
。（ピクチャなしにウィンドーを作成することはできな
い０ウィンドー７レームの型および内容もまた指定され
る。これらのパラメータはいずれも何時でも変更するこ
とができる。

適当な名を持った新たなピクチャマネージャプロセスを
作成し、オプションとしてその画素の入手源である１フ
アイル”の名をそのピクチャマネージャプロセスに告げ
ることによって、ピクチャの新たな場合が作られる。フ
ァイルが備えられていないと、ピクチャドローイング要
求がそこに記入されることを予期して１空の”ピクチャ
が作成される。

メニュー、プロンプト、ヘルプメツセージ、エラーテキ
ストおよびアイコンは；ンソールマネージャがユーザと
対話するのに用いる（対話マネージャを介して与えられ
る）定義法ピクチャにすぎない。従って、これらはピク
チャを作成し編集することができる方法と同じ方法で任
意の特定のシステムの要求を満たすように作成し編集す
ることカテキる。メニューおよびヘルプテキストは通常
は要求があると表示されるが、時にはそれらは別のオペ
レーションの結果であるかもしれない。

ピクチャマネージャ　−　ピクチャマネージャはピクチ
ャが組立てられる時に作成され、そのピクチャがもはや
不必要となるとその作成から出る。

１つのピクチャにつき１つのピクチャマネージャがある
。ピクチャマネージャは少数の１組の基本的”画素”を
用いてピクチャのデバイス独立性表現を構成し、画素の
修正、および検索を制御する。

ピクチャマネージャは下記のプロセスを知っている。そ
れを作成したプロセスおよびドローマネージャ。下記の
プロセスはピクチャマネージャを知っている。同じ文脈
内のコンソールマネージャおよび同じ文脈内のウィンド
ーマネージャ。

ピクチャマネージャは正確に１つのピクチャを扱うため
に作成され、そのピクチャがアクセスされつつある場合
に作成される必要があるにすぎない。ピクチャに対して
は何時でも中止してそのピクチャの表現を削除するよう
に話すことができる。

ピクチャを保管する必要がある場合には、他のプロセス
がそのピクチャをファイルにコピーしなければならない
。

ピクチャマネージャが先ず最初に起動したときには、そ
の内部ピクチャは空白である。ピクチャが実際に利用可
能になる前にピクチャマネージャは“ロードファイル”
要求または一連の１ドロー“要求を受取らなければなら
ない。このことが行われるまでに、ピクチャ内の特定の
要素または位置に言及するいかなる要求も適当な１未発
見”状態メツセージを受取る。

ピクチャは論理的にはテキスト、線、弧および記号のよ
うなデバイス独立性”要素”からなる。

一般的には少数のそのような要素がある。各要素は、ピ
クチャの座標系内におけるその要素の位置。

その色、大きさなど金含む共通のヘッダ、およびその要
素の型（例えば文字列など）に−意の１値″からなる。

このヘッダはまたこの要素がピクチャ内の他の要素と結
合する（他の要素の上に重なる、他の要素とマージする
等の）方法を指定する。

入力マネージャ　−　システムに接続した（キーボード
、マウス、ライトペンなどのような）１組の“論理入力
デバイス”につき１つの入力マネージャがある。入力マ
ネージャは入力割込を扱い、それうｔ−−ンソールマネ
ージャへ送る。カーソル移動入力もまた指定された出力
マネージャへ送られる。

入力マネージャは下記のプロセスを知っている。

それを初期設定したプロセス、そして多分同じ文脈内の
１つの特定の出力マネージャ。下記のプロセスは入力マ
ネージャを知っている。同じ文脈内のコンソールマネー
ジャ。

入力マネージャはシステム内の各１組の１論理入力デバ
イスごとに（自動的にシステム起動時に）作成され、単
一１゛仮想キーボードを実施する。

コンソール文脈当たシそのような１組だけが、従って１
つの入力マネージャだけが存在しうる。各マネージャに
対するソフトウェア（メツセージ）インタフェースは同
じであるが、それらの内部挙動はそれらが交信する物理
装置によって決まる。

（マウス、デジタル化パッドなどを含む）総ての入力装
置割込サービスルーチンは入力マネージャに含まれ、他
のプロセスからは隠されている。作動可能状態になった
場合には、各入力マネージャは“コンソール１という名
を持つ最も近いプロセスへ”’　Ｉ’ｍ　ｈｅｒｅ“　
メツセージを送らなければならない。

入力マネージャは明示的に初期設定されなければならず
、入力割込の処理を開始できるようになる前に進行する
ように告げられなければならない。

これらのことはいずれも適当なメツセージを用いて行わ
れる。どのプロセスが入力マネージャを初期設定するか
はその入力マネージャに強く結合するようになる。即ち
、そのプロセスおよびマネージャは名を介してではなく
　ＰＩＤ’ｓを介してメツセージを交換することができ
る。入力マネージャは総ての入力をこのプロセス（通常
はコンソールマネージャ）へ送る。この結合は動的には
変えることができず、マネージャは再初期設定されなけ
ればならない。′初期設定”と“進行″との間に、入力
マネージャは１つまたは複数の１組”の要求を送ってそ
の挙動を定義してもよい。入力マネージャはカーソルを
非カーソルと区別する以外はいかなる入力の意味も解釈
できる必要はない。（画素のサイズおよび密度のような
）デバイス独立パラメータはダウンロードされないで、
ソフトウェアに組込まれるものと想定され、このソフト
ウェアの一部は一般的に入力マネージャの各型にとって
一意でなければならない。

入力マネージャはもし所望するならば特定の出力マネー
ジャに動的に１リンク”することができる。もしそうで
あれば、総てのカーソル制御入力（または文字セットの
任意の他の一定のサブセット）はそれが受取られると初
期設定プロセスのほかにそのマネージャも送られる。こ
の割当は何時でも変更または遮断できる。（これは出力
デバイスがスクリーンである場合にのみ一般に有用であ
る。） 一般的に、入力は、その各々が指定されたプロセスへの
（バッファに入れられていない）単一＠Ｋ”（即ちキー
ボード列）メツセージの彫金した単一１文字”として送
られる。″１けたシフト”または非語間アクセントのよ
うな一部の文字は、次の文字がタイプされ対として送ら
れるまで一時的にバッファに入れられる。総ての表示可
能なテキスト、カーソル制御コマンド、′動作”キーな
どを含む再定義可能な文字はトリプルとして送られる。

マネージャを再初期設定し適当なパラメータをダウンロ
ードし、その後に１進行″が続くことによって新たな出
力デバイスを何時でも”仮想キーボードに付加すること
ができる。このことが行われている間は総ての入力は中
断される。以前にダウンロードされたパラメータおよび
スクリーン割当は影響を受けない。同様に、デバイスを
個々に終結させることによって（デバイスに対する“１
中止”要求を送ることによって）デバイスを切ルはなす
ことができる。非特定“中止”はマネージャ全体を終結
させる。

適用できる場合には、入力マネージャは光または音発生
器（例えばベル）のようなそのデバイスに関する出力を
起動させる要求を支援する。

入力プロセスは現在の入力状態を追跡するためにその入
力マネージャのための各コンソールマネージャによって
作成される別個のプロセスである。

一般的に、これは各型（テキスト、機能キー、ポインタ
、ナンバーなど）のその最後の入力のコピー、現在の再
定義可能な文字セットナンバー、ならびに１キーボード
ロツク状態”、＠押されたキー選択”（およびダウン状
態保持）などのような状態に対する論理変数を含む。こ
のプロセスは簡単に”Ｉｎ″と名づけられている。入力
マネージャはこのプロセスを最新のものに維持する責任
がある。どのシロセスも“Ｉｎ″の内容を調べることが
できる（が変更はできない）。

出力マネージャ　−　システムに接続された物理出力デ
バイス（スクリーン、プリンタ、プロッタなど）１個に
つき１つの出力マネージャがある。

各出力マネージャは標準１ピクチャ１ｔ−その特定のデ
バイス上の適当な表現に変換する（そして多分スケール
する）。

出力マネージャは下記のプロセスを知っている。

それを初期設定したプロセスおよび同じ文脈内のドロー
マネージャ。下記のプロセスは出力マネージャを知って
いる。同じ文脈内のコンソールマネージャ、同じ文脈内
の入力マネージャ、および同じ文脈内のウィンドーマネ
ージャ。

出力マネージャはシステム内の各物理出力デバイス用に
（自動的にシステム起動時Ｋ）作成され、多数の“仮想
スクリーン”を実施する。１つのコンソール文脈につき
任意の数のそのようなデバイスを存在させることができ
る。各マネージャに対するソフトウェア（メツセージ）
インク７エースは同じでおるが、それらの内部挙動はそ
れらが交信する物理デバイスに依存する。出力割込サー
ビスルーチンは（もしあれば）そのすべてが出力マネー
ジャに含まれ、他のプロセスから隠されている。各マネ
ージャはまたそれ自身のカーソルに関する情報を保持す
るカーソルと呼ばれるプロセスを制御する。作動可能状
態になると、各出力マネージャは“Ｉ’ｍ　ｈｅｒｅ　
’メツセージ１−　　コンソール”という名を持った最
も近いプロセスへ送らなければならない。

出力マネージャは明示的に初期設定されなければならず
、それがそのデバイスに実際に書込みを開始できるよう
になる前に進行するように告げられなければならない。

これらのことはいずれも適当なヒユーマンインタフェー
スメツセージを用いて行われる。どのプロセスがマネー
ジャを初期設定するかはそのプロセス強く結びつくよう
になる。

即ち、そのプロセスとマネージャはメツセージを名によ
ってではな（ＰＩＤ’ｓによシ交換する。この結合は動
的には変更できず、マネージャは再初期設定されなけれ
ばならない。１初期設定１と１進行”との間に、出力マ
ネージャはその挙動を定義するために１つまたは複数の
１組′の要求を送ることができる。（画素のサイズおよ
び密度のような）デバイス独立性パラメータはダウンロ
ードされず、ソフトウェアに組込まれるものと想定され
、そのソフトウェアの一部は一般的に出力マネージャの
各盤にとって一意でなければならない。スクリーンのバ
ックグラウンドカラーやパターンのようなものは起動時
および任意の他の時にダウンロードすることができる。

一般的に、出力マネージャは任意のプロセス（通常はウ
ィンドーマネージャ）によってそれに送られる（標準画
素を含む）″″ドローコマンドによってドライブされる
。その主な機能は仮想画素で記述されている画素をその
特定のデバイスへの出力の適当なシーケンスに翻訳する
ことである。

出力マネージャはドローマネージャを用いて画素を複数
の組の実画素に拡張し、その結果生じたカーソル位置の
変化をカーソルプロセスに通知し続ける。出力マネージ
ャは定義済表の色および陰影パターンを探索する。゛空
１カラー（零）はそれに出会った場合には１ドローナツ
シングと解釈される。′クリア′要求も支援される。そ
れは一定の多角領域をスクリーンの省略特色および陰影
パターンに変える。

カーソルプロセスはカーソルを追跡するためにその文脈
内のコンソールマネージャによって作成される別個のプ
ロセスである。（出力マネージャと同じ名でなく）スク
リーンと同じ名を有するそのプロセスはカーソルの現在
の位置、スクリーン上のカーソルを表す総ての記号、ど
の記号が現在使用中であるか、カーソル移動コマンドが
実行されるとどれくらい多くに実画素が移動するかなど
全知っている。カーソルプロセスはこの情報のど！ れについても、どのプロセスによっても何時でもアクセ
スできる。関連出力マネージャがこのプロセスのプライ
ムユーザであυ、それを最新なものにしておく責任があ
る。関連入力マネージャは（もしそれがあれば）次の最
も共通のユーザであシ、“コマンド入力を処理する度ご
とくカーソルの位置を要求する。

対話マネージャ　−　１つのコンソールにつき１つの対
話マネージャがあフ、その対話マネージャはヒユーマン
インタフェースのための（そして多分システムの残部の
ための）メニュー、ヘルプテキスト、プロンプトなど全
定義する１ピクチヤ”のライプ２りにアクセスし、これ
らのピクチャとのユーザ対話を扱う。

対話マネージャは下記のプロセスを知っている。

なし。下記のプロセスは対話マネージャを知っている。

同じ文脈内のコンソールマネージャ。

１つの対話マネージャが各コンソール文脈内においてシ
ステム起動時に自動的に作成される。その機能は入力お
よび出力マネージャを介してユーザとの総ての視覚対話
を扱うことである。その目的はそのような対話の外部表
現をその固有の意味から切シはなすことである。例えば
、コンソールマネージャはユーザがどれ位の報告コピー
数を所望するかについてユーザに尋ねる必要があること
があるかもしれない。質問と応答の文句（ｐｈｒａｓ　
ｉｎｇ）は無関係であシ、それらはコンソールマネージ
ャが整数または多分−ｆｏｒｇｅｔ　ｉｔ”の応答で終
わる限シにおいては英語でも、スワヒリ語でも、絵文字
でもよい。

一般的に、対話マネージャには（ファイルから）ロード
するように要求したシ、またはメニュー。

エラーメツセージ、ヘルプ（通報）テキスト、プロンプ
ト、１組のアイコンなどを表すピクチャを（一定の仕様
から）動的に作成するように要求することができる。こ
のピクチャはユーザが応答するまで通常は表示される。

ヘルプまたはエラーテキストに対する応答はそのテキス
トが読取られたという肯定応答にすぎない。プロンプト
に対する応答は要求された情報である。ユーザはメニュ
ー中のアイテムを選択することによシ、またはそのメニ
ューを取消すことによシ（従ってそのメニューが生じさ
せた動作を取消すことＫよシ）メニューに応答すること
ができる。アイコンを選択し、次に移動させまたは“開
く″ことができる。アイコンを開くとその結果一般的に
は関連アプリケーションが実行される。

１選択”はコンソールマネージャへ通知ヲ送る入力マネ
ージャを介して行われる。コンソールマネージャはこの
応答を対話マネージャを介して濾過し、対話マネージャ
はそれを解釈してメツセージ中の適当なパラメータを戻
し、次にこのパラメータはサービスを要求したプロセス
へ送られる。

総ての対話はピクチャとして表され、大部分は自由書式
で表される。ヘルプおよびエラ一対話は最も簡単なもの
で′Ｉ：）り構造化されていないが、但し１つの要素は
それを”　Ｉ　ｈａｖｅ　ｒｅａｄ　ｔｈｉａ　ｔｅｘ
ｔ’応答目標記号として識別するために”タグ″が付け
られていなければならない。このテキストはユーザがこ
の要素を選択するまで表示されている。

ドローマネージャ　−　１つのコンソールにつき寸ノ １つのドローマネージャがちシ、このローマネージャは
ヒエ−マンインタフェースのために（ソシて多分システ
ムの残部のために）メニュー、ヘルプ、プロンプトなど
を定義する１ピクチヤ“のライブラリにアクセスし、こ
れらのピクチャとのユーザ対話を扱う。

ドローマネージャは下記のプロセス’ｔ−知っている。

なし。下記のプロセスはドローマネージャを知っている
。同じ文脈内のピクチャマネージャおよび同じ文脈内の
出力マネージャ。

画素をビットマツプに拡張することを要求する各文脈内
においてシステム起動時に１つのドローマネージャが動
的に作成される。その唯一の責任は１つのメツセージ内
の任意の里の１つまたは複数の画素を受取シ、１つのメ
ツセージ内の要素によって作られた図に対応するビット
マツプ（“記号＃）要素のリストを戻すことである。種
々のパラメータを各要素に適用できるが、最も重要なの
は要素を実画素に変えたシ、または仮想画素を実画素に
変換するのに用いることができるけた移動子である。ド
ローマネージャは文脈が遮断されつつある場合には文脈
から出るように告げられなければならない。

ウィンドーマネージャ　−　特定のスクリーン上の１ウ
ィンドー”の現在の場合１つにつき１つのウィンドーマ
ネージャがある。ウィンドーマネージャはウィンドーが
開かれた時に作成され、ウィンドーが閉じると出る。ウ
ィンドーマネージャは一定のスクリーン上の一定の大き
さの矩形領域に一定のピクチャ（またはその一部）′ｆ
：マップする。

即ち、ウィンドーマネージャは装置独立ピクチャを装置
依存スクリーンにリンクする。′フレーム”をウィンド
ー〇周シに描くことができ、その境界をマークし、タイ
トルまたはメニューのような他の情報を含むことができ
る。各マネージャはまたそのウィンドーの内容が変化し
た場合にはスクリーンを更新する責任がある。

ウィンドーマネージャは下記のプロセスを知っている。

それを作成したプロセス、同じ文脈内の１つの特定のピ
クチャマネージャ、および同じ文脈内の１つの特定の出
力マネージャ。下記のプロセスはウィンドーマネージャ
を知っている。同じ文脈内のコンソールマネージャ。

ウィンドーマネージャの主要ジョブは画素をピクチャの
一定の矩形領域から特定のスクリーン上の（”ウィンド
ー″と呼ばれる）矩形領域にコピーすることである。こ
のことを行うために、ウィンドーマネージャは正確に１
つのピクチャマネージャと１つの出力マネージャと対話
する。ウィンドーマネージャはスクリーン上でウィンド
ーが°開かれた時にだけ作成される必要があシ、（関連
ピクチャに影響を与えることなしに）ウィンドーが”閉
じられ九″時に中止するように告げられることができる
。開かれるとモトローラはそのウィンドーのアウトライ
ン、フレームおよびバックグラウンドを描かなければな
らない。閉じられるとそのウィンドーおよびそのフレー
ムは消去されなければならない（即ちスクリーンのバッ
クグラウンドカラーおよびパターンに再び描かなければ
ならない）。ウィンドーの１移動＃（スクリーン上のそ
の位置の変更）は本質的にはウィンドーの閉鎖および再
開と同じである。

ウィンドーマネージャはコンソールマネージャによって
のみ作成および破壊が可能であシ、コンソールマネージ
ャはスクリーン上にウィンドーを配列したシ、オーバラ
ップをなくしたシする等々の責任がある。ウィンドーマ
ネージャが作成されると、ウィンドーマネージャは１初
期設定”メツセージを待ち、自らを初期設定し、ウィン
ドーマネージャへ“初期設定”メツセージを送ったプロ
セスへ−Ｉ’ｍ　ｈｅｒｅ　＝メツセージを戻し、次に
更に追加のメツセージを待つ。ウィンドー１ネージヤは
それが下記の総てを受取るまでは出力マネージャへいか
なるメツセージも送らない。その寸法（フレームは除く
）、アウトラインのラインタイプ。

サイズおよびカラー、バックグラウンドカラー。

スクリーン上の位置、クリッピングポリゴン、けた移１
およびフレーミングパラメータ、ウィンドーマネージャ
はまたウィンドー内で（常に基本制御を有するコンソー
ルマネージャを介して）コマンドを扱う特定のプロセス
である“オーナ”を有する。

上記のパラメタはどれも何時でも変えることができる。

一般的に、（オーナ以外の）パラメータを変えるとスク
リーン上にウィンドーが再び描かれる。

ウィンドーの各ヘシに沿って１つずつある（蟻バー”と
呼ばれる）４つのコンポーネントからなる１フレーム＃
を一定のウィンドーの周シに置いてもよい。それらのバ
ーは頂部、低部、左側および右側に指定されている。そ
れらのバーは単純な線のセグメント、タイトルバー、ス
クロールバー、メニューバー、およびパレットバーの任
意の組合せとすることができる。これらのバーは標準画
素の（４つの別個のメツセージ中の）４つの別個のリス
トとしてメツセージへ供給され、これらのリストはその
バーを参照する新たなメツセージ中癌ることによって何
時でも変更できる。各バーの原点はウィンドーの左上角
に対応する［　０．０　］である。

コンソールマネージャはそのパラメータのいずれかにつ
いてウィンドーマネージャに間合せてもよく、その間合
せに対してウィンドーマネージャはそれが最初に受取っ
たメツセージとおなしメツセージで応答する。コンソー
ルマネージヤニ対シてはまた一定の絶対カーソル位置が
そのウインド−内（即ち現在のクリッピングポリゴン内
）にあるかまたはそのフレーム内にあるかを尋ねること
ができ、ウィンドーまたはフレームのいずれかのヘシの
原点に対応するカーソル座標を要求することができる。

ウィンドーマネージャはそのクリエータ（コンソールマ
ネージャ）、ピクチャマネージャ、および出力マネージ
ャに強く結合している。即ち、それらはプロセス−意名
（ＰＩＤ’５）ｔ−用いて互いに交信する。この結果、
ウィンドーマネージャは出る時にはピクチャマネージャ
に通知しなければならず、ウィンドーマネージャはピク
チャマネージャも同じことをすることを期待する。

ひとたびウィンドーマネージャがアクセスしつつあるピ
クチャおよびそのウィンドーの寸法（またはこれらのい
ずれかが変化する時）を知ると、ウィンドーマネージャ
は完全に、または部分的にそのウィンドー内にある総て
の画素をウィンドーマネージャに送るよりにピクチャマ
ネージャに要求する。ウィンドー内ネ・−ジャはまたピ
クチャの表示された部分に影響する変化をウィンドーマ
ネージャに通知するようにピクチャマネージャに要求す
る。ピクチャマネージャはこれらの要求を満たすために
（任意の時Ｋ）“ドロー″メツセージをウィンドーマネ
ージャへ送る。

ウィンドーマネージャはそれが受取る総ての画素につ込
てグ四スクリツビングを行り。即ち、ウィンドーマネー
ジャは各画素が現在のクリッピングポリゴン内に現れる
ことができるかどうかを決定するにすぎない（このポリ
ゴンはもし他のウィンドーがこのウィンドーにオーバラ
ッグしていると成る瞬間にはこのウィンドーよシ小さい
ことがあるかもしれない）。

ウィンドーマネージャは厳密に仮想画素に関係し、ウィ
ンドーマネージャが書込みを行いつつあるスクリーンの
物理特質については知らない。この結果、ウィンドのサ
イダンよび位置は仮想画素で指定され、もしこれらが異
なると実画素からの変換を暗に示す。

プリントマネージャ　−　１つの“出力サブシステム”
につき、即ち出力デバイスの１つのプールにつき１つの
プリントマネージャがある。プリントマネージャはハー
ドコピーデバイスに対する（即ちそれらの出力マネージ
ャに対する）出力を調整スる。プリントマネージャはプ
リントする必要のあるファイルのための包括的待合せサ
ービスをする。プリントマネージャはまたテキストの最
小限の書式化（位置合せ、自動ページナンバーリング、
ヘッダ、フッタなど）を行うことができる。。

プリントマネージャは下記のプロセスを知っている。お
なし文脈内の出力マネージャ、および同じ文脈内のピク
チャマネージャ。下記のプロセスはプリントマネージャ
を知っている。それを所望する任意のプロセス。

各プリント文脈内の１つのプリントマネージャが起動時
に自動的に作られる。プリントマネージャはハードコピ
ー出力に対する一般要求を受取フ、それらを一時に（通
常は出力の一本の線に対応する）１メツセージす゛つ適
当な出力マネージャへ送ることが期待されている。プリ
ントマネージャはまたファイルを（即ちファイルマネー
ジャプロセスを）参照する要求を受取ることができる。

゛スプール”要求として知られるそのような各メツセー
ジは優先順位、所望するコピー数、（もしあれば）ｑ＃
定の出力デバイス要求および（もしあれば）特別な形式
要求を含む。これらのパラメータならびにファイルのサ
イス゛、要求が待っている時間の量、出力デバイスの可
用性に基づいてプリントマネージャは懸案になっている
要求の項序付けられたキューを維持する。プリントマネ
ージャはそれらの要求を一時に１つずつキューから外し
、出力マネージャを選択し、（ピクチャマネージャを周
込て）ピクチャを構成する。次にプリントマネージャは
ファイル全体がプリントされるまで一時に１″″ページ
”ずつ（ピクチャマネージャから）要求して１プリント
＃（プロットなど）する。

ヒユーマンインタフェース−コンポーネント間の関係８
つのヒユーマンインタフェースコンポーネントが一緒に
なって最小限のヒユーマンインタフェースを支援するの
に必要なサービスの総てを行う。

それらのコンポーネント間の関係は第６図に示してあシ
、この図は各コンポーネントの少なくとも１つの場合を
示す。円３０１．３０２．３０７．３１２．３１５およ
び３１７−３２０によって浅されるコンポーネントは一
般的に常に存在しアクティブであるが、その他のコンポ
ーネントは必要に応じて作成されその特定の機能が終わ
ると出る。第６図は２つの主文脈、即ち１コンソール”
３５０と１プリント１３５１に分けられる。

カーソル３１４および入力３１１はその一次機能がデー
タの記憶であるプロセスの例である。′カーソル”の目
的はスクリーン上の現在のカーソル位置およびカーソル
に関連した（相異なるカーソルを定義する記号などの）
総てのパラメータを追跡することである。出力マネージ
ャが初期設定されるとその各出力マネージャごとに１つ
のカーソルプロセスがコンソールマネージャによって作
成される。出力マネージャはカーソルデータを更新する
責任があるが、”カーソル”に対する間合せは誰が行っ
てもよい。“入力”は１選択キーが押鍵されている”、
′キーボードがロックされている”などの現在の入力状
態を追跡する。各コンソールマネージャによって１つの
入力プロセスが作られる。コンソールの入力メツセージ
はプロセスを更新し、他のプロセスがそれを間合せても
よい。

ヒユーマンインタフェースは文脈として実施されるサブ
システムの集まシとして構成され、各サブシステムはイ
ンタフェースの１つの広い領、域に責任２＞１　する。

ヒユーマンインタフェースの外カラアクセスできる２つ
の主要文脈がある。即ち、”コンソール”と１プリント
”である。これらの文脈は総てのスクリーン／キーボー
ド対話と総てのハードコピー出力をそれぞれ扱う。これ
らの文脈は必ずしも一意である必要はない。システム内
に各文脈の１つまたは複数の場合があってもよく、同じ
セルに数個の場合がある可能性がある。各場合に入れ子
形文脈のいくつかのレベルがあってもよい。

種々のヒューマンイニ／タフエースコンポーネント間の
可能性のある対話について説明する。

コンソールマネージャ／その他の文脈−その他の文脈の
プロセスはコンソールサービスの要求または関連事象の
通知の要求″Ｉｋ［接にコンソールマネージャへ送って
もよい。コンソールマネージャはメツセージを適当なサ
ービスへ送る。コンソールマネージャはまたウィンドー
内の目的が選択されると（“状態”メツセージを介して
）そのウィンドーの現在のオーナに通知する。同様にコ
ンソールマネージャは、ユーザが特定のウィンドー内の
アプリケーションを要求するとメツセージをそのアプリ
ケーションへ送る。

コンソールマネージャ／入力マネージャ　−　コンソー
ルマネージャは入力マネージャを初期設定し、通常はそ
れに特定の出力マネージャを割当てる。入力マネージャ
は常に総ての入力（一時に１つの文字、１つのキー、１
つのカーソル移動など）を直接にコンソールマネージャ
へ送る。入力マネージャはまた１ダウンロード、″″初
期設定”または“終結“要求に応答して、または異常が
起きた時に゛状態”メツセージを送ってもよい。

コンソールマネージャ／出力マネージャ　−　コンソー
ルマネージャはシステム起動および遮断の期間中にピク
チャおよびウィンドーを用いずにその”基本１出力デバ
イスに情報を表示する。従ってコンソールマネージャは
画素ｔ−直接に出力マネージャへ送る。コンソールマネ
ージャはまたもし適用可能であればシステムの実行中に
カーソルをスクリーン上で移動させる責任がある。コン
ソールマネージャ（または”エティタ”のような任意の
他のヒユーマンインタフェースマネージャ）ハ現在のカ
ーソルを任意の表示可能な記号に変えてもよい。出力マ
ネージャは異常が起きた時にはコンソールマネージャへ
１状態”メツセージを送る。

コンソールマネージャ／ピクチャマネージャーコンソー
ルマネージャはもし適用可能であれば、要求のあシ次第
ピクチャマネージャを作シ、そのピクチャマネージャの
各々に画素を含むファイルの名を告げる。ピクチャマネ
ージャはまたピクチャに個々に画素を追加し、画素を削
除し、画素をコピーし、画素を移動させ、画素の属性を
修正し又は画素を変換するためにコンソールマネージャ
（または他のだれか）から要求を受取る。ピクチャ内の
一定の位置における（ｔたはその一定の位置の近くの）
画素の値をピクチャマネージャに間合せることができる
。コンソールマネージャはピクチャマネージャに対して
そのピクチャを消去するように告げ、それがもはや必要
でなくなった場合には出る。ピクチャマネージャは何か
異常なこと（例えばエラー）が起きると通常は”状態″
メツセージをコンソールマネージャへ送る。

コンソールマネージャ／ウィンドーマネー　シー’ｒ−
コンソールマネージャは要求があシ次第ウィンドーマネ
ージャを作る。各ウィンドーマネージャはそのサイズ、
出力マネージャのＰＩＤ　、その左上の外角の（スクリ
ーン上の）座標、そのフレームの特性、特定のピクチャ
マネージャのＰＩＤ　、ビづクチャ表示が始まる第１画
素の座標、およびそのウィンドーを“所有する１グロセ
スの名を告げられる。ウィンドーがアクティブであると
、異なる画素で始まる同じピクチャを再び表示すること
、または完全に異なるピクチャを表示することをウィン
ドーマネージャに要求することができる。

ウィンドー自体の座標を変えてスクリーン上でウィンド
ーを移動させてもよく、またはウィンドーにそのサイズ
、フレームまたはオーナを変えるよりに告げてもよい。

ウィンドーマネージャに対して一定のポリゴンのヘシ（
省略時ポリゴンはウィンドーのフレームの内側のヘシで
ある）に沿ってその表示装置における画素を”クリップ
”するように告げることができる。一定の座標に対応す
る画素をウィンドーマネージャに間合せることができる
。コンソールマネージャはウィンドーマネージャにその
ウィンドーｆ：＠閉じるｍ（消去する）ように告げ、そ
れがもはや不必要になった時には出る。ウィンドーマネ
ージャはコンソールマネージャに”状態′メツセージを
送シ要求の成功または失敗を示す。

コンソールマネージャ／対話マネージャ　一対話マネー
ジャはメニュー、プロンプト、エラーメツセージなどを
表す“ピクチャ＃をロードおよび／または動的に作成す
る要求を受取る（メニューのような）対話型ピクチャの
場合には、対話マネージャはまたコンソールマネージャ
のための応答全解釈する。その他のプロセスもまたコン
ソールマネージャを介して対話マネージャを用いてもよ
い。

コンソールマネージャ／プリントマネージャー〃　コン
ソールマネージャは一般に１スプール”要求をプリント
マネージャへ送夛スクリーンマタはピクチャの・・−ド
；ビｉる。アクティブピクチャが最初にファイルにコピ
ーされなければならない。プリントマネージャは要求が
完全であるかまたは失敗すると”状態”メツセージを戻
す。

ウィンドーマネージャ／ピクチャマネージャー÷　ウィ
ンドーマネージャはピクチャ内の矩形“ビューボート“
に座標によって指定された。関連ピクチャマネージャか
らの１つまたは複数の画素のりストｔ−要求する。ウィ
ンドーマネージャはまたピクチャマネージャに対し変更
（新たな。

修正された。または消去された画素）または変更の通知
だけを自動的にウィンドーマネージャへ送るように要求
することができる。ピクチャマネージャは゛状態”メツ
セージを送シ変更またはエラーｔウィンドーマネージャ
に通知する。

ウィンドーマネージャ／出力マネ）ヤ　−　ウィンドー
マネージャは、出力マネージャが画素を描く時にそれに
よシ画素を”クリップ″するポリゴンの座標によってグ
レフィクスされた画素のリストをその出力マネージャへ
送る。一定の画素リストはその寸法のどの次元の一定の
けた移動子によってもスケールすることができる。出力
マネージャは要求が失敗すると１状態”メツセージを戻
す。

入力マネージャ／出力マネージャ　−人力マネージャは
総てのカーソル移動入力を事前割当てされた出力マネー
ジャがあればその出力マネージャへ送シ、マたコンソー
ルマネージャへも送る。この割当は動的に変更できる。

プリントマネージャ／その他のプロセス　−　プリント
マネージャはファイルを°スプール′する。

または１つまたは複数の画素を１プリント”する要求を
受取る。プリントマネージャはその要求が完了した時に
、またはその要求を実行できないと１状態”メツセージ
を送る。キューに登録された要求の状態を間合せること
ができ、または何時でも変更できる。

プリントマネージャ／ファイルマネージャ　−プリント
マネージャは（その名が１スプール＃要求を介してプリ
ントマネージャへ送られた）ファイルマネージャから画
素を読取る。プリントマネージャはピクチャのプリント
を終えた後にファイルを“削除”する要【をファイルマ
ネージャへ送り返してもよい。

プリントマネージャ／ピクチャマネージャ　−プリント
マネージャはプリントマネージャが現在プリントしつつ
あるスプールされた各ピクチャ用のピクチャマネージャ
を作シ、それに関連ファイル名を与える。次にプリント
マネージャは（出力デバイスの特性に応じて）ピクチャ
の１ページ″を一時に１つずつ要求する。最後に、プリ
ントマネージャはピクチャマネージャに立ち去るように
告げる。

プリントマネージャ／ｌ１１：１カマネージヤ　−　プ
リントマネージャは画素を出力マネージャへ送る。

出力マネージャは要求が完了するか、または失敗すると
、またはプリンタに異常が起きると１状態“メツセージ
を送る。

ドローマネージャ／その他のグロセス　−　ドローマネ
ージャは明示的画素パラメータ（密度、けた移動子など
）によってグレフィクスされた要素のリストを受取る。

ドローマネージャは、それが受取る各メツセージのため
に描かれた結果のビットマツプ（゛記号″）要素のリス
トを含む単一メツセージを戻す。

ヒユーマンインタフェース　−　サービスヒユーマンイ
ンタフェースサービスは要求メツセージ１最も近ＩＡ（
即ち次の”）ヒユーマンインタフェースマネージャへ送
ることによって、または直接に特定のコンソールマネー
ジャへ送ることによってアクセスされる。このことは現
在あるヒユーマンインタフェース資源への接続全行い、
または新たなヒユーマンインタフェース資源を作成する
。その後の要求は、その接続が破られるまで初期要求か
ら戻されたコネクタを用いて資源に直接性われなければ
ならない。ヒユーマンインタフェースマネージャは分散
しておシ、従って仮想計算機全体にわたっている。資源
は特定のノードに関連している。

ピクチャのサイズはどのようなものでもよく。

物理スクリーンまたはウィンドーより大きいこともしば
しばある。ウィンドーはそれ炉゛現れるスクリーンと同
じだけの大きさでもよい。単一スクリーン上にピクチャ
を同時に光示する任意の数のウィンドーがあってもよい
。ウィンドーにマツプされるピクチャを更新するとスク
リーン表示も自動的に更新される。いくつかのウィンド
ーを異なる座標において同じピクチャに同時にマツプし
てもよい。

ヒユーマンインタフェースによって与えラレル入カモデ
ルは“仮想デバイス“の２つのレベルからなる。下位レ
ベルは特定のウィンドーに関連した゛位置“、″″文字
″、°動作”および“機能キー′デバイスを支援する。

これらはシステムに接続した実際のデバイスに関係なく
一貫して支援される。

オプションとしての上位レベルは１対話サービス”から
なシ、この対話サービスは”アイコン”。

１メニユー”、′プロンプト１．′値”、および°精報
ボックスを装置独立性対話のレパートリに加える。入力
は通常は（メツセージを介して）事象によシトライブさ
れるが、サンプリングされたシ、または明示的に要求さ
れることもある。

総ての寸法は１仮想画素”によって示される。

仮想画素は縦横対称の測定単位である。仮想画素ｌ雀特
定のサイズを持たない。その唯一の目的は画素間の空間
関係を定めることである。実際のサイズはピクチャが表
示された場合にそのピクチャが指向する出力デバイスに
よって決められる。１つの仮想画素は１つの実画素の任
意の倍数（分数を含む）に変換できる。

コアヒユーマンインタフェースの使用バ一般に下記を含
む。ピクチャを作成する（または定義済ピクチャにアク
セスする）こと、特定のスクリーン上にウィンドーを作
成しピクチャ全それに接続させること、ピクチャを更新
して（新たな要素を描き、古い要素を移動または消去す
るなどして）アプリケーションの変化（例えば新たなデ
ータ）を反映させること、アプリケーションが対話型で
ある場合には入力を繰シ返しウィンドーから受取シ、そ
れに従って動作すること、作業が終わったらピクチャお
よび／またはウィンドーと削除すること。

新資源の作成は、適当な資源マネージャ（即ちヒユーマ
ンインタフェースマネー　シャｔ　７’ｃ　ハコンソー
ルマネージャ）に向けられた適当な“作成”メツセージ
によって行われる。資源、特にウィンドーが作成される
と、多数のオプションが可用になる。例えば、典型的な
アプリケーションは特定のキーが押された時を知らされ
ることを望むかもしれない。ポツプアップおよびプルダ
ウンメニューおよび機能キーもまたウィンドーのために
定義されるかもしれない。

ヒユーマンインタフェースからの総ての入力は１クリツ
ク”メツセージによって送られる。このメツセージの意
図は、アプリケーションプログラムをできるだけ外部入
力から独立させることである。この結果、ポツプアップ
メニューが発生させた１クリツク”は、機能キーを押し
てまたはアオコンを選択して発生させたものと非常に良
く似たものになる。事象がドライブさせる入力はキーボ
ードまたはマウスのような外部デバイスと対話するユー
ザによって開始される。この場合には、“クリック″は
非同期に送られ、多重事象がキューに登録される。

プログラムはまたメニュー、プロンプトなどを用いて明
示的に入力を要求してもよく、この場合にはその要求が
満たされた時にのみ１クリツク”が送られる。

直接的にはユーザを含まない第３の入力方法は、仮想入
力デバイスの現在の状態（例えば現在のカーソル位置）
を間合せることである。

１クリツク″メツセージは特定のウィンドーに関連して
おシ（そして含意によシ通常は特定のピクチャに関連し
てお））、或はまた対話１メタフオ”に関連しておシ、
それによ勺入カモデルの２つのレベル全反映する。

ヒユーマンインタフェースの視覚アスヘクトハアブリケ
ーションアスペクトから分離されているので、ウィンド
ー、メニュー、アイコンなどのその後の再設計は現在あ
るアプリケーションに殆んヒユーマンインタフェース−
詳細な説明コネクタ 一般的にいうと、ヒユーマンインタフェース資源（コン
ソール、ウィンドー、ピクチャまたは仮想端末）との総
ての対話はその資源に対するコネクタを介して行われな
ければならない。コンソールに対スるコネクタはヒユー
マンインタフェースこシ マネージャから得ることができる。その他の資源に対す
るコネクタはヒユーマンインタフェースマネージャを介
して、またはその中に所望する資源があるコンソールマ
ネージャを介して利用できろ。

要求は下記のように資源の経路名を指定しなげればなら
ない。

（＜ｃｏｎｓｏｌｅ−ｎａｍｅ＞）（／＜　ｓｃｒｅｅ
ｎ−ｎａｍｅ＞　）（／＜ｗｉｎｄｏｗ　ｏｒ、、−ｐ
ｉｃｔｕｒｅ−ｎａｍｅ　＞、１即チ、コンソールの名
の後にオブンヨンとしてスラックスとスクリーン名が続
き、その後にオプションとしてスラックスとウィンドー
、ピクチャまたは端末の名が続く。メツセージが所望す
るコンソールマネージャに直接に送られる場合にのみコ
ンソール名は省略できる。スクリーン名が省略されると
、一定のコンソール上に構成された第１スクリーンが想
定される。これらの資源のうちの１つが接続されている
場合には、ウィンドー名が指定されなければならない。

接続要求 １作成′および′開放′要求は“次の′ヒユーマンイン
タフェース文脈（’ＨＩ”）または特定のコンソールコ
ネクタ、または′コンソール′という名の１次の′文脈
ヘアドレスすることができる。’　ＨＩ　’へ送られる
場合には、全経路名（名パラメータ）が与えられなけれ
ばならないが、さもなければ所望する資源の名だけが必
要とされる（例えば、最小限ウィンドーまたはピクチャ
の名だけは必要とされる）。

ピクチャマネージャプロセスが専用にアプリケーション
によって局所的に作成されると、′作成′または１開放
′と同じ内容を持った’１ｎｉｔ’メツセージがピクチ
ャプロセスに直接に送られなければならない。その応答
は′ダン′または′失敗′である。

下記は種々の接続要求およびその各要求に関連している
かもしれない情報の型である。

ＣＲＥＡＴＥ　（作ＪＲ）は新たなピクチャ資源。

新たなウィンドー資源またはあらたな仮想端末資源を作
成するのに用いられる。

新たなピクチャ資源を作成するのに用いられた場合には
、ＣＲＥＡＴＥは資源型（即ち′ピクチャ′）、そのピ
クチャの経路名、サイズ、バックグラウンドカラー、ハ
イライトする方法、要素の最大数、最大要素サイズ、お
よびそこから他の要素をコピーできるライブラリピクチ
ャの経路名に関する情報を含むことがある。

新たなウィンドー資源を作成するのに用いられた場合に
は、ＣＲＥＡＴＥは資源型（即ち′ウィンドー′）、そ
のウィンドーの経路基、ウィンドーのタイトル、スクリ
ーン上のウィンドーの位置。

ウィンドーのサイズ、カラー、幅、アウトラインとベイ
ンとの間のフィルカラー、および主要ウィンドーアウト
ラインのスタイル、ペインアウトラインのカラーおよび
幅、ピクチャの一部のウィンドー内へのマツピング、変
更表記法、特殊文字表記法２種々のオプション、ウィン
ドー上またはウィンドー内での種々の指定された動作の
通知を要ｉｆる’ｗｈｅｎ’パラメータ、タイトルバー
、パレットバー、垂直および水平スクロールバー、汎用
バー、およびコーナーボックスに関する情報を含むこと
がある。

新たな仮想端末を作成するのに用いられた場合には、Ｃ
ＲＥＡＴＥは資源型（即ち”端末′）。

端末の経路名、端宋のウィンドーのタイトル、種々のオ
プション、スクリーン上の端末の位置、端末のサイズ（
即ちウィンドー内の行と列の数）。

仮想スクリーンの最大の高さと幅、ウィンドー内のカラ
ーおよびテキスト、タブ、エミュレータプロセス、現存
するウィンドーへのコネクタ、ウィンドーフレームカラ
ー、メニューアイテムのリストおよび代わりの書式に関
する情報を含むことがある。

０ＰＥＮ（開放）はヒユーマンインタフェースサービス
または現存のヒユーマンインタフェース資源へ接続する
のに用いられる。ヒユーマンインタフェースサービスへ
接続するのに用いられた場合には、０ＰＥＮはサービス
型、およびサービスの特定の場合の名に関する情報を含
むことがある。

この資源はヒユーマンインタフェース文脈へ送うれなげ
ればならない。

現存する　゛　　　　　インタフェース資源に接続する
ために用いられる場合には、０ＰＥＮは資源の経路名、
５に源の型（例えばピクチャ、ウィンドーまたは端末）
、およびそこからピクチャｔマンインタフェースマネー
シャマタハコンソールマネージャへ送ることができるが
、その代わりにファイルを指定するメツセージ１．Ｄ、
　’ｉｎ　ｉ　ｔ”ｆｊ（持った同一メツセージを専用
に所有されているピクチャマネージャへ直接に送ること
もできる。

ＤＥＬＥＴＥ　（削除）は現存するヒユーマンインタフ
ェース資源をシステムから除去するのに用いられ、資源
への接続、−資源の型、およびウィンドーのために対応
するピクチャが同時に削除されるかどうかを指定する情
報を含むことがある。

ＣＬＯ８Ｅ（閉ａ）はヒユーマンインタフェース資源へ
の接続を断つのに用いられ、資源への接続、および資源
の型を指定する情報を含むことがある。

ＷＨＯ？（ｉＡ？）はサインド・オンユーザのリストを
要求するのに用いられ、ユーザ識別列を含むことがある
。

ＱＵＥＲＹ（間合せ）はサービスまたは資源の状態を得
るのに用いられ、資源型、サービスまたは資源の名、ソ
フトウェアへの接続、および種々のオプションに関する
情報を含むことがある。

下記は種々の接続応答およびその各応答に関連するかも
しれない情報の型である。

Ｃ０ＮＮＥＣＴ　（接続）はヒユーマンインタフェース
資源との接続を行い、オリジネータ（即ちヒユーマンイ
ンタフェースまたはコンソール）。

資源型、もとの要求メツセージ−意名、資源の名。

および資源へのコネクタに関する情報を含むことがある
。

ＵＳＥＲ（ユーザ）は零またはそれより多い現在サイン
・オンされているユーザの名およびそれらの位置を含み
、それはまたコンソールマネージャへのコネクタおよび
それに続くそのコンソールにおいてサイン・オンされて
いるユーザの名を含む。

コンソール要求 コンソールの主目的はそれに関連したウィンドー、ピク
チャおよび対話のアクティビティを調整することである
。上述したＣＲＥＡＴＥ、０ＰＥＮ、ＤＥＬＥＴＥおよ
びＣＬＯ８Ｅ接続要求はいずれも（但しコンソールに関
係あるものは除く）（名により常にコンソールを探索ス
ル’）　ヒ３−−−’ンインタフェースマネージャへで
はなく既知のコンソールマネージャへ直接に送ることが
できる。

この結果、サイズのようなウィンドーの特性の一部はコ
ンソールマネージャにより動的に変更できる。コンソー
ルの現在の１ユーザ′を変更することができる。そして
コンソールに対してはその現在の状態（またはその資源
のうちのいずれかの状態）を間合せることができる。

下記は種々のコンソール要求およびその各要求と関連が
あるかもしれない情報の型である。

ＵＳＥＲ（ユーザ）は現在サイン・オンされているユー
ザを変更するのに用いられ、ユーザ識別列を含む。

ＣＨＡＮＧＥ　（変更）はウィンドーのサイズおよびそ
の他の条件を変更するのに用いられ、ウィンドーまたは
端末へのコネクタ、（仮想画素の新たな高さと幅、高さ
および幅の増分９行および列の位置９種々のオプション
、新たなオーナプロセスへのコネクタ、およびそのウィ
ンドーをスクリーン上の現在のアクティブウィンドーと
丁ベキカどうかに関する情報をふくむことがある。

ＣＵＲ８ＯＲ（カーソル）はスクリーンカーソルを移動
させるのに用いられ２行および列に関する位置情報を含
む。

ＱＵＥＲＹ（問合せ）はコンソールおよびその資源のう
ちの１つの現在の状態を得るのに用いられ、資源へのコ
ネクタ、および種々の間合せオプション（例えば総ての
スクリーン、総てのピクチャまたは総てのウィンドーの
リスト作成）の形の情報を含む。

ＢＡＮＤ　（バンド）はラババンディング（ｒｕｂｂｅ
ｒ−ｂａｎｄｉｎｇ　）機能およびドラッギング（ｄｒ
ａｇｇｉｎｇ　）機能を開始／停止し、そこからオペレ
ーションを始めるピクチャ内の点の位゛菫、ドラッグさ
れる図の終点、オペレーションの飄（例えば線、矩形。

円または楕円）、カラー、および線の型（例えば実線）
に関する情報を含む。ラババンディングにおいては、描
がれた図はカーソルが移動するにつれてそのサイズが変
化する。ドラッギングにおいては１図はカーソルととも
に移動する。

下記は徨々のコンソール応答およびその各応答に関連が
あるかもしれない情報の型である。

５ＴＡＴＵＳ　（状ｇ）はコンソールの現在の状態を述
べ、それはコンソールへのコネクタ、オリジネータ、コ
ンソール名、現在のコンソールの位置、現在のメタ７オ
のサイズ、垂直および水平方向の１　ｒｍ当たりの仮想
画素のスケール、支援されるカラーの数、現在のユーザ
識別列、スクリーンの名およびサイズ、ウィンドーコネ
クタおよび名。

およびピクチャコネクタ、スクリーン名およびウィンド
ー名に関する情報を含むことがある。

ピクチャドローイング ピクチャはヒユーマンインタフェースにおける基本的ビ
ルディングブロックである。ピクチャは。

その各々が表示可能な目的（線、テキストなど）の装置
独立性抽象である零またはそれより多い“画素′のリス
トからなる。現在アクティブな各ピクチャは別個のピク
チャマネージャによって記憶され維持される。ピクチャ
ｔ＃ドロー′することはピクチャ操作メツセージをピク
チャマネージャへ送ることからなる。

ピクチャマネージャは先ずＣＲＥＡＴＥまたは０ＰＥＮ
要求により（または、そのピクチャが専用に作成された
場合にはＩＮＩＴにより）初期設定されなげればならな
い。ＣＲＥＡＴＥはピクチャを空（ｅｍｐｔ）’）にセ
ットし、それに名を与え。

そのバックグラウンドを定義する。０ＰＥＮ要求はファ
イルから定義済ピクチャを読取り、それに名を与える。

それらはいずれも他の事が行われる前に先ず最初に送ら
れなければならない。その後の０ＰＥＮはそのファイル
からピクチャを再ロードする。

基本要求は１つまたは複数の要素をＷＲＩＴＥすること
である。ＷＲＩＴＥは新たな要素を現在のリストの宋尾
に加え、従ってそのｌ１ｊｌ序を反映する。ピクチャの
部分がコピーまたは表示されると。

この順序は保存される。ひとたび描かれると、１つまた
は複数の要素を移動、消去、コピーまたは置換すること
ができる。ピクチャの全部または一部は一定のファイル
に保管することができる。更に、１つまたは複数の要素
の特定の属性を速やかに変更する（例えばそれらを選択
する）要求がある。最後に、（コンソールマネージャへ
の）ＤＥＬＥＴＥ要求（ピクチャ資源を指向する場合に
はＱＵＩＴ要求）はピクチャを保管せずにピクチャマネ
ージャを終結させる。

ピクチャは画素に“ａｐｐＬ’フィールドをセットする
ことによっていくつかのプロセス（′アプリケークヨン
′）の間で共用することができる。各アプリケーション
プロセスはあたかもそれが自分自身の要素のみを含むか
のようにピクチャな処理することができる。各プロセス
によってなされた総ての要求はマツチング’ａｐｐｌ’
　フィールドを含む要素に影響を与えるにすぎない。参
加プロセスはＷ　ａ　ｐ　ｐ　ｌ　＃要求を介してピク
チャマネージャに対して識別されなげればならない。

下記は種々のピクチャドローイング要求およびその各要
求に関連しているかもしれない情報の型である。

ＷＲＩＴＥＣ書込）は新たな要素をピクチャに加えるの
に用いられ１画素のリスト、データ型。

一定の範囲に発見される第１要素の後に（フォアグラウ
ンドの代わりに、リストの終わりに）新たな要素を加え
る表示を与える情報を含むことがあるかもしれない。

ＲＥＡＤ　（読取）はピクチャから要素をコピーするの
に用いられ、そこへ要素が送られる接続。

バックグラウンド要素をコピーする表示、およびコピー
される成る範囲の要素に関する情報を含むことがあるか
もしれない。

ＭＯＶＥ　（移動）は要素を別の場所へ移動させるのに
用いられ、要素の移動先であるピクチャ内の点９行およ
び列オフセット、ピクチャフォアグラウンド向き、ピク
チャバックグラウンド向き。

固定サイズ増分、および移動される成る範囲の要素を示
す情報を含むことがあるかもしれない。

ＲＥＰＬＡＣＥ　（置換）は現在ある要素を新たな要素
で置換するのに用いられ１画素のリスト。

および置換される成る範囲の要素を与える情報を含むこ
とがあるかもしれない。

ＥＲＡＳＥ（消去）はピクチャから要素を除去するのに
用いられ、消去される要素の範囲に関する情報を含むこ
とがあるかもしれない。

ＱＵＩＴ（中止）は総ての要素を消去し終結するのに用
いられ９％定のパラメータを有しない（ピクチャが専用
である場合にのみ有効である）。

ＭＡＲＫ（マーク）は１マークされた′属性をセットす
るのに用いられ（テキストの場合にはマーク記号を表示
するのに、用いられ）、マークされる要素、その後にマ
ーク記号を表示する文字のオフセットを指定する情報を
含むことがあるかもしれない。

５ＥＬＥＣＴ　（選択）は要素を選択し、それをマーク
するのに用いられ、それは選択される要素。

その後にマーク記号を表示する文字のオフセット。

選択する文字の数、およびデセレクトオプションを指定
する情報を含むことがあるかもしれない。

５ＡＶＥ（保管）はピクチャの全部または一部をファイ
ルにコピーするのに用いられ、それはファイルの名、お
よびピクチャのサブセラトラ指定する情報を含むことが
あるかもしれない。

ＱＵＥＲＹ（間合せ）は現在の状態を得るのに用いられ
、それは特定のパラメータを有しない。

ＢＫＧＤはピクチャのバックグラウンドカラーな変える
のに用いられ、それはカラーを指定する情報を含むこと
があるかもしれない。

ＡＰＰＬはピクチャを１アプリケーシヨン′としてレジ
スタするのに用いられ、それはアプリケージＥｉンの名
、アフリケーションプロセスへの接続、およびピクチャ
内の原点を指定する情報を含むことがあるかもしれない
。

ＮＵＭＢＥＲは特定の要素の序数および一意名を得るの
に用いられ、それは要素を指定する情報を含むことがあ
るかもしれない。

ＨＩＴは一定の位置における。または一定の位置に最も
近い要素を見付けるのに用いられ、それはピクチャ内の
位置、および要素がその位置からどの位置れていること
ができるかを含むことがあるかもしれない。

〔、〕はババラを開始／終了するのに用いられ。

第１記号は第２記号が受取られるまで総ての更新を延期
させる（バッチは最大１０の深さまでネストしてもよい
）。

ＨＩＧＨＬＩＧＨＴ、ＩＮＶＥＲＴ、ＢＬＩＮＫ、ＨＩ
ＤＥは特定の要素属性を変えるのに用いられ、属性がセ
ットされているか、またはクリアされているかを示す情
報、および変更される成る範囲の要素を示す情報を含む
ことがあるかもしれない。

ＣＨＡＮＧＥ（変更）は１つまたは複数の要素フィール
ドを変更するのに用いられ、それは要素のカラー、バッ
クグラウンドカラー、フィルカラー、フィルパターン、
および変更される成る範囲の要素を指定する情報を含む
ことがあるかもしれない。

ＥＤＩＴ（編集）はテキスト要素の列を変更するのに用
いられ、それは現在のマークにおいて編集し次にそのマ
ークを移動させることを示す情報。

現在選択されているサブストリングが編集されることを
指定する情報、そこへ挿入しおよび／またはそこからシ
フティングを開始するテキスト内へのオフセットを示す
情報１文字の一定数だけ一定の位置へ／一定の位置から
テキストヲクフトスることを示す情報、タブスペーンン
グを示す情報。

置換サブストリングを示す情報、要素の終わりにブラン
クすることを示す情報、および編集される成る範囲の要
素を示す情報を含むことがあるがもじれない。

下記は種々のピクチャドローイング応答およびその各応
答に関連があるかもしれない情報の型である。

５ＴＡＴＵＳ　（状態）はピクチャの現在の状態を述べ
、それはピクチャへのコネクタ・、もし適用可能であれ
ば、もとのメツセージ−意名、ピクチャの名、最後に読
取られた。または書込まれたファイルの名、高さおよび
幅、ピクチャ内の最低および最高の行／列、要素の数、
および現在アクティブなビューボート数を指定する情報
を含むことがあるかもしれない。

ＷＲＩＴＥ（書込）はピクチャからコピーされた要素を
含み、それはピクチャへのコネクタ、ピクチャ要素のリ
スト、およびデータ型を指定する情報を含むことがある
かもしれない。

ＮＵＭＢＥＲＣ数）は要素数および一意名を含み、それ
は数のリスト、および要素−意名のリストを指定する情
報を含むことがあるかもしれない。

画　　　素 画素は共通ヘッダ用の１つのデータ構造を含む複数のデ
ータ構造、いくつかのオプション構造。

および可能性のある各要素型用の１つの構造の集まりに
よって定義される。要素の位置はピクチャの（０，０）
に対応する１組の絶対座標として常に与えられる。これ
は各要素を取りかこむ′ボックス′の左上角を定める。

（例えば線上の点を定める）要素内において指定されて
いる点はこの位置に対応する座標として常に与えられる
。′マクロ′においては１個々の各要素の開始位置はそ
のマクロ要素自体の絶対開始位置に対応するものと考え
られる１、即ちそれらはネストされている。

第７図は完全な画素の一般構造を示す。′値′部分は要
素型に依存する。ｌ　ａｐｐｌｌおよび’ｔａ／フィー
ルドはオプションであり、’ａｔｔｒ’のインジケータ
ズセットに依存する。

下記は画素の種々のフィールドの説明である。

Ｌｅｎｇｔｈ　＝バイトで表した全画素の長さ。

Ｔｙｐｅ　　＝下記のうちの１つ。テキスト、線。

矩形、楕円９円、記号、配列、離 散、空白、メタエレメント。

Ａｔｔｒ　　　＝下記のうちの１つ。選択可能９選択さ
れている。直線からなる２反 転した７オアグラウンド／バツク グラウンド、プリンク、タグされ ている。アプリケーションニモニ ツク、隠されている１編集可能。

移動可能、コピー可能、消去可能。

変換されている。ハイライトされ ている。マツプされている／マツ プされていない、マークされてい る。コピー。

Ｐｏｓ　　　　＝要素ボックスの左上角の行／列座標。

Ｂｏｘ　　　　＝＝＝要素完全に正確に取りかこむ想儂
上のボックスの高さ７幅。

Ｃｏ１ｏｒ　　ｘ５つのサブフィールド、即ち色相。

彩度および色価からなる要素のカ ラー。

Ｂｋｇｒｄ　　＝要素のバックグラウンドカラー。

Ｆｉｌｌ　　　＝閉じられた図の内部のカラー。

Ｐａｔｔｅｒｎ　　＝１０の“フィル′パターンのうち
の１つ。

Ａｐｐｌ　　　＝特定のアプリケーション（例えば形式
マネージャ、ワードプロセラ サ、レポートジェネレータなど） を参照するニモニック、多数のプ ロ七スが単一のピクチャを共用で きるようにする。

Ｔａｇ　　　　＝＝ユーザによって供給される可変長を
白終結列、これは特定の要素ま たは要素のクラスを識別するため に、または追加の属性を記憶する ためにアプリケーションによって 使用されることができる。

′テキスト′と指定された場合には′型′フィールドに
関連した属性は下記の通りである。

０ｐｔｉｏｎｓ＋＝ワードラツプ、ボールド、下線。

イタリック、ボーダー、左行揃え。

右行揃え、中間位置、ボックスの 頂部、ボックスの底部、ボックス の中央部、インデント、タブ、ボ ックスサイズの調節１文字サイズ。

文字／線スベークング、および活 字面。

ｊ３ｅｌｅｃｔ　＝列の始めからオフセットによって現
在選択されているサブストリン グ、および長さを示す。

Ｓｔｒｉｎｇ±ＡＳＣＩＩを含む任意の数のバイトとそ
の後に続く単一空白バイト。

テキストは要素のボックス内に当 てはまるように制約されており。

それがその面積の右境界に達する と新たな行に押し入る。

Ｉｎｄｅｎｔ　＝要素の１ボツクス′内のテキストの第
１行及びその後の複数の行の 字下げを指定する２つの数字。

Ｔａｂｓ　　＝＝（タイプ、位置〕のリスト、但し。

１位置′は要素のボックスの左縁 がらの文字数であり、１タイプ′ はＬｅｆｔ、ＲｉｇｈｔまたはＤｅｃｉｍａｌである。

Ｇｒｏｗ　　＝それによって要素のボックスがタイプさ
れた入力により拡張される ことがある文字（水平）および線 （垂直）の最大数、右方および下 方への拡張を制限する。

５ｉｚｅ　　＝文字のエクステントの高さおよび対応す
る幅。

５ｐａｃｅ＝テキストの線間および文字間のスペークン
グ。

Ｆａｃｅ　　＝特定の活字面の名。

１線′が指定された場合には′を′フィールドに関する
属性は下記の通りである。

５ｔｙｌｅ＝実線、破線２点線、二重線、破線一点線、
ダッシュ−ドツト−ドラ ト、パターン化などの種々のオプ ション。

ｐａｔｔｅｒｎ＝パターンナンバー Ｔｈ１ｃｋ＝画素の線の幅。

Ｐｏ１ｎｔｓ＝＝ヘツダに定義されているボックスの左
上角に対応する２つまたはそ れより多い対の座標（即ち点）。

“矩形′と指定された場合には′型′フィールドに関連
する属性は下記の通りである。

５ｔｙｌｅ＝上記の′線′の場合に同じ、それに加えて
シャドー付き中実（ｓｏｌｉｄ）Ｐａｔｔｅｒｎ　＝　
’線’　Ｏ場合ト同し／。

Ｔｈ１ｃｋ＝１線′の場合と同じ。

Ｒｏｕｎｄ＝矩形の６角に描かれる四分円弧の半径。

′楕円′と指定された場合には１タイプ′フイールドの
属性は下記の通りである。

５ｔｙｌｅ＝中実（ｓｏｌｉｄ）、パターン化または二
重。

Ｐａｔｔｅｒｎ　＝　’線′の場合と同じ。

Ｔｈ１ｃｋ＝’線′の場合と同じ。

Ａｒｃ　　　＝ｘ楕円弧のオプションとしてのスタート
アングルおよびエンドアング ル。

“円′と指定された場合には′型′フィールドに関連す
る属性は下記の通りである。

３ｔｙ１６＝’楕円′ｐ場合と同じ。

Ｐａｔｔｅｒｎ＝１線′の場合と同じ。

Ｔｈ１ｃｋ＝’線′の場合と同じ。

Ｃｅｎｔｅｒ　＝要素のボックスの左上角に対応する９
円の中心を指定する点。

Ｒａｄｉｕｓ＝円の半径の長さ。

Ａｒｃ　　　＝円弧のオプションとしてのスタートアン
グルおよびエンドアングル。

′記号′は見える（描かれている）、または見えない（
描かれていない）画素を含む矩形空間である。それはそ
の起点が左上角にある二次元配列または１と００“ビッ
トマツプ′によって表される。

“記号′が指定された場合には１を′フィールドに関連
する属性は下記の通りである。

Ｂｉｔｍａｐ　＝　’１’　（画素をフォアグラウンド
カラーで描く）または１０′（画 素をバックグラウンドカラーで描 く）である単一ビットを含む（行 と列のオーダーの）二次元配列で あり、その配列の起点は要素の開 始位置に対応する。

Ａｌｔ　　　＝記号の代わりに非ビットマツプデバイス
に表示できるテキストスト リングである。

配列要素は記号要素に似た。特定のカラーで描かれてい
る画素を含む矩形空間である。それはその起点が左上角
にあるカラーナンバーの二次元配列または１ビツトマツ
プ′として表される。その要素の１フイル′および１パ
ターン′は無視される。

′配列′が指定された場合には′型′フィールドに関連
する属性は下記の通りである。

Ｂｉｔｍａｐ　＝カラーナンバーの（行と列のオーダー
の）二次元配列であり、各ナ ンバーは描かれる画素のカラーを 定めるか、または零である（この 場合には画素はバックグラウンド カラーで描かれる）。配列の起点 は要素の開始位置に対応する。

Ａｌｔ　　　＝配列の代わりに非ビットマツプデバイス
に表示できる代わりのテキ ストストリング。

個別要素は、別個の点に結合する線をオブクヨンとして
用いてスクリーン上に別個の点をプロットするのに用い
られる。各点は要素の１ボツクス′に対応するその座標
によって指定される。明示要素（通常は単一文字テキス
ト要素または記号要素）を各点において描かれるマーク
として与えてもよい。さもなげれば星印を用いる。その
結果できる図はフィルできない。

１個別′が指定された場合には“型′フィールドに関連
している属性は下記の通りである。

Ｍａｒｋ＝＋各点に描かれる′マーク′を定義する画素
。もし適用不可能であれ ば９長要素（即ち値零を含む単一整数）がこのフィール
ドのために与えられなければならない。

Ｓｔｙｌｅｗ線の型、パターンおよび厚さく上記の′線
′要素参照）。

ａｔ ｈｉｃｋ Ｊｏｉｎ　　＝”ｌ”または′Ｎ′（または空。

これは１Ｎ′に相当する）。もし “Ｙ′であれば線はマークを接続 するために描かれる。

Ｐｏ１ｎｔｓ　＝２つまたはそれ以上の座標。各点はヘ
ッダに定められた１ボツクス′ の左上角に対応する。

ｌマクロ′要素は先行するプリミティブ要素タイプ（′
テキスト′など）および／またはその他のマクロ要素か
らなる複合要素である。それは時愕は他のマクロ要素を
１大括弧で囲む′ものと考えることができる。含まれて
いる要素の座標はマクロ要素の絶対要素に対応する。々
クロ要素の１長さ′フィールドはそれ自身のヘッダと１
マクロ′フィールドＩ、　＞よび含まれている要素全部
の長さの合計を含む。′テキスト′マクロはテキストの
単一ユニット（ワードなど）における相異なる字体およ
びスタイルを混ぜるのに有用である。

ｌマクロ′が指定されている場合には１型′フイールド
に関連している属性は下記の通りである。

Ｍａ　ｃ　ｒ　ｏ＝マクロ要素の内容を述べる。下記の
うちの１つであってもよい。

′Ｎ′−正常（含まれている要素は 完全である） “Ｙ′−リスト。′Ｎ′と同じであ るが、一時に１つだけのサ ビエレメントを表示できる。

その他は’ｈｉｄｄｅｎ　（隠さ れている）′とマークされ。

表示された要素だけが要求 （１コピー′など）に応答 して送られ、″ハイライト′ 要求はサブニレメントラ介 して順序正しく循環する。

′Ｔ′−テキスト。１Ｎ′と同じで あるが、′マクロ′フィー ルドのすぐ後にはテキスト ′オプションズ′フィール ドおよびテキスト“選択′ フィールドが続く、マクロ Ｉリスト′フィールドの後 には（オブクヨンズフィー ルドにおいて指定されてい る）追加のテキストパラメ ータが続いてもよい。

Ｌｉ５ｔ　　＝（サブエレメントとして参照される）任
意の数の画素であって、上 述したように書式化され、無効語 によって終結されている。

′メタエレメント′はピクチャマネージャが発生させた
疑似要素であり、これはピクチャがファイルに１保管′
されるとピクチャ自体を記述する。

この結果、ファイルから読取られたメタエレメントはピ
クチャのサイズやバックグラウンドカラーのようなピク
チャに関連したパラメータを設定するのく用いられる。

メタエレメントは（例えば″読取′要求に応答して、ま
たはウィンドーマネージャに対する更新として）ピクチ
ャマネージャが出した書込みメツセージには決して現れ
ない。

メタエレメントの書式は長さフィールド、型フィールド
、メタフィールド、および値を含む。１６ビツト長さフ
ィールドは常に３６の長さを指定する。盤フィールドは
正常ピクチャ要素用のそれに似ている。メタエレメント
フィールドは下記の型のうちの１つを含む。

Ｎａｍｅ　　＝ピクチャを命名する列からなる値。

５ｉｚｅ　　＝最大桁及び列、および最大要素数および
サイズ。

Ｂａｃｋｇｒｄ　＝ピクチャのバックグラウンドカラＯ Ｈｉｇｈｌｔ＝ピクチャのハイライティング。

値フィールドの書式はメタタイプに依存する。

ウィンドーインク ウィンドーは一定のピクチャの特定のサブセット（これ
はしばしば１ビユー′と呼ばれる）を特定のスクリーン
上に！ラグする。スクリーン上の各ウィンドーは、その
中にピクチャが表示され最高４つの′フレームバー′の
ある１ペイン（ｐａｎｅ）’を扱う単一資源である。

′！５８図を参照すると、フレームバーはタイトルのよ
うな補助的情報を示すのに用いられる。フレームバーは
′プルダウン′メニューの名を表示する対話をとするこ
とができ、このメニューは選択されると、ウィンドーに
関するオプションまたは動作のリストを表示する。パレ
ットバーは永久的に開いているメニューのようなもので
あり、総ての選択が常に見えている。

スクロールバーはピクチャ内のウィンドーのビューの相
対的位置を示し１選択可能な′スクロールパー１によっ
てスクローリングを可能にする。

１リサイズ（ｒｅｓｉｚｅ）’ボックスを選択してスク
リーン上のウィンドーのサイズを拡大また縮小すること
ができるが、一方′クローズ′ボックスを選択してウィ
ンドーを除くことができる。′ブローアツプ′ボックス
を選択するとウィンドーはスクリーンサイズ全体に拡大
され、再びそれを選択するとウィンドーはもとの寸法に
縮小される。

コーナーボックスはもし所望するならハ追加ノユーザ情
報を表示するのに利用できる。

第８図に示しであるウィンドーは単一ペイン。

４つのフレームバー、およびコーナーボックスからなる
。各スクロールバー内の矩形要素はそれが！ツプサレル
ピクチャ内のウィンドーの相対的位置（即ち約１／３程
下がったやや右よりの位置）を示す。

ウィンドーの任意の部分で（’選択′のような）動作を
行うと、オプクヨンとして′クリック′メツセージがウ
ィンドー〇オーナヘ送られる。例えば、ペイン内の要素
を選択すると、＃動作′＝１選択′および“領域′＝１
内側′の１クリツク′が（ピクチャの左上角に対応する
）座標およびその位置における要素のコピーとともに送
られる。

任意の７レームバーに現れることがあるメニューの名を
選択すると、そのメニューがポツプアップする。。それ
は′クリック′メツセージにおいて送られるメニューに
対する応答であって、メニューバーアイテムの選択に対
する応答ではない。

（キーボード上のメニューキーによって起動される）ポ
ツプアップメニューはまた特定のウィンドーと関連づけ
ることができる。

総てのウィンドーは“作成′要求をコンソールマネージ
ャへ送ることによって作られる。上述したように、ｙ作
成′はウィントーイングメツセージのうちで最も複雑な
ものであり、ウィンドーのサイズおよび位置、どのフレ
ームバーが表示するか、ウィンドー内で一定の動作が行
われた場合に何なすべきかなどを指定する多数のオプシ
ョンを含む。

要求を送ったプロセスはウィンドーの′オーナ′として
知られているが、これは動的に変更することができる。

最も最近に開かれたウィンドーが通常は現在の１アクｆ
イブ′ウィンドーとなるが。

これは無効にしても、または変更してもよい。

その後の′マツプ′要求は、（′作成′要求において指
定されていない場合には）どのピクチャを表示すべきか
をウィンドーに告げるために必要である。′！ツブ′は
何回でも再発行できる。

その他の要求はポツプアップメニューおよびソフトキー
を定義し、または特定のフレームバーの内容を変更する
。ライ２ドーはそれが重なる他のウィンドーの上に常に
開かれている。関連ピクチャのために指定されたバック
グラウンドに応じて。

下にあるウィンドーは見えることも、見えないこともあ
る。

′削除′要求はウィンドーをアンマツプし、ウィンドー
マネージャを外に出す。（′削除′のセンダと異なる場
合には）ウィンドー〇オーナにはその結果として′状態
′メツセージが送られる。

下記は種々のウィンドーインク要求およびその各要求に
関連があるかもしれない情報のタイプである。

ＭＡＰはウィンドーにピクチャをマツプまたは再マツプ
するのに用いられ、それは所望するピクチャへの接続、
およびウィンドーの座標系における（０，０）になる′
ビューボート′の左上角のピクチャの座標を指定する情
報を含むことがあるかもしれない。

ＵＮＭＡＰはウィンドーをそのピクチャから切りはなす
のに用いられ、それはパラメータを含まない。

ＱＵＥＲＹはウィンドーの状態を得るのく用いられ、そ
れはパラメータを含まない。

〔、〕は“バッチ′を５ｔａｒｔ／ｅｄさせるのに用い
られ、第１記号が存在−すると第２記号が受取られるま
で総ての更新が延期される（バッチは最高１０の深さま
でネストされてもよい）。

ＭＥＮＵはメニューキーが押されると“ポツプアップ′
するメニューを定義し、どのメニューキーがメニューを
起動させるかｌ指定丁や情報、ヒユーマンインタフェー
スライブラリにお・けるメニューの名を指定する情報（
省略された場合は１リスト′が与えられなげればならな
い）、および′クリック′メツセージにおいて戻される
名を指定する情報を含むことがあるかもしれない。

ＫＥＹＳはウィンドーのだめの９疑似機能′キーを定１
１．　それはヒユーマンインタフェースライブラリにお
けるメニューの名、中−名のリスト。

および“クリック′メツセージにおいて戻される名を指
定する情報を含むことがあるかもしれない。

ＡＤＤ、Ｃ０ＰＹ、ＥＲＡＳＥ、ＲＥＰＬＡＣＥはフレ
ームバーにおける要素を制御し、それらはバーの型（例
えばタイトル、パレット、汎用など）、。

’ａｄｄ’および“ｒｅｐｌａｃｅ’のための画素のり
スト（’ｃｏｐｙ’および’ｅｒａｓｅ’　Ｋついては
省略される）、および（’ａｄｄ’には適用できない）
特定の要＊Ｖ識別するタグを指定する情報を含むことが
あるかもしれない。

ＨＩＧＨＬＩＧＨＴ、ＩＮＶＥＲＴ、ＨＩＤＥ、ＢＬＩ
ＮＫはフレームバー要素の属性を変更し、これらはセッ
ト／クリア属性、バーの型、およびバーの特定の要素を
指定するタグを指定する情報を含むことがあるかもしれ
ない。

下記の雅々のウィンドーインク応答およびその各応答に
関連があるかもしれない情報の型である。

５ＴＡＴＵＳはウィンドーの現在の状態ｌ述べ。

それはウィンドーへのコネクタ、オリジネータ（即ち“
ウィンドー′）、もし適用可能であればもとのメツセー
ジ−意名、サブシステム、ウィンドーの名、ウィンドー
のコンソールマネージャへのコネクタ、スクリーン上の
ウィンドーの位置。

ペインサイズおよび位置、ウィンドーに現在マツプされ
ているピクチャへのコネクタ、およびビューのサイズお
よび位置を指定する情報を含むことがあるがもじれない
。

ＢＡＲは′コど−′要求に対する要求を表し。

それはバーの型（例えばタイトル、パレット、汎用、コ
ーナーボックスなど）、および画素のリスト！指定する
情報を含むことがあるかもしれない。

ＣＬＩＣＫはウィンドー上の、またはウィンドー内のユ
ーザ開始事象を述べ、それはどんな事象か（例えばペイ
ン内、フレームバー、コーナーボックス、ポツプアップ
メニュー、機能キーなど）を指定する情報、ウィンドー
マネージャへのコネクタ、ウィンドーのコンソールマネ
ージャへのコネクタ、ウィンドーの名、メニューまたは
機能キーの名、１ｍ連ピクチャマネージャへのコネクタ
。

メニューまたはパレットバーアイテムからの、または機
能キーからのラベル、動作が起きたカーソルの位置、ユ
ーザによって行われた動作、特定の位置における要素の
コピー、第１要素の数、第１要素の一意名、タイプされ
た文字または境界インジケータまたは完了文字のコピー
、および他の総てのウィンドーからの他の現在選択され
ている要素がもしあればその要素乞指定する情報を含む
ことがあるかもしれない。

ＨＩ　　−詳細な説明 ユーザ調整可能ウィンドー 第９図はピクチャ、ウィンドー、（目的を作成し破壊す
る）コンソールマネージャ、および（物理装置への出力
を行う）仮想出力マネージャの間の関係を示す。１つま
たは複数のアプリケーションプログラム２２５に応答し
て、コンソールマネージャ２２０は１つまたは複数のピ
クチャ２２１−２２３を作成してもよい。コンソールは
また各ピクチャの一部を見るための少なくとも１つのウ
ィンドーを作成してもよい。仮想出力マネージャ２３５
は各ウィンドーに対応する仮想出力を、ビデオ表示端末
のような１実′出力装置上に表示するのに適した形に変
換する。

１つまたは複数のウィンドー２３１−２３３を出力デバ
イス上の同時に表示することができる。ウィンドー２３
１−２５３は別個のピクチャの部分を表示するために示
されているが、それらのウィンドーはまた単一ピクチャ
の相異なる部分を表示することもできる。

第１０図はアプリケーションプログラムがどのようにし
てコンソールマネージャプロセスと対話してウィンドー
およびビクチャタ作成および／または破壊するかを示す
フローチャートを示す。アプリケーション要求２４０に
応答して、コンソールマネージャ２４１は適当なプログ
ラムモジュール２４２へ進んでピクチャ２４４またはウ
ィンドー２４３を作成することができ、またはモジュー
ル２４５へ進んでウィンドー２４６またはピクチャ２４
７ヲ破壊することができる。

コンソールマネージャが新たなウィンドー２４３を作成
するように要求されると、それは先ず新たなウィンドー
プロセスを開始する。次にそれはフレームなどを描くこ
とによってウィンドーを初期設定する。次にそれは一定
のピクチャの初期ビューを定義する。

コンソールマネージャが新たなピクチャ２４４を作成す
るように要求されると、それは新たなピクチャプロセス
を開始する。

コンソールマネージャがウィンドー２４６を削除するよ
うに要求されると、それはウィンドーを閉じる。

コンソールマネージャがピクチャ２４７を削除するよう
に要求されると、それはピクチャに中止するように告げ
る。

第１１図は本発明の好ましい実施例によりピクチャを更
新し１選択されたサイズのウィンドーにおいて結果を見
るオペレーションを示す。第１４図において行われるオ
ペレーションは第１２図のラインセグメント２０１によ
って示されているオペレーションに対応する。

アプリケーション２４９からの要求に応答して。

ピクチャマネージャ２５０は示された更新動作のうちの
どれを行ってもよい。例えば、ピクチャマネージャは記
述子を割当てそれによりビューの位置およびサイズをフ
ィルすることによってピクチャのビューを変更してもよ
い。

或は、ピクチャマネージャ２５０は要求に応じて適当に
画素を描き、置換し、消去するなどしてもよい。ピクチ
ャマネージャは各ビューごとに要求されたオペレーショ
ンを繰り返ス。

ピクチャ　−　多重アプリケーション からのライプデータ 第１２図は単一ピクチャがどのようにして多重ア７’　
ＩＪケーションソフトウエアプログラムを共用できるか
な示す。ピクチャ２６５はスブレッドンー）　２６０　
、グラフィックパッケージ２６２．ワードプロセッシン
グ２６４．データベース管理２６８．およびプロセス制
御２６６、アポイントメントカレンダ（図示されていな
い）などの任意の数の独立アプリケーションを含むこと
ができる。各アプリケージョンは画素をスプレッドシー
ト、グラフ、電機式文書のページなどとして解釈するこ
とによってその制御下にある画素の特定の編成に意味を
与える。

第１３図はピクチャマネージャがどのようにしていくつ
かのアブリケークヨンを単一ピクチャに多重化するかを
示している。ピクチャマネージャ２７６は各アブリケー
クヨン２７１−２７５７に属すル画素を追跡する。ピク
チャにアクセスする。またはピクチャを修正するために
ピクチャマネージャが受取るいかなる要求も構成要素で
あるアブリケークヨンのリストに照らしてチェックされ
る。現在の要求を行っているアプリケーションに属さな
い画素は読飛ばされるだけである。

ピクチャマネージャ２７６はアプリケーション２７１−
２７５の適当な画素についてドロー、コピー。

置換、消去および／またはその他のオペレーションを行
うことができる。

ヒユーマンインタフェースは多重アプリケーションが単
一ピクチャを共用できるようにするので。

（例えば）スズレツドクート、グラフおよびテキストを
特定のユーザに適するように結合することができる。例
えば、第１４図は単一スクリーン上での２つのアプリケ
ーションのライブ統合を示す。

スクリーン上に示されている部分２９１はテキスト編集
またはワード処理アプリケーションからのテキストを表
す。部分２９１はユーザにより完全に編集可能である。

部分２９２はスプレッドシートアプリケーションの一部
を表し、それはまたユーザにより完全に修正可能である
。スプレッドシートのいずれかのセルの内容の修正は、
＄１４図に示されたスクリーン上に表示されている部分
２９２に対する適当な変更を反映する。

第１４図に示したワード処理およびスプレッドシートア
プリケーションを含むピクチャに関しては、いずれのア
プリケーションも他方の存在を類ラス、またいずれのア
プリケー７ョンもそのピクチャが共用されているという
事実を知らす、またはその事実によって影響されない。

各アプリケーションはあたかもそれがピクチャの唯一の
ユーザであるかのように動作する。（ＶＤＴスクリーン
のような出力デバイスに対する）最終効果は、関連アプ
リケーションのうちのいずれか、または全部によって互
いに完全に独立して動的に更新された単一の結合した視
覚イメージである。

入力／出力デバイス独立性 本発明においては、外部の世界との総てのシステム対話
は、′仮想人力′デバイスまたは′仮想出力′デバイス
を介して行われる。このクステムはいかなる形の入力ま
たは出力デバイスも受入れることができる。ヒユーマン
インタフェースははっきりと定義された１組の′仮想デ
バイス′を用いて構成されている。総てのヒユーマンイ
ンタフェース機能（ウィンドーインク、ピクチャドロー
イング、対話管理など）はこの１組のデバイスを独占的
に使用する。

これらの仮想入力デバイスは“キー′　（タイプされた
テキスト人力）、′位置′（スクリーン座標）、′動作
′（１ウィンドーを開くなどのヒユーマンインタフェー
ス機能）、１機能′（ユーザ定義動作）、および１手段
′　（選択のプツプアツブリスト）の形をとる。

仮想出力デバイスはデバイス独立出力、テキスト、線、
矩形、多角形１円、楕円、離散点、ビットマツプされた
記号、およびビットマツプされた配列を生じさせる。

第１５図はどのようにしてコンソールマネージャが仮想
入力に働いて仮想出力を発生させるかを示す、ＨＩソフ
トウェアの最下層は任意の′笑′物理デバイスからの入
力を一般的な仮想形に変換し、ｌ（仮想形の）ヒユーマ
ンインタフェース出力を物理出力に変換する。

第１５図は仮想入力を扱い仮想出力を発生させるヒユー
マンインタフェースの中心フロセス、コンソールマネー
ジャ３００を示す。仮想入力マネージャ３０１を通過し
た仮想入力は直接にコンソールマネージャ３００によっ
て処理されるが、出力は２つの中間プロセス、即ち（１
）デバイス狸立性グラフイメージを操作するピクチャマ
ネージャ６０２．および（２）全体的ピクチャの（′ビ
ュー′と呼ばれる）サブセットを仮想出力マネージャ３
０６へ提示するウィンドーマネージャ３０４を通過する
。

任意の数の物理デバイスを、ヒユーマンインタフェース
の現在の状態またはヒユーマンインタフェースを用いる
任意のアプリケー７ョンの現在の状態を妨害せずに、ヒ
ユーマンインタフェースに接続でき、または動的に除去
または置換できる。

換言すると、ヒユーマンインタフェースは特定のＩ１０
デバイスから独立しており、デバイスに特有な性質はヒ
ユーマンインタフェースからは隠されている。

第１６図は仮想入力がどのようにしてコンソールマネー
ジャによって扱われるかを示すフローチャートを示す。

仮想入力はキーストローク、カーソル位置、動作９機能
キー、メニューなどのいくつかの形のうちのどの形ｔと
ってもよい。

例えば、ブロック３１１の下のオペレーションに関シテ
いうと、コンソールマネージャへの仮想入力がキースト
ロークである場合には、コンソールマネージャはカーソ
ルがウィンドー内にあるかどうかをチェックする。もし
カーソルがウィンドー内にあると、コンソールマネージ
ャはそれが仮想端末に起始したかどうかをチェックし、
もしそうでなければコンソールマネージャは編集オペレ
ーションが起きているかどうかをチェックする。もしそ
うでなければ、コンソールマネージャはピクチャを更新
する。

ブロック６１２の下のオペレーションに関していうと、
仮想人力がカーソル位置を表していると。

コンソールマネージャはオートハイライトオブンヨンが
使用可能になっているかどうかをチェックする。もし使
用可能になっていれば、コンソールマネージャはカーソ
ルが要素上にあるかどうかをチェックする。もしそうで
あればコンソールマネージャはその要素をハイライトす
る。

ブロック３１３の下のオペレーションに関していうと、
コンソールマネージャは示された動作のうちのいずれか
の動作を用いて適宜ピクチャを更新し、ウィンドーを更
新し、または対話を開始する。

ブロック３１４の下のオペレーションについていうと、
仮想人力が機能キーからのものであると。

コンソールマネージャは対話マネージャに通知する。

ブロック３１５の下のオペレーションについていうと、
仮想入力がメニュー選択を表す場合には。

コンソールマネージャはカーソルがウィンドー内にある
かどうかをチェックする。もしカーソルがウィンドー内
にないと、コンソールマネージャはカーソルはユーザメ
タフオ上にあると判断し、カーソルがウィンドー内にあ
ると、コンソールマネージャはウィンドーからのメニュ
ーを要求する。

メニューが定義されると、コンソールマネージャはウィ
ンドー（またはメタフオ）のオーナに通知し、ポツプア
ップメニューを起動させ、応答を得てその応答をウィン
ドーオーナヘ送る。

第１７図は仮想入力がどのようにしてピクチャマネージ
ャによって扱われるかを示すフローチャートを示す。ピ
クチャマネージャ３２０はコンソー３２０は古い出力を
新たな出力と置換し、その変更をウィンドーマネージャ
へ送る。ウィンドーマネージャはその変更を出力マネー
ジャへ送り、こんどは出力マネージャがその変更を実デ
バイスへ送る。

スクリーン　−　多重ウィンドーにおけるライブデータ 第１８図はコンソールマネージャ３４０がどのようにし
てアプリケークコンソフトウエアプログラム３３０−３
３４　Ｙ多重ピクチャ３４１−３４３　ＩＣよって表す
ことができるようにするか、多重ウィンドー３６１−３
６３および３６７がどのようにして１つのピクチャの相
異なるビューを与えるかｔ示す。

コンソールマネージャ３４０は要求に応答してピクチャ
３４１−３４３のうちのどれかまたは諾てについてプロ
セス制御モジュール３３０．スブレッドクートそジュー
ル３５１．グラフィックパッケージ３３２、ワード処理
ソフトウェア３３３．またはデータペース管理３３４の
ようなアプリケーションプロセスを作成することができ
、または開くことができる。ウィンドー３６１はピクチ
ャ３４１の一部を見ることができ、ウィンドー３６２は
ピクチャ３４２の一部を見ることができ、ウィンドー６
６６および３６７はピクチャ３４３の相異なる部分を見
ることができる。ウィンドーマネージャ３Ｓ１−３６３
および３６７の仮想出力は仮想出力マネージャ３６５に
よって処理され、この仮想出力マネージャ３６５はまた
それをビデオ表示端末３６６のような実出力デバイスに
よって表示されるのに適した形に変換する。

第１９図はいくつかのウィンドーがどのようにして典型
的なスクリーン上に同時に表示されるかを示す。ヒユー
マンインタフェースは多重アプリケーションの部分を別
個のウィンドーにより表示することを可能にする。例え
ば、第１９図はワード処理アプリケーションからのライ
ブテキスト部分３７１．スブレッドクートからのライブ
数値部３７０、およびグ５・ソイツクプログラムからの
ライブグラフィック部分３７２の同時表示を示す。各ウ
ィンドー３７０−３７２内の情報は“ライブ１で有り。

即ちその情報は進行中の処理によって変わることがある
。

ユーザは何時でもウィンドー３７０−３７２内の情報を
追加または修正してもよく９表示された情報のいかなる
変更もそれが処理されるＫつれて適当なウィンドー内で
行われる。例えば、１つのウィンドー内に表示された１
つのアプリケーションに対する変更はいくつかのウィン
ドーに表示された情報の変更を生じさせる。

資源コード表の説明 ユーザ調整可能ウィンドー プログラム要人およびＢは上述した表示ウィンドーのサ
イズ調整に関する概念の１Ｃ′言語実施例を含む。下記
の表はそれらの表の関連部分がどこにあるかを示す。

機能　　　　　　　　　　　　　　　プログラム要人の
行番号主要行、初期設定、要求を　　　１９０−２２２
受取る。

要求の型を決定する。　　　　　　３２９−３６９作成
。　　　　　　　　　　　　　４１８−４５４ウィンド
ーを作成する。　　　　１２９８−１６００ピクチヤを
作成する。　　　　　４４０−４４７破壊（削除）する
。　　　　　　４５６−４８４機能　　　　　　　　　
　　　　　　プログラム表Ｂの行番号主要行、初期設定
、処理を　　　１２５−１４１開始する。

要求を受取る。変更をチェ　　　１６１−２０３ツクす
る。

要求の型を決定する。　　　　　　２３９−３１０見る
。　　　　　　　　　　　　　１２０５−１２４９描く
。　　　　　　　　　　　　　　　　４１０−４５７置
換する。　　　　　　　　　　　５３７−５８５消去す
る。　　　　　　　　　　　５８７−６０９ピクチヤ　
−　多重アプリケーションからのライブデータ プログラム表Ｂは上述して単一ピクチャに同時に常駐す
るアプリケーションの要素を修正する要求の受領に関す
る概念の１Ｃ′言語実施例を含む。

下記の表はプログラム表Ｂの関連部分が発見される場所
を示す。

機能　　　　　　　　　　　　　　　プログラム表Ｂの
行番号主要行、初期設定、処理を　　　１２４−１４１
開始する。

要求を受取る。変更をチェ　　　１６１−２１３ツクす
る。

要求の型を決定する。　　　　　２５９−５１０アプリ
ケーシヨンを登録する。　　８４３−８６４描く、コピ
ーするなど。　　　　　３１２−８４１アプリケーシヨ
ンが登録され　　　１７９，１８０゜たかどうかをチェ
ックする。　　　２０５−２１７要素がアプリケーショ
ンに属　　１６５３−１６５９するかどうかをチェック
する。

人力／出力デバイス独立性 プログラム要人およびＢは入力／出力デバイス独立性に
関する上述した概念のＩＰ　ＣＩ言語実施例を含む。下
記の表は表ＡおよびＢの関連部分が発見される場所を示
す。

機能　　　　　　　　　　　　　　　プログラム表Ａの
行番号主要行、初期設定、入力を　　　１９０−２２２
受取る。

入力の型を決定する。　　　　　４８６−５２１仮想キ
ー　　　　　　　　　　　５２３−６３１仮想位置　　
　　　　　　　　　６３３−６６１仮想動作　　　　　
　　　６６３−７０２．７６３−１２００仮想機能　　
　　　　　　　　　７０４−７２５仮想メニユー　　　
　　　　　　７２５−７６１機能　　　　　　　　　　
　　　　プログラム表Ｂの行番号主要性、初期設定、処
理を　　　１２５−１４１開始する。

要求（仮想出力）を受取る。　　　１６１−２０３変更
をチェックする。

要求の型を決定する。　　　　　２３９−３１０描く。

　　　　　　　　　　　　　　　　４１０−４５７コピ
ーする。　　　　　　　　　　６１１−６５２置換する
。　　　　　　　　　　　５３７−５８５消去する。　
　　　　　　　　　　　５８７−６０９移動する。　　
　　　　　　　　　６３４−６７８変更を送る。　　　
　　　　　　１２６５−１５５２スクリーン　−　多重
ウィンドーにお けるライブデータ プログラム表Ｂは上述した単一スクリーン上の多重アプ
リケー７ョンからの“ライプ′ウィンドーの同時表示に
関する概念の１Ｃ′言語実施例を含む。下記の表は表Ｂ
の関連部分がどこに発見されるかを示す。

機能　　　　　　　　　　　　　　　プログラム表Ｂの
行番号主要台、初期設定、処理を　　　１２４−１４１
開始する。

要求を受取る。変更をチェ　　　１６１−２１３ツクす
る。

要求の型を決定する。　　　　　２３９−３１０アプリ
ケーシヨンを登録する。　　８４３−８６４描く、コピ
ーするなど。　　　　　３１２−８４１アプリケーシヨ
ンが登録され　　　１７８，１８０゜たかどうかチェッ
クする。　　　　　２０５−２１７要素がアプリケーシ
ョンに属　　１６５５−１６５９するかどうかチェック
する。

ここに開示した発明は多くの方法で変更することができ
、上記に具体的に示し説明した好ましい形以外の多数の
実施例の形をとることができることは当業者には明らか
であると思われる。例えば。

そのユーティリティはデータ処理システムまたはデータ
処理システムの他の特定に型に限定されるものではない
。

従って、添付の特許請求の範囲によって本発明の真の精
神および範囲内に入る本発明の総ての修正を含むことが
意図されている。

【図面の簡単な説明】

第１図は本発明を取入れた型の単一ネットワーク分散型
メツセージペースデータ処理りステムの代表的な実例を
示す。 第２図は本発明を取入れた型の多重ネ、ットワーク分散
型メツセージベースデータ処理システムを図解するブロ
ック図な示す。 第３図は本発明の分散型データ処理システムに用いられ
る標準メツセージ書式を示す。 第４図は本発明な取入れた塁のデータ処理システムのヒ
ユーマンインタフェースにおゆるピクチャ、ビュー（ｖ
ｌｅｗｓ　）およびウィンドー間の関係を示す。 ｇＩ４５図は本発明を取入れた型のデータ処理システム
システム内のヒユーマンインタフェースの相異なるレベ
ルの概念図を示す。 第６図は代表的な作業環境における基本的ヒューマンイ
ンタ７エースコンポーネント間の関係を示す。 第７図は１つの完全な画素の一般的構造を示す。 第８図は本発明のヒユーマンインタフェースシステム内
に含まれる代表的なスクリーンのコンポーネントを示す
。 第９図は本発明の好ましい実施例によりそれを介して多
重アプリケーションが単一ビデオ表示装置を共用できる
ピクチャ、ウィンドー、コンソールマネージャおよび仮
想出力マネージャ間の関係を示す。 第１０図は本発明の好ましい実施例によりアプリケーシ
ョンプログラムがどのようにしてコンソ−ルマネージャ
プロセスと対話しウィンドーおよびピクチャを作成およ
び破壊するかを図解する７０−チャートを示す。 第１１図は本発明の好ましい実施例によりピクチャを更
新しその結果を選択されたサイスのウィンドーに見るオ
ペレーションを示す。 第１２図は単一ピクチャが多重アプリケーションソフト
ウェアプログラムを共用できる方法を示すＯ 第１３図はピクチャマネージャがいくつかのアプリケー
ションを単一ピクチャに多重化する方法を示す。 第１４図は本発明のヒユーマンインタフェースシステム
内の単一スクリーン上の２つのアプリケーションのライ
ブ統合（ｌｉｖｅ　　ｉｎｔｅｇｒａｔｉｏｎ）を示す
。 第１５図はコンソールマネージャがどのようにして仮想
人力に動作して仮想出力を発生させるかｔ示す。 第１６図は仮想入力がどのようにコンソールマネージャ
によって扱われるかを示す。 第１７図は仮想入力がどのようにピクチャマネージャに
よって扱われるかを示す。 第１８図はコンソールマネージャがどのようにして多重
アプリケーションソフトウェアプログラムが多重ピクチ
ャによって表されるのを可能にするか、どのようにして
多重ウィンドーが１つのピクチャの相異なるビューを与
えることができるかを示す。 第１９図は幾つかのウィンドーがどのようにして１つの
代表的なスクリーン上に同時に表示されるかを示す。 粥５図において。 １８０・・・アプリケーションズ １８１・・・表示 １８２・・・形式 ％式％ １８６・・・仮想入力デバイス １８７・・・仮想出力デバイス １８８・・・物理デバイス。

Claims (1)

1. 【特許請求の範囲】 １、少なくとも１つの抽象的なデバイス独立性ピクチャ
   で情報を表す手段と、 サイズ情報を含む第１メッセージを発生させる手段と、 前記第１メッセージに応答して前記の１つのピクチャに
   ウィンドーを作るコンソールマネージャプロセスとを含
   み、前記ウィンドーのサイズは前記第１メッセージに含
   まれる前記サイズ情報によって決定される、 データ処理システムのヒューマンインタフェース。 ２、サイズ情報を含む第２メッセージを発生させる手段
   と、 前記第２メッセージに応答して１つのピクチャに第２ウ
   ィンドーを作るコンソールマネージャプロセスとを更に
   含み、前記第２ウィンドーのサイズは前記第２メッセー
   ジに含まれる前記サイズ情報によって決定され、前記ウ
   ィンドーおよび前記第２ウィンドーのサイズは互いに独
   立してる、特許請求の範囲第１項に述べられているヒュ
   ーマンインタフェース。 ３、少なくとも１つの抽象的なデバイス独立性ピクチャ
   で情報を表す手段と、 前記ピクチャを複数の独立したアプリケーションによっ
   て共用できるようにする手段とを含む、データ処理シス
   テムのヒューマンインタフェース。 ４、ピクチャはユーザインタフェース情報を含み、ヒュ
   ーマンインタフェースは更にアプリケーションのうちの
   少なくとも１つからのイメージと前記ユーザインタフェ
   ースからのイメージとを同時に表示する手段を含む、 特許請求の範囲第３項に述べられているヒューマンイン
   タフェース。 ５、前記ユーザインタフェース情報はメニュー情報、ア
   イコン情報、ヘルプ情報、およびプロンプト情報からな
   るグループからの情報を含み、前記の少なくとも１つの
   アプリケーションはテキスト編集アプリケーション、ス
   プレッドシートアプリケーション、グラフィックスアプ
   リケーション、データベースアプリケーション、および
   プロセス制御アプリケーションからなるグループからの
   ものである前記特許請求の範囲第４項に述べられている
   ヒューマンインタフェース。 ６、少なくとも１つの物理デバイスから入力を受取る手
   段と、 前記物理デバイス入力を仮想入力に変換する手段と、 前記仮想入力に応答して前記仮想入力に処理オペレーシ
   ョンを行う手段とを含む、 データ処理システムの仮想入力インタフェース。 ７、前記の少なくとも１つの物理デバイスは前記システ
   ムの残部のオペレーションに影響を与えることなく前記
   システムから除去できる特許請求の範囲第６項に述べら
   れている仮想入力インタフェース。 ８、システム処理オペレーションが発生させた仮想出力
   を受取る手段と、 前記仮想出力を、少なくとも１つの物理デバイスが使用
   するのに適した少なくとも１つの物理出力に変換する手
   段とを含む、 データ処理システムの仮想出力インタフェース。 ９、前記の少なくとも１つの物理デバイスは前記システ
   ムの残部のオペレーションに影響を与えることなく前記
   システムから除去できる特許請求の範囲第８項に述べら
   れている仮想出力インタフェース。 １０、少なくとも１つの抽象的なデバイス独立ピクチャ
   で情報を表す手段と、 前記ピクチャを複数の独立したアプリケーションによっ
   て共用できるようにする手段と、 前記ピクチャからのライブ情報を２つ以上のウィンドー
   に同時に表示できるようにする手段とを含む、 データ処理システムのヒューマンインタフェース。 １１、前記ピクチャはユーザインタフェース情報を含み
   、ヒューマンインタフェースは更に前記アプリケーショ
   ンのうちの少なくとも１つからのイメージと前記ユーザ
   インタフェース情報からのイメージとを同時に表示する
   手段を含む、 特許請求の範囲第１０項に述べられているヒューマンイ
   ンタフェース。 １２、前記ユーザインタフェース情報はメニュー情報、
   アイコン情報、ヘルプ情報、およびプロンプト情報から
   なるグループからの情報を含み、前記の少なくとも１つ
   のアプリケーションはテキスト編集アプリケーション、
   スプレッドシートアプリケーション、グラフィックスア
   プリケーション、データベースアプリケーションおよび
   プロセス制御アプリケーションからなるグループからの
   ものである特許請求の範囲第１０項に述べられているヒ
   ューマンインタフェース。