JPH07200233A

JPH07200233A - グラフィック部品管理装置

Info

Publication number: JPH07200233A
Application number: JP5335024A
Authority: JP
Inventors: Ken Kameyama; 研亀山
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 1993-12-28
Filing date: 1993-12-28
Publication date: 1995-08-04

Abstract

(57)【要約】【目的】プログラムのコーディングによって複数のグ
ラフィック部品の相互関係を定義する際の問題を解決す
る。【構成】リソースファイル４０には、構築処理が相互
に関連する複数のグラフィック部品の相互関係を規定す
る相互関係リソースが登録されている。ウィンドウマネ
ージャ１２は、アプリケーションプログラム１１からウ
ィジェットの構築処理の実行要求を受けると、リソース
ファイル４０に登録されている相互関係リソースに基づ
いて、複数のウィジェットの構築処理を実行する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、グラフィカル・ユー
ザ・インタフェースを構築するための処理が相互に関連
する複数のグラフィック部品の相互関係を管理するグラ
フィック部品管理装置に関する。

【０００２】

【従来の技術】一般に、ワークステーション等の個人向
け高機能コンピュータにおいては、ユーザ・インタフェ
ースとして、グラフィカル・ユーザ・インタフェース
（以下、「ＧＵＩ」という。）が採用されている。

【０００３】このＧＵＩを提供するシステムとしては、
例えば、Ｘウィンドウ・システム（Ｘウィンドウは登録
商標）が知られている。このＸウィンドウ・システム
は、複数のウィンドウを使って、複数の情報を同時に表
示可能なマルチ・ウィンドウ・システムである。

【０００４】このＸウィンドウ・システムにおいては、
ＧＵＩを構築するためのグラフィック部品（ボタン、ダ
イアログ等）として、ウィジェットが用意されている。
このウィジェットは、イベントが発生すると、コールバ
ックという手段により、アプリケーションプログラムや
他のウィジェットと通信することができる。また、各ウ
ィジェットは、ある特定のクラスに属し、常に関連する
ウィンドウを有する。

【０００５】このＸウィンドウ・システムに提供されて
いる従来のツールキット（ＭＯｔｉｆ等）においては、
あるウィジェットに発生したイベントが他のウィジェッ
トに及ぼす作用を定義する方式が十分提供されていなか
った（下記の文献１，２参照）。

【０００６】文献１：ＸＴｏｏｌｋｉｔプログラミング
ＯＳＦ／ＭＯＴＩＦ版Ｄ．Ａ．ヤング著トッパン発行１９９１年４月１５日発行文献２：ＯＳＦ／Ｍｏｔｉｆプログラマーズリファレ
ンスリリース１．１ＯｐｅｎＳｏｆｔｗａｒｅＦ
ｏｕｎｄａｔｉｏｎ著株式会社日立制作所ソフトウェア開発本部訳トッパン発行１９９１年１１月２５日言い換えれば、従来のツールキットにおいては、ＧＵＩ
を構築するための処理（以下、「構築処理」という。）
が相互に関連する複数のウィジェットの相互関係を定義
する方式が十分提供されていなかった。

【０００７】このため、従来は、複数のウィジェットの
相互関係をアプリケーションプログラムのコーディング
によって定義することにより、この相互関係を管理する
ようになっていた。

【０００８】なお、上述した構築処理としては、例え
ば、ウィジェットを画面上に表示する表示処理、画面上
から消去する消去処理、画面から消去するとともに、表
示用の画像データも破壊してしまう削除処理といった処
理がある。

【０００９】

【発明が解決しようとする課題】以上述べたように、従
来は、構築処理が相互に関連する複数のウィジェットの
相互関係を管理する場合、この相互関係をアプリケーシ
ョンプログラムのコーディングにより定義するようにな
っていた。

【００１０】しかしながら、このような構成では、ア
プリケーションプログラムの開発工数が多くなるととも
に、このプログラムを開発した後、複数のウィジェット
の相互関係を変更する場合、プログラムを書き替えなけ
ればならないという問題があった。

【００１１】また、このような構成では、複数のウィ
ジェットの相互関係を明確に定義することが難しいため
に、ＧＵＩの仕様から発生するバグ（例えば、入力を受
付けなくなるなどのバグ）を誘発する可能性があるとい
う問題があった。

【００１２】さらに、このような構成では、特定の相
互関係（例えば、複数のダイアログを重ね表示する場合
の優先度）を定義する場合、その定義が極めて難しかっ
たり、全く定義することができないことがあるという問
題があった。

【００１３】

【課題を解決するための手段】上記課題を解決するため
に、この発明は、構築処理が相互に関連する複数のグラ
フィック部品の相互関係を管理する装置において、上記
相互関係を規定する情報を提供する手段と、この手段に
より提供される相互関係規定情報に基づいて、複数のグ
ラフィック部品の構築処理を実行する手段とを設けるよ
うにしたものである。

【００１４】

【作用】上記構成においては、構築処理が相互に関連す
る複数のグラフィック部品の相互関係は、プログラムで
はなく、データとして定義される。そして、このデータ
によって表される相互関係に基づいて、複数のグラフィ
ック部品の構築処理が実行される。

【００１５】

【実施例】以下、図面を参照しながらこの発明の実施例
を詳細に説明する。

【００１６】図１は、この発明の第１の実施例の構成を
示すブロック図である。なお、以下の説明では、この発
明をＸウィンドウ・システムに適用した場合を代表とし
て説明する。

【００１７】Ｘウィンドウ・システムにおいては、その
機能を実現する方式として、サーバ・クライアント方式
が採用されている。ここで、サーバ・クライアント方式
とは、クライアントとサーバという２つのプログラムに
よって目的とする機能を実現する方式である。

【００１８】図１は、このサーバ・クライアント方式の
モデル図に基づいて、この発明の第１の実施例の構成を
概念的に表したものである。

【００１９】すなわち、図１において、１０は、サーバ
に様々な要求を出すクライアントであり、２０は、ハー
ドウェア部３０を管理するサーバである。

【００２０】クライアント１０は、サーバ２０に対し
て、例えば、ウィンドウの開閉や、ウィンドウに対する
ウィジェットやテキストの表示を要求する。

【００２１】サーバ２０は、クライアント１０からの要
求に基づいて、ディスプレイ３１の画面上でウィンドウ
を開閉したり、ウィンドウにウィジェットやテキストを
表示したりする。また、このサーバ２０は、イベントが
発生すると、これをクライアント１０に報告する。

【００２２】なお、イベントは、ユーザがマウス３２の
ボタンをクリックしたり、キーボード３３のキーを押す
ことにより発生する。また、このイベントは、ウィンド
ウの状態が変化することによっても発生する。

【００２３】クライアント１０としては、アプリケーシ
ョンプログラム、ウィンドウマネージャ、ユーティリテ
ィ等がある。図１には、アプリケーションプログラム１
１と、ウィンドウマネージャ１２を示す。

【００２４】アプリケーションプログラム１１は、ウィ
ンドウマネージャ１２に対して、例えば、ウィンドウの
開閉やウィジェットの生成を要求する。また、このアプ
リケーションプログラム１１は、サーバ２０からイベン
トを受けると、これを解読し、この解読結果に基づい
て、ウィンドウマネージャ１２に対して、ウィジェット
の構築処理等を要求する。

【００２５】ここで、ウィジェットの構築処理とは、上
記の如く、ウィジェットの表示、消去、削除等の処理を
いう。また、ウィジェットの生成とは、ウィジェットの
シンボルを表示するための画像データを生成することを
いう。

【００２６】ウィンドウマネージャ１２は、アプリケー
ションプログラム１１により要求されたウィンドウの開
閉処理等をサーバ２０に依頼したり、ウィンドウやウィ
ジェットの表示位置等を管理したり、ウィジェットを生
成したりする。また、このウィンドウマネージャ１２
は、サーバ２０から報告のあったイベントをアプリケー
ションプログラム１１に中継する。

【００２７】以上は、クライアント・サーバ方式の一般
的な構成である。次に、この発明の特徴とするウィジェ
ットの相互関係を管理する構成を説明する。

【００２８】ウィジェットは、形態（サイズ、色、形
等）や動作を規定するプログラムパラメータを有する。
このパラメータは、リソースと呼ばれる。ウィンドウマ
ネージャ１２は、アプリケーションプログラム１１から
ウィジェットの生成要求を受けると、このリソース（特
に、形態に関するリソース）に基いてウィジェットを生
成する。

【００２９】このような構成によれば、リソースの内容
を変更することにより、ウィジェットの形態を簡単かつ
自由に変更することができる。

【００３０】この実施例は、この点に着目し、各ウィジ
ェットの形態や動作を規定するリソース（以下、「形態
リソース」という。）のほかに、構築処理が相互に関連
する複数のウィジェットの相互関係を規定するリソース
（以下、「相互関係リソース」という。）を用意し、こ
の相互関係リソースに基いて、複数のウィジェットの構
築処理を実行するようにしたものである。

【００３１】この実行は、ウィンドウマネージャ１２に
よりなされる。したがって、この実施例のウィンドウマ
ネージャ１２には、上述したウィンドウの開閉機能等の
ほかに、構築処理が相互に関連する複数のウィジェット
の構築処理を実行する機能が設けられている。

【００３２】また、ウィンドウマネージャ１２に対する
相互関係リソースの提供は、リソースファイル４０を使
ってなされる。したがって、この実施例のウィンドウマ
ネージャ１２には、リソースファイル４０から相互関係
リソースを読み出す機能が設けられている。

【００３３】図２は、相互関係リソースの一例を示す図
である。なお、図２では、各相互関係リソースの内容を
分かり易くするために、その名前を実際の命名体系では
なく、日本語で表現してある。

【００３４】これら複数の相互関係リソースのうち、例
えば、「重なり優先度」は、複数のウィジェットが重な
った時のあるウィジェットの表示の優先度を示すリソー
スである。この相互関係リソースを使って、ウィジェッ
ト１の優先度が１であることを表す場合は、例えば、
「ウィジェット１．重なり優先度：１」と表される。

【００３５】また、「表示時に削除」は、あるウィジェ
ットが表示されたときに、削除されるウィジェットのリ
ストを示すリソースである。この相互関係リソースを使
って、“ウィジェット１を表示する場合に、ウィジェッ
ト２を削除する”という関係を表す場合は、例えば、
「ウィジェット１．表示時に削除：ウィジェット２」と
表される。

【００３６】なお、詳細な説明は省略するが、図２に示
すその他の相互関係リソースについても、上述した「表
示時に削除」という相互関係リソースと同じように考え
ることができる。

【００３７】図３は、リソースファイル４０の構成の一
例を示す図である。図示のリソースファイル４０は、相
互関係リソースの登録と形態リソースの登録で兼用され
るようになっている。この場合、リソースファイル４０
は、２つの領域を有し、相互関係リソースと形態リソー
スを別々に保持するようになっている。

【００３８】以上はこの実施例の概念的な構成である。
次に、図４を参照しながら、この実施例のハードウェア
構成を説明する。

【００３９】図４は、この実施例のハードウェア構成の
一例を示すブロック図である。図示の如く、この実施例
のハードウェア構成は、通常のコンピュータのハードウ
ェア構成とほぼ同じである。

【００４０】すなわち、図４において、３４は、アプリ
ケーションプログラム１１、ウィンドウマネージャ１
２、Ｘサーバ２０といった各種プログラムを実行するた
めの中央処理装置（以下、「ＣＰＵ」という。）であ
る。したがって、この実施例の特徴とする処理は、この
ＣＰＵ３４により実行されることになる。

【００４１】３５は、このＣＰＵ３４により実行される
プログラムや各種データの記憶に使用されるメモリであ
る。したがって、この実施例の特徴とする処理を規定す
るプログラムは、このメモリ３５に格納されることにな
る。

【００４２】３６は、上述したリソースファイル４０等
が設定されるディスクである。したがって、この実施例
の特徴とする相互関係リソースは、このディスク３６に
登録されることになる。

【００４３】上記構成において、相互関係リソースに基
づいて、複数のウィジェットの構築処理を実行する動作
を説明する。

【００４４】図５は、この場合のアプリケーションプロ
グラム１１の処理を示すフローチャートである。なお、
図５では、説明を簡単にするために、ウィジェットに関
係する部分の処理だけを簡単に示す。また、この図５で
は、イベントが発生した場合は、必ず、ウィンドウマネ
ージャ１２に対して、構築処理の実行要求を与えるもの
としている。

【００４５】このアプリケーションプログラム１１の処
理においては、まず、ウィンドウマネージャ１２に対し
て、ウィジェットの生成を要求する処理がなされる（ス
テップＳ１１）。これにより、ウィンドウマネージャ１
２では、後述するように、要求されたウィジェットの生
成がなされる。つまり、要求されたウィジェットを表示
するための画像データの生成がなされる。

【００４６】この後、イベントが発生したか否かを判定
する処理がなされる（ステップＳ１２）。これは、サー
バ２０からウィンドウマネージャ１２を介してイベント
が発生した旨の報告を受けたか否かを判定することによ
りなされる。

【００４７】イベントが発生しなければ、そのままイベ
ントの発生を監視する処理が続けられる。これに対し、
イベントが発生すると、発生したイベントの内容を解読
する処理がなされる（ステップＳ１３）。この解読によ
り、ウィンドウマネージャ１２に要求すべきウィジェッ
トの構築処理（表示、消去、削除）が決定される。

【００４８】この解読が終了すると、これによって定め
られた構築処理を、ウィンドウマネージャ１２に要求す
る処理がなされる（ステップＳ１４）。これにより、ウ
ィンドウマネージャ１２では、後述するように、要求さ
れた構築処理に関連する相互関係リソースに基づいて、
複数のウィジェットの構築処理が実行される。

【００４９】この処理が終了すると、ステップＳ１２に
戻る。これにより、イベントが発生した時点で再び上述
した処理がなされる。以下、同様に、イベントが発生す
るたびに上述した処理が繰り返される。

【００５０】図６は、ウィンドウマネージャ１２の処理
を示すフローチャートである。なお、図６でも、説明を
簡単にするために、ウィジェットに関する処理の部分だ
けを簡単に示す。また、イベントが発生した場合は、必
ず、アプリケーションプログラム１１から構築処理の実
行要求を受けるものとしている。

【００５１】このウィンドウマネージャ１２の処理にお
いては、まず、アプリケーションプログラム１１により
要求されたウィジェットを生成する処理がなされる（ス
テップＳ２１）。この生成は、リソースファイル４０に
登録されている形態リソースに基づいてなされる。生成
されたウィジェット、つまり、ウィジェットのシンボル
を表示するための画像データは、削除要求を受けるま
で、例えば、メモリ３５に保存される。

【００５２】この処理が終了すると、イベントが発生し
たか否かを判定する処理がなされる（ステップＳ２
２）。この判定は、サーバ２０からイベントが発生した
旨の報告を受けたか否かを判定することによりなされ
る。

【００５３】イベントが発生した場合は、これをアプリ
ケーションプログラム１１に報告する処理がなされる
（ステップＳ２３）。この後、ステップＳ２４の処理が
なされる。これに対し、イベントが発生しない場合は、
そのままステップＳ２４の処理がなされる。

【００５４】このステップＳ２４においては、アプリケ
ーションプログラム１１からウィジェットの構築処理の
実行要求を受けたか否かを判定する処理がなされる。こ
の要求を受けた場合は、ステップＳ２５の処理がなされ
る。これに対し、要求を受けない場合は、上記ステップ
Ｓ２２に戻り、要求を受けるまで、ステップＳ２２，Ｓ
２４の処理が繰り返される。

【００５５】ステップＳ２５においては、リソースファ
イル４０から相互関係リソースを読み出す処理がなされ
る。この場合、相互関係リソースとしては、アプリケー
ションプログラム１１により要求された構築処理に関連
するリソースのみが読み出される。

【００５６】例えば、要求された構築処理がウィジェッ
ト１の消去である場合は、このウィジェット１の消去に
関連するリソースのみが読み出される。これは、リソー
スの読出し時間を短縮するためである。

【００５７】すなわち、リソースファイル４０から相互
関係リソースを読み出す場合、要求のあった構築処理
（上の例では、ウィジェット１の消去）に関連するリソ
ースではなく、この構築処理の要求のあったウィジェッ
ト（上の例では、ウィジェット１）に関連するリソース
を読み出すことが考えられる。

【００５８】しかし、ウィジェットに関連するリソース
を読み出すようにすると、一般的には、このリソースの
方が構築処理に関連するリソースよりも多いので、リソ
ースの読出し時間が長くなることが多い。

【００５９】そこで、この実施例では、構築処理に関連
するリソースのみを読み出すことにより、読出し時間の
短縮を図っている。なお、これについては、後で、具体
例を使って詳細に説明する。

【００６０】相互関係リソースの読出しが終了すると、
読み出された相互関係リソースの中から、現在の画面の
表示状況に関連するリソースを選択する処理がなされる
（ステップＳ２６）。

【００６１】例えば、リソースファイル４０から「ウィ
ジェット１．表示時に削除：ウィジェット２」なるリソ
ースが読み出された場合は、このリソースは、ウィジェ
ット２が画面に表示されている場合のみ選択される。な
お、これについても、後で、具体例を使って詳細に説明
する。

【００６２】相互関係リソースの選択が終了すると、選
択された相互関係リソースに基づいて、複数のウィジェ
ットの構築処理を実行する処理がなされる（ステップＳ
２７）。例えば、相互関係リソースとして上述した「ウ
ィジェット１．表示時に削除：ウィジェット２」なるリ
ソースが読み出された場合は、ウィジェット１の表示と
ウィジェット２の削除が実行される。

【００６３】この処理が終了すると、ステップＳ２２に
戻る。これにより、イベントが発生した時点で、再び、
上述した処理が実行される。以下、同様に、イベントが
発生するたびに、上述した処理が繰り返される。

【００６４】なお、ウィジェットの表示位置は、予め定
めた規則に基づいて定められる。また、ウィジェットの
構築処理は、実際には、上記の如く、ウィンドウマネー
ジャ１２の依頼に基づいて、サーバ２０により実行され
る。

【００６５】ここで、図７〜図１１を参照しながら、図
６におけるステップＳ２５，Ｓ２６の処理を具体例を使
って説明する。

【００６６】なお、以下の説明では、ウィジェットがダ
イアログである場合を代表として説明する。ここで、ダ
イアログとは、簡単には、ウィンドウの本体を構成する
長方形のグラフィック部品と考えることができる。

【００６７】図７は、リソースファイル４０に登録され
ているリソースのうち、複数のダイアログの相互関係の
管理に関連するリソースの一例を示す図である。

【００６８】図において、を除く６つのリソース、
，，，，は、複数のダイアログの相互関係を
規定する相互関係リソースである。これに対し、は、
後処理関数をコールバックとして登録するためのリソー
スである。このリソースは、すでに、上述したＭｏｔ
ｉｆ等のツールキットで提供されている。

【００６９】ここで、コールバックとは、ウィジェット
にイベントが発生した場合に、コールされる関数であ
る。このコールバックは、ウィジェットの生成時（シン
ボルの画像データ生成時）に、ウィンドウマネージャ１
２により、リソースファイル４０に登録される。

【００７０】このようなリソースをリソースファイル
４０に登録しておくことにより、後処理が自動的に行わ
れる。これにより、複数のダイアログの相互関係と、そ
れに伴う後処理を切り分けて考えることができるので、
ウィンドウマネージャ１２を作成する際の負担を軽減す
ることができる。

【００７１】各リソースを簡単に説明すると、，，
は、ダイアログ１，２，３の重なり優先度を示すリソ
ースである。は、ダイアログ１の表示によって削除さ
れるダイアログのリストを示すリソースである。は、
ダイアログ１の削除によって表示されるダイアログのリ
ストを示すリソースである。は、ダイアログ６の表示
によって消去されるダイアログのリストを示すリソース
である。は、ダイアログ１が消去される時の後処理関
数を示すリソースである。

【００７２】図８は、リソース，，に基づく処理
（第１の具体例）を説明するため図である。

【００７３】今、図８（ａ）に示すように、ディスプレ
イ３１の画面上に、ダイアログ２，３だけが表示されて
いるものとする。この場合、ダイアログ２の方がダイア
ログ３より優先度が高いため、ダイアログ２がダイアロ
グ３の上に重ね表示される。

【００７４】この状態において、アプリケーションプロ
グラム１１からダイアログ１の表示要求が送られてくる
と、リソースファイル４０からリソース，が読み出
される。

【００７５】すなわち、表示要求のあったダイアログ１
に関連するリソースとしては、、、、がある。
しかし、これら４つのリソース，，，のうち、
ダイアログ１の表示要求に関連するリソースは、、
の２つである。したがって、この場合は、この２つのリ
ソース，だけが読み出される。

【００７６】読み出されたリソース，は、現在の画
面の表示状況に応じて適宜選択される。今の例では、現
在、画面上に、ダイアログ２，３が表示され、ダイアロ
グ４は表示されていない。したがって、この場合、リソ
ースが選択され、リソースは選択されない。その結
果、図８（ｂ）に示すように、ダイアログ１がダイアロ
グ２の上に重ね表示される。

【００７７】図９は、リソースに基づく処理（第２の
具体例）を説明するための図である。

【００７８】今、図９（ａ）に示すように、ダイアログ
４が表示されている状態において、アプリケーションプ
ログラム１１からダイアログ１の表示要求が送られてき
たものとする。この場合、リソースファイル４０から
は、上記の如く、リソース，が読み出される。

【００７９】しかし、現在、画面には、ダイアログ４だ
けが表示されている。したがって、この場合、読み出さ
れた２つのリソース，のうち、リソースだけが選
択され、リソースは選択されない。その結果、図９
（ｂ）に示すように、ダイアログ１が表示され、ダイア
ログ４が削除される。

【００８０】図１０は、リソースに基づく処理（第３
の具体例）を説明するための図である。

【００８１】今、図１０（ａ）に示すように、ダイアロ
グ１が表示されている状態において、ダイアログ１の削
除要求が送られてきたものとする。この場合、この要求
に関連するリソースはのみであるから、この場合は、
このリソースのみが読み出される。その結果、図１０
（ｂ）に示すように、ダイアログ１が削除され、ダイア
ログ５が表示される。

【００８２】図１１は、リソース，に基づく処理
（第４の具体例）を説明するための図である。

【００８３】今、図１１（ａ）に示すように、ダイアロ
グ１が表示されている状態において、ダイアログ６の表
示要求が送られてきたものとする。この場合、この要求
に関連するリソースはであるから、このリソースが
読み出される。

【００８４】このリソースは、ダイアログ６の表示時
に、ダイアログ１の消去を指示するリソースである。リ
ソースファイル４０には、このダイアログ１の消去に関
連するリソースとして、リソースが設けられている。
したがって、この場合は、リソースの他に、リソース
も読み出される。

【００８５】その結果、図１１（ｂ）に示すように、リ
ソースに基づいて、ダイアログ６が表示され、ダイア
ログ１が消去される。このとき、リソースに基づい
て、ダイアログ１の消去に対する後処理が自動的に行わ
れる。

【００８６】（１）以上詳述したこの実施例によれば、
構築処理が相互に関連する複数のウィジェットの相互関
係を規定するリソースを用意し、この相互関係リソース
に基づいて、複数のウィジェットの構築処理を実行する
ようにしたので、次のような効果が得られる。

【００８７】アプリケーションプログラムのコーディ
ングによって複数のウィジェットの相互関係を定義する
必要がないので、アプリケーションプログラムの開発時
に、ＧＵＩの開発に要する工数を短縮することができる
とともに、ＧＵＩの仕様変更やバグに対応する工数を短
縮することができる。

【００８８】従来に比べ、複数のウィジェットの相互
関係を把握し易いため、ＧＵＩ上のバグ（画面のデット
ロックなど）の発生を防止することができる。

【００８９】相互関係リソースを変更することによ
り、複数のウィジェットの相互関係を変更することがで
きるので、複雑な相互関係も、簡単にかつ自由に定義す
ることができる。

【００９０】これにより、例えば、複数のダイアログを
グループ分けしておき、あるグループに属する複数のダ
イアログのうち、いずれか１つの削除要求を受けると、
そのグループに属するすべてのダイアログを削除すると
いった相互関係や、特定のダイアログが表示されている
間だけ、画面上に表示されるダイアログや隠れているダ
イアログを設定するといった相互関係も、簡単に定義す
ることができる。

【００９１】（２）また、この実施例によれば、相互関
係リソースを、形態リソースと同様に、リソースファイ
ル４０を使ってウィンドウマネージャ１２に提供するよ
うにしたので、その提供手段を新たに構築することな
く、形態リソースの提供手段を使って提供することがで
きる。

【００９２】（３）さらに、この実施例によれば、リソ
ースファイル４０から相互関係リソースを読み出す際、
構築処理の実行要求のあったウィジェットに関連するす
べてのリソースを読み出すのではなく、要求のあった構
築処理に関連するリソースのみを読み出すようにしたの
で、リソースの読出し時間を短縮することができる。

【００９３】（４）さらにまた、この実施例によれば、
リソースファイル４０に、相互関係リソースだけでな
く、後処理関数をコールバックとして登録するためのリ
ソースも登録するようにしたので、ウィジェットの相互
関係と、それに伴う後処理を切り分けて考えることがで
きる。これにより、ウィンドウマネージャ１２作成時の
負担を軽減することができる。

【００９４】図１２はこの発明の第２の実施例の構成を
示すブロック図である。

【００９５】先の実施例では、ウィンドウマネージャ１
２により記憶内容を読み出されるリソースファイル４０
を使って、相互関係リソースをウィンドウマネージャ１
２に提供する場合を説明した。

【００９６】これに対し、この実施例は、アプリケーシ
ョンプログラムからウィンドウマネージャに、構築処理
の実行要求を伝えるためのメッセージを使って、アプリ
ケーションプログラムからウィンドウマネージャに相互
関係リソースを供給するようにしたものである。

【００９７】図１２は、この場合の概念的な構成を示す
ブロック図である。なお、図１２において、図１と同一
部には同一符号を付し、詳細な説明を省略する。

【００９８】図１２において、１６はこの実施例のアプ
リケーションプログラムであり、１７は、同じく、ウィ
ンドウマネージャである。

【００９９】この実施例のアプリケーションプログラム
１６は、先の実施例のアプリケーションプログラム１１
と異なり、上記要求メッセージを使って相互関係リソー
スをウィンドウマネージャ１７に提供する機能を有す
る。このため、この実施例のウィンドウマネージ１７に
は、リソースファイル４０から相互関係リソースを読み
出す機能は設けられていない。

【０１００】図１３は、アプリケーションプログラム１
６の処理を示すフローチャートである。なお、図１３に
おいて、先の図５と同一部には、同一符号を付して、詳
細な説明を省略する。

【０１０１】図１３において、図４と異なる点は、イベ
ントの解読処理ステップＳ１３の後に、リソースファイ
ル４０から相互関係リソースを読み出すステップＳ１６
が設けられている点である。

【０１０２】また、ウィンドウマネージャ１２に対し
て、ウィジェットの構築処理を要求するステップＳ１７
において、図１４に示すように、要求メッセージのパラ
メータ部に、相互関係リソースが挿入される点である。

【０１０３】なお、この実施例においても、相互関係リ
ソースの読出しは、イベントの解読により決定された構
築処理に関連するリソースのみについてなされる。ま
た、メッセージに挿入されるリソースとしては、上述し
たような後処理関数を登録するためのリソースも含まれ
る。

【０１０４】図１５は、ウィンドウマネージャ１７の処
理を示すフローチャートである。なお、図１５におい
て、先の図６と同一部には、同一符号を付して、詳細な
説明を省略する。

【０１０５】この図１５において、図６と異なる点は、
図６における相互関係リソースの読出しステップＳ２５
が省略されている点である。これは、この実施例では、
上記の如く、相互関係リソースがアプリケーションプロ
グラム１６から与えられるからである。

【０１０６】上記構成においては、アプリケーションプ
ログラム１６で、ウィジェットの構築処理の実行要求が
発生すると、まず、リソースファイル４０からこの構築
処理に関連する相互関係リソースを読み出す処理がなさ
れる（ステップＳ１６）。この後、読み出された相互関
係リソースを含む要求メッセージをウィンドウマネージ
ャ１７に供給する処理がなされる（ステップＳ１７）。

【０１０７】これにより、ウィンドウマネージャ１７で
は、送られてきた相互関係リソースから、現在の画面の
表示状態に関連するリソースを選択する処理がなされる
（ステップＳ２６）。この後、この選択リソースに基づ
いて、複数のウィジェットの構築処理の実行がなされ
る。

【０１０８】以上詳述したこの実施例においても、先の
実施例と同様の効果を得ることができることは勿論、さ
らに、次のような効果が得られる。

【０１０９】すなわち、この実施例では、相互関係リソ
ースが要求メッセージを使って提供されるので、ウィン
ドウマネージャ１７は構築処理の実行要求を受けた時点
で、すぐに、構築処理の実行を開始することができる。

【０１１０】以上、この発明の２つの実施例を説明した
が、この発明は、上述したような実施例に限定されるも
のではない。

【０１１１】（１）例えば、先の第２の実施例では、相
互関係リソースをリソースファイル４０から読み出す場
合を説明した。しかし、この実施例では、このリソース
をアプリケーションプログラム上にデータとして設定す
るようにしてもよい。

【０１１２】このような構成であっても、相互関係を変
更する場合は、プログラムに書き込まれたデータだけを
変更すればよいので、プログラムのコーディングを変更
する場合に比べ、変更が容易となる。

【０１１３】（２）また、先の第１，第２実施例では、
この発明をＸウィンドウ・システムに適用する場合を説
明した。しかし、この発明は、ＧＵＩを有するシステム
であれば、Ｘウィンドウ・システム以外のシステムにも
適用することができる。

【０１１４】すなわち、ＧＵＩを有するシステムであれ
ば、Ｘウィンドウ・システムのようなマルチ・ウィンド
ウ・システム以外のウィンドウ・システム、さらには、
ウィンドウ・システム以外のシステムにも適用すること
ができる。

【０１１５】（３）このほかにも、この発明は、その要
旨を逸脱しない範囲で種々様々変形実施可能なことは勿
論である。

【０１１６】

【発明の効果】以上詳述したようにこの発明によれば、
構築処理が相互に関連する複数のグラフィック部品の相
互関係を規定するリソースを用意し、この相互関係リソ
ースに基づいて、複数のグラフィック部品の構築処理を
実行するようにしたので、プログラムのコーディングに
より、相互関係を定義する場合の問題を解決可能なグラ
フィック部品管理装置を提供することができる。

【図面の簡単な説明】

【図１】この発明の第１の実施例の概念的な構成を示す
ブロック図である。

【図２】第１の実施例の相互関係リソースの一例を示す
図である。

【図３】第１の実施例のリソースファイルの構成の一例
を示す図である。

【図４】第１の実施例のハードウェア構成を示す図であ
る。

【図５】第１の実施例のアプリケーションプログラムの
処理を示すフローチャートである。

【図６】第１の実施例のウィンドウマネージャの処理を
示すフローチャートである。

【図７】第１の実施例の相互関係リソースの具体例を示
す図である。

【図８】第１の実施例の処理の第１の具体例を説明する
ための図である。

【図９】第１の実施例の処理の第２の具体例を説明する
ための図である。

【図１０】第１の実施例の処理の第３の具体例を説明す
るための図である。

【図１１】第１の実施例の処理の第４の具体例を説明す
るための図である。

【図１２】この発明の第２の実施例の概念的な構成を示
すブロック図である。

【図１３】第２の実施例のアプリケーションプログラム
の処理を示すフローチャートである。

【図１４】第２の実施例の要求メッセージの構成を示す
図である。

【図１５】第２の実施例のウィンドウマネージャの処理
を示すフローチャートである。

【符号の説明】

１０…クライアント２０…サーバ３０…ハードウエア部４０…リソースファイル１１，１６…アプリケーションプログラム１２，１７…ウィンドウマネージャ３１…ディスプレイ３２…マウス３３…キーボード３４…ＣＰＵ３５…メモリ３６…ディスク

Claims

【特許請求の範囲】

【請求項１】グラフィカル・ユーザ・インタフェース
を構築するための処理が相互に関連する複数のグラフィ
ック部品の相互関係を管理するグラフィック部品管理装
置において、前記複数のグラフィック部品の相互関係を規定する相互
関係規定情報を提供する相互関係規定情報提供手段と、前記処理の実行要求を受けると、前記相互関係規定情報
提供手段により提供される相互関係規定情報に基づい
て、前記複数のグラフィック部品の処理を実行する処理
実行手段とを具備したことを特徴とするグラフィック部
品管理装置。
【請求項２】前記相互関係規定情報提供手段は、前記
処理実行手段により記憶内容が読み出される情報記憶手
段であることを特徴とする請求項１記載のグラフィック
部品管理装置。
【請求項３】前記処理実行手段は、前記情報記憶手段から前記実行要求によって要求された
処理に関連する相互関係規定情報のみを読み出す情報読
出し手段と、この情報読出し手段により読み出された相互関係規定情
報の中から、現在の画面の表示状態に関連する相互関係
規定情報のみを選択する情報選択手段と、この情報選択手段により選択された相互関係規定情報に
基づいて、前記複数のグラフィック部品の処理を実行す
る実行手段とを具備したことを特徴とする請求項２記載
のグラフィック部品管理装置。
【請求項４】前記相互関係規定情報提供手段は、前記
処理の実行要求が発生すると、この要求を前記処理実行
手段に伝えるためのメッセージを使って、前記相互関係
規定情報を前記処理実行手段に供給するように構成され
ていることを特徴とする請求項１記載のグラフィック部
品管理装置。
【請求項５】前記相互関係規定情報提供手段は、前記相互関係規定情報を記憶する情報記憶手段と、前記処理の実行要求が発生すると、前記情報記憶手段か
ら前記相互関係規定情報を読み出す情報読出し手段と、この情報読出し手段により読み出された相互関係規定情
報を、前記メッセージを使って前記処理実行手段に供給
する情報供給手段とを具備したことを特徴する請求項４
記載のグラフィック部品管理装置。
【請求項６】前記情報提供手段は、前記実行要求によ
って要求される処理に関連する相互関係規定情報のみを
前記処理実行手段に供給するように構成されていること
を特徴とする請求項４記載のグラフィック部品管理装
置。
【請求項７】前記処理実行手段は、前記相互関係規定情報提供手段により供給された相互関
係規定情報の中から、現在の画面の表示状態に関連する
相互関係規定情報のみを選択する情報選択手段と、この情報選択手段により選択された相互関係規定情報に
基づいて、前記複数のグラフィック部品の処理を実行す
る実行手段とを具備したことを特徴とする請求項６記載
のグラフィック部品管理装置。