JP2004310655A - ウィンドウスタック制御方法 - Google Patents
ウィンドウスタック制御方法 Download PDFInfo
- Publication number
- JP2004310655A JP2004310655A JP2003106393A JP2003106393A JP2004310655A JP 2004310655 A JP2004310655 A JP 2004310655A JP 2003106393 A JP2003106393 A JP 2003106393A JP 2003106393 A JP2003106393 A JP 2003106393A JP 2004310655 A JP2004310655 A JP 2004310655A
- Authority
- JP
- Japan
- Prior art keywords
- window
- stack
- group
- windows
- management program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 130
- 230000008569 process Effects 0.000 claims description 93
- 238000012508 change request Methods 0.000 claims description 63
- 230000004044 response Effects 0.000 claims description 12
- 230000008859 change Effects 0.000 claims description 11
- 238000010586 diagram Methods 0.000 description 47
- 238000012545 processing Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 11
- 230000006378 damage Effects 0.000 description 4
- 239000004973 liquid crystal related substance Substances 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 230000007175 bidirectional communication Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/14—Display of multiple viewports
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/451—Execution arrangements for user interfaces
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Human Computer Interaction (AREA)
- Computer Hardware Design (AREA)
- User Interface Of Digital Computer (AREA)
- Digital Computer Display Output (AREA)
Abstract
【課題】ウィンドウスタックの制御において、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事の無いウィンドウスタック制御方法を提供することを目的とする。
【解決手段】コンピュータから表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタックを制御するに際し、アプリケーションプログラムがウィンドウにグループを指定し、ウィンドウ管理プログラムがウィンドウのスタック順をグループ毎に一連とする。
【選択図】 図１
【解決手段】コンピュータから表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタックを制御するに際し、アプリケーションプログラムがウィンドウにグループを指定し、ウィンドウ管理プログラムがウィンドウのスタック順をグループ毎に一連とする。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は、コンピュータから表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法に関する。
【０００２】
【従来の技術】
近年、表示装置に複数のウィンドウを表示するコンピュータとして、ワークステーションや家庭用コンピュータが広く普及している。これらの場合、ユーザは、表示装置として比較的大きな画面に複数のウィンドウを表示して、マウスとキーボードを使ってウィンドウの重なりの上下関係であるスタック順の操作を行うのが一般的である。
【０００３】
例えば、Ｕｎｉｘ（Ｒ）ワークステーションで広く普及しているＸ１１ウィンドウシステムの場合、ウィンドウの重なりの上下関係であるスタック順は、ウィンドウの生成時にスタック最上位に位置付けられ、マップされた後は、マウスやアプリケーションの操作によって、スタック位置を上下方向に移動させる。
【０００４】
具体例として、コンピュータ上で動作する３種類のアプリケーションが合計５枚のウィンドウを表示装置であるスクリーンに表示する際の表示例となる模式図を図２８に示す。図２８において、１はＣＲＴモニタや液晶モニタで実現される表示装置のスクリーン、２及び３は第１のアプリケーションが表示するウィンドウ、４及び５は第２のアプリケーションが表示するウィンドウ、６は第３のアプリケーションが表示するウィンドウであり、第１のアプリケーションが表示するウィンドウ２及びウィンドウ３を第１のグループ、第２のアプリケーションが表示するウィンドウ４及びウィンドウ５を第２のグループ、第３のアプリケーションが表示するウィンドウ６を第３のグループとする。
【０００５】
図２８を見ればわかるように、ウィンドウ３はウィンドウ２の上に重なり、ウィンドウ５はウィンドウ４の上に重なっている。この時のウィンドウスタック順の例となる模式図を図２９に示す。図２９を見ればわかるように、ウィンドウ３はウィンドウ２よりスタック上位にあるので、両者が表示上で重なる場合は、ウィンドウ３がウィンドウ２の上に重なる事となり、同様に、ウィンドウ５はウィンドウ４よりスタック上位にあるので、両者が表示上で重なる場合は、ウィンドウ５がウィンドウ４の上に重なって表示される。
【０００６】
そして、このような表示状態、スタック順状態で、第１のアプリケーションが何らかの都合で、例えば、ウィンドウ２をウィンドウ３の前面に表示させたくなった場合、ウィンドウ２をスタック最上位に持ってくる事で対応していた。この時のスタック順の模式図を図３０に示す。図３０を見ればわかるように、ウィンドウ２はウィンドウ３よりスタック上位にあるので、両者が表示上で重なる場合は、ウィンドウ２がウィンドウ３の上に重なって表示されることとなる。また、この操作により、ウィンドウ２が、第２のグループ、第３のグループのウィンドウを跨って、スタック順で下位方向から最上位へ移動した事がわかる。
【０００７】
【特許文献１】
特開昭６２−２９８８８２号公報
【０００８】
【発明が解決しようとする課題】
しかしながら、上記従来のウィンドウスタック制御方法においては、アプリケーションが或るウィンドウに対して、ウィンドウスタック移動、ウィンドウ生成及び表示を行った場合、グループを跨ってスタック制御をするため、意図せず、該ウィンドウが他のアプリケーションの表示するウィンドウの上に重なることがあるという問題があった。
【０００９】
上記課題に鑑み、本発明は、ウィンドウスタックの制御方法において、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事の無いウィンドウスタック制御方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
この課題を解決するために本発明は、表示装置を含むコンピュータにおいて、前記表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法であって、アプリケーションプログラムがウィンドウにグループを指定し、ウィンドウ管理プログラムがウィンドウのスタック順をグループ毎に一連とする。
【００１１】
これにより、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられて表示される事は無くなり、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事を無くす事ができる。
【００１２】
【発明の実施の形態】
本発明の第１の発明は、表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法であって、１つ以上のウィンドウを前記表示装置に表示する１つ以上のアプリケーションプログラムと、前記１つ以上のアプリケーションプログラムが表示するウィンドウの重ね合わせを管理するウィンドウ管理プログラムとを備え、前記アプリケーションプログラムが前記ウィンドウ管理プログラムに対してウィンドウのグループを指定し、前記ウィンドウ管理プログラムが、前記アプリケーションプログラムからウィンドウの表示要求を受け、該ウィンドウの表示を行う際に、該ウィンドウのスタック順をグループ毎に一連とする制御を行うことを特徴とするウィンドウスタック制御方法であり、スタック順がグループ単位で纏められるため、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられて表示される事が無い。
【００１３】
また、本発明の第２の発明は、第１の発明において、ウィンドウ管理プログラムは、グループ毎に纏めていない第１のウィンドウの表示要求をアプリケーションプログラムから受け取った際に、グループ毎に纏めていない全ウィンドウから、前記第１のウィンドウと同じグループに属する第１のウィンドウ群を、前記第１のウィンドウ群の中でのスタック順関係は保持したまま、既にグループ毎に纏められた前記第１のウィンドウと同じグループに属する第２のウィンドウ群とスタック順を一連にし表示処理を行うことを特徴とするウィンドウスタック制御方法であり、表示要求によって同一グループ内でみたスタック順が変更されることがないので、アプリケーションの同一グループ内のスタック順管理の負担が軽減される。
【００１４】
また、本発明の第３の発明は、第１の発明又は第２の発明において、ウィンドウ管理プログラムは、グループ毎に代表ウィンドウを１枚生成し、ウィンドウのスタック順をグループ毎に一連とする際に、前記ウィンドウを前記代表ウィンドウの子ウィンドウとする事を特徴とするウィンドウスタック制御方法であり、グループ単位のスタック移動やグループ単位のウィンドウの表示／非表示の切り替えを代表ウィンドウに対する制御で実施できる分、グループ内のウィンドウが多いほど、処理負荷を軽減することができるようになる。
【００１５】
また、本発明の第４の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、アプリケーションプログラムからの要求を受けて、グループ内でウィンドウスタックの最上位移動、最下位移動を行うことを特徴とするウィンドウスタック制御方法であり、スタックの操作がグループ内で閉じるので、各アプリケーションプログラムは、他のアプリケーションプログラムのウィンドウ表示を気にする事無くスタック変更を行う事ができる。
【００１６】
また、本発明の第５の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、アプリケーションプログラムからの要求を受けて、グループ単位でウィンドウスタックの最上位移動、最下位移動を行うことを特徴とするウィンドウスタック制御方法であり、ウィンドウの操作をグループ指定で実施できるので、例えば、グループをアプリケーションプログラム単位で振り分けた場合だと、そのアプリケーションに属するウィンドウのメンバーを知らなくても、スタック最前面にそのアプリケーションに属する全通常ウィンドウを移動させる事が可能となる。
【００１７】
また、本発明の第６の発明は、第４の発明又は第５の発明において、ウィンドウ管理プログラムは、第１のウィンドウ又は第１のグループに対するスタック変更要求をアプリケーションプログラムから受け取った際に、グループ毎に纏めていない全ウィンドウから、前記第１のウィンドウと同じグループ又は前記第１のグループに属する第１のウィンドウ群を、前記第１のウィンドウ群の中でのスタック順関係は保持したまま、既にグループ毎に纏められた前記第１のウィンドウと同じグループ又は前記第１のグループに属する第２のウィンドウ群とスタック順を一連にしてスタック変更を行うことを特徴とするウィンドウスタック制御方法であって、スタック変更対象となるグループに属する通常ウィンドウ全てを、その中でのスタック順は保持したままで纏めた上でスタック変更を実施するので、アプリケーションプログラムは、自グループのウィンドウのスタック順を把握し易くなる。
【００１８】
また、本発明の第７の発明は、第１の発明において、ウィンドウ管理プログラムは、アプリケーションプログラムによって指定されたウィンドウをグループに属させず、グループに属して表示された全てのウィンドウより常にスタック上位に位置させることを特徴とするウィンドウスタック制御方法であって、グループ単位のスタック順に関係無くウィンドウを表示できるので、最優先で表示するウィンドウのサービスを提供することができる。
【００１９】
また、本発明の第８の発明は、第１の発明において、ウィンドウ管理プログラムは、最上位グループに属するウィンドウよりスタック下位のウィンドウを常に非表示状態とすることを特徴とするウィンドウスタック制御方法であって、最上位グループよりスタック下位のグループが何を表示しようとしても表示装置には表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。
【００２０】
また、本発明の第９の発明は、第１の発明において、ウィンドウ管理プログラムは、最上位グループに属するウィンドウの中のスタック最下位のウィンドウの直下に、特定のウィンドウを位置させることを特徴とするウィンドウスタック制御方法であって、例えば、前記特定のウィンドウを表示装置のスクリーン一杯に表示しておけば、前記特定のウィンドウのスタック下位のグループが何を表示しようとしても，表示装置に表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。
【００２１】
また、本発明の第１０の発明は、第４の発明又は第５の発明において、ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、最上位グループの直上に特定のウィンドウを位置させることを特徴とするウィンドウスタック制御方法であって、最上位グループを別のグループに入れ替える際、Ｘウィンドウシステムの場合、ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数を使用する事となるが、ウィンドウ群のスタック移動先を示すために使用できる。もし、最上位グループのウィンドウよりスタック上位にウィンドウが存在しなかった場合、存在する全てのウィンドウの並び順を決め、前記ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）の引数に代入せねばならないが、前記特定のウィンドウがあれば、前記特定のウィンドウと前記ウィンドウ群を引数に代入するだけで済む。
【００２２】
また、本発明の第１１の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、ウィンドウマネージャが、ウィンドウ破棄通知受信時に、ウィンドウシステム間とでスタック認識の整合性を確認し、異なっている場合は、ウィンドウシステムのスタック認識をウィンドウマネージャのスタック認識にあわせ込む処理を行うことを特徴とするウィンドウスタック制御方法であって、ウィンドウ破棄通知受信時に整合性確保を図るので、ウィンドウシステムがスタック変更処理に失敗しても、処理が破綻する事がなくなる。
【００２３】
また、本発明の第１２の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、ウィンドウマネージャが、ウィンドウシステムにスタック変更を要求する際にフラグを立てる一方で、ウィンドウ破棄通知受信時に、前記フラグが立っている時のみ、ウィンドウシステム間とでスタック認識の整合性を確認し、異なっている場合は、ウィンドウシステムのスタック認識をウィンドウマネージャのスタック認識にあわせ込む処理を行い、前記フラグを下げることを特徴とするウィンドウスタック制御方法であって、ウィンドウマネージャがスタック変更を実施した時のみ、スタック認識の整合性のための処理を行うので、処理の実行頻度を軽減できる。
【００２４】
以下、本発明の実施の形態について、図面を用いて説明する。
【００２５】
（実施の形態１）
本実施の形態では、ウィンドウ管理プログラムが、Ｘウィンドウシステムとウィンドウマネージャから成り、ウィンドウマネージャがルートウィンドウの子ウィンドウであるトップレベルウィンドウのスタック順を制御する場合を例にとって説明する。
【００２６】
図１に本発明の実施の形態１のウィンドウスタック制御方法を実現するシステムの構成例を示す。
【００２７】
図１において、７はコンピュータ、８はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、９は各種プログラムや処理データ等を格納するメモリ、１０は各構成要素に所望の双方向通信を行わせるバス、１１はＣＲＴモニタや液晶モニタといった表示装置、１は表示装置１１のスクリーン、１０１及び１０２，１０３はＣＰＵ８で実行され１枚以上のウィンドウをウィンドウ管理プログラム１０４を介してスクリーン１に表示しようとするアプリケーションプログラム、１０４はＣＰＵ８で実行されアプリケーションプログラムが表示しようとするウィンドウを管理してバス１０を介して表示を行うウィンドウ管理プログラムであり、ウィンドウシステム１２とウィンドウマネージャ１０５から成る、ウィンドウシステム１２は従来のＸウィンドウシステム、１０５はウィンドウマネージャである。
【００２８】
以下、図面を用いて本実施の形態の動作を説明する。
【００２９】
まず、アプリケーションプログラム１０１、１０２、１０３は、ウィンドウ管理プログラム１０４を通じて、スタック制御特性の異なる２種類のトップレベルウィンドウを表示することができるものとし、その２種類を通常ウィンドウ、優先ウィンドウと呼ぶ事とする。両者の違いは、表示された優先ウィンドウは表示された全ての通常ウィンドウより常にスタック上位に表示されることと、通常ウィンドウはグループ単位でスタック順を一連とするが優先ウィンドウでは行わないことである。
【００３０】
アプリケーションプログラム１０１、１０２、１０３は、ウィンドウを表示する場合、ウィンドウシステム１２に対して、ウィンドウ生成要求、ウィンドウ種類及びグループ設定要求、マップ要求を発行する。この内、ウィンドウ種類及びグループ設定要求については、Ｘウィンドウシステムの場合、プロパティ機構を用いる事で、ウィンドウ毎に値を設定することができる。
【００３１】
各ウィンドウは、ウィンドウ生成及びマップという過程を経て初めてスクリーン１に表示されるようになる。
【００３２】
ウィンドウシステム１２は、ウィンドウ生成要求を受け取ると、ウィンドウの重なりであるスタック順の最上位にそのウィンドウを位置させ、ウィンドウマネージャ１０５に対してウィンドウ生成通知イベント（ＣｒｅａｔｅＮｏｔｉｆｙ）を発行する。
【００３３】
ウィンドウマネージャ１０５は、内部データベースとして、ウィンドウ毎にウィンドウ情報を保持する。
【００３４】
（表１）にウィンドウ情報の一例を示す。
【００３５】
【表１】
【００３６】
表１に示されるように、ウィンドウ情報は、ウィンドウ識別子、スタック位置確定フラグ、スタック位置情報、プロパティ獲得フラグ、ウィンドウ種類、グループ値から成る。ウィンドウ識別子は、そのウィンドウ情報がどのウィンドウの情報かを示し、スタック位置確定フラグは、そのウィンドウが、ウィンドウマネージャにとって、スタック位置が暫定か確定済みなのかを示し、スタック位置情報は、そのウィンドウのスタック位置を示し、プロパティ獲得フラグは、そのウィンドウのウィンドウ種類とグループ値をウィンドウマネージャが獲得済みかどうかを示し、ウィンドウ種類は、前記プロパティ獲得フラグが獲得済みとなっている場合は、そのウィンドウが優先ウィンドウか通常ウィンドウのどちらであるかを示し、グループ値は、前記プロパティ獲得フラグが獲得済みとなっている場合は、そのウィンドウのグループ値を示す。
【００３７】
図１のウィンドウマネージャ１０５は、ウィンドウ生成通知イベント（ＣｒｅａｔｅＮｏｔｉｆｙ）を受け取ることで、新規にウィンドウが生成された事を知り、そのウィンドウ生成通知イベント（ＣｒｅａｔｅＮｏｔｉｆｙ）からウィンドウ識別子を獲得し、内部データベースに新規にウィンドウ情報格納領域を設け、そのウィンドウ情報のウィンドウ識別子に格納し、また、同ウィンドウのスタック位置確定フラグを暫定に、スタック位置情報をスタック最上位に、プロパティ獲得フラグを未獲得に、各々初期化する。
【００３８】
次に、ウィンドウシステム１２は、ウィンドウ種類及びグループ設定要求を受け取り、該ウィンドウのプロパティとして記憶する。
【００３９】
次に、ウィンドウシステム１２は、アプリケーションプログラム１０１や１０２、１０３からマップ要求を受け取り、内部処理は特にせずに、ウィンドウマネージャ１０５にマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を発行する。
【００４０】
マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図２に示す。
【００４１】
図２に示されるように、Ｓ２０１では、該時点で受け取ったマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）からマップ対象ウィンドウの識別子を獲得して、Ｓ２０２に進む。
【００４２】
Ｓ２０２では、マップ対象ウィンドウの識別子で内部データベースを検索し、対応するウィンドウ情報が存在する場合はＳ２０３へ進み、存在しない場合はＳ２１４へ進む。
【００４３】
Ｓ２０３では、内部データベースで対象ウィンドウのスタック位置確定フラグが確定済みかどうかをチェックし、確定済みの場合はＳ２１３に進み、暫定の場合はＳ２０４に進む。
【００４４】
Ｓ２０４では、対象ウィンドウのプロパティ獲得フラグをチェックし、獲得済みの場合はＳ２０６に進み、未獲得の場合はＳ２０５に進む。
【００４５】
Ｓ２０５では、対象ウィンドウのウィンドウ種類及びグループ値をウィンドウシステムに問い合わせて獲得し、内部データベースに格納し、Ｓ２０６に進む。
【００４６】
Ｓ２０６では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウの場合は、Ｓ２１３に進み、通常ウィンドウの場合は、Ｓ２０７に進む。
【００４７】
Ｓ２０７では、内部データベースに、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウがあるかどうかをチェックし、有る場合はＳ２０８進み、無い場合はＳ２０９に進む。
【００４８】
Ｓ２０８では、対象ウィンドウが、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウの内のスタック最上位のウィンドウの直上となるようウィンドウシステム１２にスタック変更要求を発行する。
【００４９】
Ｓ２０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図３に示す。
【００５０】
図３に示されるように、通常ウィンドウである対象ウィンドウが、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが確定済みのウィンドウの内のスタック最上位のウィンドウの直上に移されているのが解る。 Ｓ２０９では、内部データベースから、通常ウィンドウ全体を対象にスタック位置確定フラグが確定済みのウィンドウを検索し、存在する場合はＳ２１０に進み、存在しない場合はＳ２１１に進む。
【００５１】
Ｓ２１０では、内部データベースにあるスタック位置確定フラグが確定済みの通常ウィンドウのうち、スタック位置が最上位のウィンドウの直上に対象ウィンドウが位置するよう、ウィンドウシステム１２に対してスタック変更要求を発行し、Ｓ２１２に進む。
【００５２】
Ｓ２１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図４に示す。
図４に示されるように、通常ウィンドウである対象ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体の内のスタック最上位のウィンドウの直上に移されているのが解る。
【００５３】
Ｓ２１１では、スタック位置の最下位に対象ウィンドウが位置するよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１２に進む。
【００５４】
Ｓ２１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図５に示す。
図５に示されるように、通常ウィンドウである対象ウィンドウが、スタック最下位に移されているのが解る。
【００５５】
Ｓ２１２では、ウィンドウシステム１２に対してマップ対象ウィンドウのマップ要求を発行し、内部データベースの対象ウィンドウのウィンドウ情報の内、スタック位置確定フラグが暫定を示している場合は確定済みに更新し、また、内部データベース全体に対して必要に応じてスタック位置情報を更新した上で、Ｓ２１３に進む。
【００５６】
Ｓ２１３では、処理を終了する。
【００５７】
ウィンドウシステム１２は、図２のＳ２０８やＳ２１０、Ｓ２１１に起因するスタック変更要求をウィンドウマネージャ１０５から受け取り、要求に従ってウィンドウのスタック順を変更する。また、図２のＳ２１２に起因するマップ要求をウィンドウマネージャ１０５から受け取り、要求に従ってウィンドウのマップする。マップされたウィンドウは、ウィンドウの重なり具合にもよるが、他のウィンドウの下に隠れていなければ、スクリーン１に表示されるようになる。
【００５８】
図２の処理によって、アプリケーション１０１、１０２、１０３が生成及びウィンドウ種類及びグループ設定した通常ウィンドウは、表示までに必ず、スタック位置情報が確定済みとなり、また、スタック位置がグループ毎に纏められ、また、優先ウィンドウのスタック上位に表示される事もない。また、優先ウィンドウは、スタック位置が変更されることなく表示される。
【００５９】
図１において、アプリケーションプログラム１０１、１０２、１０３は、生成及びウィンドウ種類及びグループ設定した通常ウィンドウに対して、スタック変更要求として、グループ内スタック最上位移動をウィンドウシステム１２に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、グループ内スタック最上位移動要求にＸＲａｉｓｅＷｉｎｄｏｗ（）関数を割り当てれば良い。また、優先ウィンドウに対して、スタック変更要求として、優先ウィンドウスタック最上位移動要求をウィンドウシステム１２に対して発行する事ができ、例えば、グループ内スタック最上位移動要求と同じＸＲａｉｓｅＷｉｎｄｏｗ（）関数を割り当てる。
【００６０】
アプリケーションプログラムがＸＲａｉｓｅＷｉｎｄｏｗ（）を実施した場合、ウィンドウシステム１２はスタック変更をせず、ウィンドウマネージャ１０５に対してスタック最上位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）を発行する。
【００６１】
スタック最上位移動要求イベントを受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図６に示す。
【００６２】
図６に示されるように、Ｓ６０１では、該時点で受け取ったスタック最上位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）から対象ウィンドウの識別子を獲得して、Ｓ６０２に進む。
【００６３】
Ｓ６０２では、対象ウィンドウの識別子で内部データベースを検索し、対応するデータが存在する場合はＳ６０３へ進み、存在しない場合はＳ６１２へ進む。
【００６４】
Ｓ６０３では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ６０４に進む。
【００６５】
Ｓ６０４では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウであればＳ６０５に進み、通常ウィンドウであればＳ６０６に進む。
【００６６】
Ｓ６０５では、内部データベースからウィンドウ種類が優先ウィンドウであるものの内、スタック最上位のウィンドウを検索し、そのウィンドウが対象ウィンドウ自身であれば、何もせずＳ６１２に進み、そのウィンドウが対象ウィンドウ自身でなければ、そのウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１２に進む。
【００６７】
Ｓ６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図７に示す。
【００６８】
図７に示されるように、対象ウィンドウのみが優先ウィンドウの中のスタック最上位のウィンドウの直上に移されているのが解る。
Ｓ６０６では、対象ウィンドウと同じグループに属する通常ウィンドウを内部データベースから検索してリストアップし、Ｓ６０７に進む。
【００６９】
Ｓ６０７では、前記リストアップした中にスタック位置確定フラグが確定済みであるウィンドウが存在するならばＳ６０８に進み、存在しないならＳ６０９に進む。
【００７０】
Ｓ６０８では、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば、それら全てを、それらの中でみたスタック順はそのままで、リストアップした中でスタック位置確定フラグが確定済みであるウィンドウの内の最上位のウィンドウの直上に位置させ、更に対象ウィンドウをリストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１０に進む。 Ｓ６０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図８に示す。
【００７１】
図８に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定のウィンドウが、同じグループ値を持つスタック位置確定フラグが確定済みのウィンドウの直上に移され、同一グループ値を持つウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００７２】
図６において、Ｓ６０９では、内部データベースにスタック位置確定フラグが確定済みのウィンドウが存在するならばＳ６１０に進み、存在しないならばＳ６１１に進む。
【００７３】
Ｓ６１０では、Ｓ６０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済みであるスタック最上位の通常ウィンドウの直上に位置させ、更に対象ウィンドウを前記リストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１２に進む。
【００７４】
Ｓ６１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図９に示す。
【００７５】
図９に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体のスタック最上位ウィンドウの直上に移され、同一グループ値を持つウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００７６】
図６において、Ｓ６１１では、Ｓ６０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、全体スタックの最下位とし、更に対象ウィンドウをリストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１２に進む。
【００７７】
Ｓ６１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１０に示す。
【００７８】
図１０に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック最下位に移され、同一グループ値を持つ通常ウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００７９】
図６において、Ｓ６１２では、処理を終了する。
【００８０】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成及びウィンドウ種類及びグループ設定したウィンドウに対して、グループ内スタック最下位移動をウィンドウシステム１２に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、グループ内スタック最下位移動にＸＬｏｗｅｒＷｉｎｄｏｗ（）関数を割り当てれば良い。また、優先ウィンドウに対して、スタック変更要求として、優先ウィンドウスタック最下位移動要求をウィンドウシステム１２に対して発行する事ができ、例えば、グループ内スタック最下位移動要求と同じＸＬｏｗｅｒＷｉｎｄｏｗ（）関数を割り当てる。
【００８１】
アプリケーションプログラムがＸＬｏｗｅｒＷｉｎｄｏｗ（）を実施した場合、ウィンドウシステム１２はスタック変更をせず、ウィンドウマネージャ１０５に対してスタック最下位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）を発行する。スタック最下位移動要求イベントを受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図１１に示す。
【００８２】
図１１に示されるように、Ｓ１１０１では、該時点で受け取ったスタック最下位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）から対象ウィンドウの識別子を獲得して、Ｓ１１０２に進む。
【００８３】
Ｓ１１０２では、対象ウィンドウの識別子で内部データベースを検索し、対応するデータが存在する場合はＳ１１０３へ進み、存在しない場合はＳ１１１２へ進む。
【００８４】
Ｓ１１０３では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ１１０４に進む。
【００８５】
Ｓ１１０４では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウの場合はＳ１１０５へ進み、通常ウィンドウの場合はＳ１１０６へ進む。
【００８６】
Ｓ１１０５では、内部データベースからウィンドウ種類が優先ウィンドウであるものの内、スタック最下位のウィンドウを検索し、そのウィンドウが対象ウィンドウ自身であれば、何もせずＳ１１１２へ進み、そのウィンドウが対象ウィンドウ自身でなければ、そのウィンドウの直下となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００８７】
Ｓ１１０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１２に示す。
【００８８】
図１２に示されるように、対象ウィンドウのみが優先ウィンドウの中のスタック最下位のウィンドウの直下に移されているのが解る。
【００８９】
図１１において、Ｓ１１０６では、対象ウィンドウと同じグループに属する通常ウィンドウを内部データベースから検索してリストアップし、Ｓ１１０７に進む。
【００９０】
Ｓ１１０７では、前記リストアップした中にスタック位置確定フラグが確定済みであるウィンドウが存在するならばＳ１１０８に進み、存在しないならＳ１１０９に進む。
【００９１】
Ｓ１１０８では、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば、それら全てを、それらの中でみたスタック順はそのままで、リストアップした中でスタック位置確定フラグが確定済みであるウィンドウの内の最上位のウィンドウの直上に位置させ、更に対象ウィンドウをリストアップしたウィンドウの中で最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００９２】
Ｓ１１０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１３に示す。図１３に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、同じグループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウの直上に移され、同一グループ値を持つ通常ウィンドウ全体の中で対象ウィンドウのスタック最下位移動がなされているのが解る。
【００９３】
図１１において、Ｓ１１０９では、内部データベースにスタック位置確定フラグが確定済みの通常ウィンドウが存在するならばＳ１１１０に進み、存在しないならばＳ１１１１に進む。
【００９４】
Ｓ１１１０では、Ｓ１１０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済みであるスタック最上位の通常ウィンドウの直上に位置させ、更に対象ウィンドウを前記リストアップしたウィンドウの中で最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００９５】
Ｓ１１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１４に示す。
【００９６】
図１４に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体のスタック最上位ウィンドウの直上に移され、同一グループ値を持つウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００９７】
図１１において、Ｓ１１１１では、Ｓ１１０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、全体スタックの最下位とし、更に対象ウィンドウをリストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００９８】
Ｓ１１１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１５に示す。
【００９９】
図１５に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック最下位に移され、同一グループ値を持つ通常ウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【０１００】
図１１において、Ｓ１１１２では、処理を終了する。
【０１０１】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成及びウィンドウ種類及びグループ設定した通常ウィンドウに対して、グループ単位スタック最上位移動をウィンドウマネージャ１０５に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、クライアントメッセージ機構を利用する事で容易に実現できる。今後、クライアントメッセージでウィンドウマネージャ１０５に対して発行するグループ単位スタック最上位移動要求のメッセージの事をグループ単位スタック最上位移動要求メッセージと呼ぶ事とする。そして、このグループ単位スタック最上位移動要求メッセージには、移動したいグループ値が含まれているものとする。
【０１０２】
アプリケーションプログラムがグループ単位スタック最上位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）を発行した場合、ウィンドウシステム１２経由でウィンドウマネージャ１０５に転送される。 グループ単位スタック最上位移動要求メッセージを受け取った際のウィンドウマネージャ１０５の動作例となるフローを図１６に示す。
【０１０３】
図１６に示されるように、Ｓ１６０１では、該時点で受け取ったグループ単位スタック最上位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）から対象グループ値を獲得して、Ｓ１６０２に進む。
【０１０４】
Ｓ１６０２では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ１６０３に進む。
【０１０５】
Ｓ１６０３では、対象グループ値を持つ通常ウィンドウ情報を内部データベースから検索してリストアップし、Ｓ１６０４に進む。
【０１０６】
Ｓ１６０４では、内部データベースにスタック位置確定情報が確定済み且つグループ値情報が対象グループ値とは異なる通常ウィンドウが存在すればＳ１６０５に進み、存在しなければＳ１６０６に進む。
【０１０７】
Ｓ１６０５では、リストアップした中でのスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済み且つグループ値情報が対象グループ値とは異なる通常ウィンドウの内でスタック最上位のウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１６０７に進む。
【０１０８】
Ｓ１６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１７に示す。
【０１０９】
図１７に示されるように、対象グループ値を持つ通常ウィンドウが、スタック位置確定フラグが確定済み且つグループ値情報が対象グループ値とは異なる通常ウィンドウ全体のスタック最上位ウィンドウの直上に移されているのが解る。
【０１１０】
図１６におけるＳ１６０６では、リストアップした中でのスタック順はそのままで、全体スタックの最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１６０７に進む。
Ｓ１６０６のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１８に示す。
【０１１１】
図１８に示されるように、対象グループ値を持つ通常ウィンドウが、全体スタックの最下位に移されているのが解る。
【０１１２】
図１６において、Ｓ１６０７では、処理を終了する。
【０１１３】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成及びウィンドウ種類及びグループ設定した通常ウィンドウに対して、グループ単位スタック最下位移動をウィンドウマネージャ１０５に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、クライアントメッセージ機構を利用する事で容易に実現できる。今後、クライアントメッセージでウィンドウマネージャ１０５に対して発行するグループ単位スタック最下位移動要求のメッセージの事をグループ単位スタック最下位移動要求メッセージと呼ぶ事とする。そして、このグループ単位スタック最下位移動要求メッセージには、移動したいグループ値が含まれているものとする。
【０１１４】
アプリケーションプログラムがグループ単位スタック最下位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）を発行した場合、ウィンドウシステム１２経由でウィンドウマネージャ１０５に転送される。
【０１１５】
グループ単位スタック最下位移動要求メッセージを受け取った際のウィンドウマネージャ１０５の動作例となるフローを図１９に示す。
【０１１６】
図１９に示されるように、Ｓ１９０１では、該時点で受け取ったグループ単位スタック最下位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）から対象グループ値を獲得して、Ｓ１９０２に進む。
【０１１７】
Ｓ１９０２では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ１９０３に進む。
【０１１８】
Ｓ１９０３では、対象グループ値を持つ通常ウィンドウを内部データベースから検索してリストアップし、Ｓ１９０４に進む。
【０１１９】
Ｓ１９０４では、リストアップした中でのスタック順はそのままで、全体スタックの最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１９０５に進む。
【０１２０】
Ｓ１９０４のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２０に示す。
【０１２１】
図２０に示されるように、対象グループ値を持つ通常ウィンドウが、全体スタックの最下位に移されているのが解る。
【０１２２】
図１９におけるＳ１９０５では、処理を終了する。
【０１２３】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成したウィンドウに対して破棄要求を発行する。
【０１２４】
ウィンドウシステム１２は、破棄要求を受け取ると、該当するウィンドウを管理から外して削除する。そして、ウィンドウマネージャ１０５にウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を発行する。
【０１２５】
ウィンドウマネージャ１０５は、ウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を受け取ると、そこからウィンドウ識別子を抽出して、該当するウィンドウ情報を内部データベースから検索し削除した後、内部データベース全体に対して必要に応じてスタック位置を更新し、処理を終了する。
【０１２６】
以上のことにより、各通常ウィンドウはそのウィンドウの表示までに、ウィンドウのスタック順がグループ毎に纏められるので、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられて表示される事が無くなる。また、ウィンドウ管理プログラムが、スタック変更要求を受け取る事を切っ掛けにして、スタック変更対象となるグループに属する通常ウィンドウ全てを、その中でのスタック順は保持したままで纏めた上でスタック変更を実施するので、アプリケーションプログラムは、自グループのウィンドウのスタック順を把握し易くなる。また、ウィンドウ管理プログラムにグループ内のスタック最上位移動とグループ内のスタック最下位移動の機能を設ける事で、グループ内で通常ウィンドウのスタック順を操作できるので、各アプリケーションプログラムは、他のアプリケーションプログラムの通常ウィンドウ表示を気にする事無く、スタック変更を行う事ができる。また、ウィンドウ管理プログラムにグループ単位のスタック最上位移動と最下位移動の機能を設ける事で、例えば、グループをアプリケーションプログラム単位で振り分けた場合だと、そのアプリケーションに属するウィンドウのメンバーを知らなくても、スタック最前面にそのアプリケーションに属する全通常ウィンドウを移動させる事が可能となる。また、優先ウィンドウを設ける事で、グループ単位のスタック順に関係無く、最優先で表示するウィンドウのサービスを提供することができる。
【０１２７】
なお、本実施の形態では、ウィンドウマネージャのウィンドウのウィンドウ種類及びグループ値取得のタイミングをマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）受信時及びスタック変更要求受信時としたが、これに限定されるものではなく、アプリケーションプログラムがウィンドウ種類及びグループ設定をしたタイミングで取得して内部データベースに記憶しておいても良く、その方がむしろ処理効率が良い。更に、このタイミングで、スタック順をグループ毎に纏めても構わない。また、ウィンドウ種類及びグループ値の変更を認めても良いし、認めなくても良い。認める場合は、ウィンドウ種類及びグループ設定のタイミングで、ウィンドウ種類が優先ウィンドウから通常ウィンドウに変更された場合は、スタック位置確定フラグを暫定に変更する。逆にウィンドウ種類が通常ウィンドウから優先ウィンドウに変更された場合は、該時点のスタック最上位に該ウィンドウを位置させるようにスタック変更を行う。また、ウィンドウ種類に変更が無く、グループ値が変更となった場合は、スタック位置確定フラグを暫定に変更する。そして、内部データベースを更新すれ場良い。また、認めない場合は、ウィンドウ種類及びグループ設定のタイミングで、プロパティ獲得フラグをチェックして、獲得済みであれば、該設定を無視すれば良い。
【０１２８】
また、ウィンドウ種類として優先ウィンドウと通常ウィンドウの２種類を制御する例を示したが、通常ウィンドウの１種類だけであっても容易に実施できる事は言うまでも無い。
【０１２９】
また、ウィンドウマネージャがルートウィンドウの子ウィンドウであるトップレベルウィンドウのスタック順を制御する場合を例に示したが、トップレベルウィンドウの子孫ウィンドウに対しても実施する事ができる事は言うまでも無い。
【０１３０】
また、ウィンドウ管理プログラムをＸウィンドウシステムとウィンドウマネージャとして、アプリケーションプログラムとのインターフェースにウィンドウ生成要求、マップ要求を用いたが、これに限定されるものではなく、表示要求に相当するインターフェースさえあれば良く、その場合、ウィンドウ管理プログラムは、ウィンドウ表示要求受信時に、本実施の形態で示したウィンドウ生成要求受信時の処理とマップ要求受信時の処理を纏めて行えば良い。
【０１３１】
また、ウィンドウのスタック順をグループ毎に一連とする際、単にウィンドウのスタック順を変更するだけであったが、例えば、ウィンドウ管理プログラムが、グループ毎に代表ウィンドウを１枚生成し、ウィンドウのスタック順をグループ毎に一連とする際に、前記ウィンドウを前記代表ウィンドウの子ウィンドウとするようにして制御することも容易である。そうすることによって、グループ単位のスタック移動やグループ単位のウィンドウの表示／非表示の切り替えを代表ウィンドウに対する制御で実施できる分、グループ内のウィンドウが多いほど、処理負荷を軽減することができる。代表ウィンドウ使用下でのスタックの様子を示す例となる模式図を図２５に示す。
【０１３２】
また、最上位グループよりスタック下位のウィンドウ表示について、ウィンドウ管理プログラムでは非表示とするような制御はしていないが、非表示とする制御を行う事も容易に実現できる。その場合、ウィンドウ情報に表示／非表示を示すマップフラグを追加して、アプリケーションプログラムの表示要求状態を記憶しておき、該ウィンドウの所属するグループが通常ウィンドウの中でスタック最上位となった時、前記マップフラグをチェックし、表示となっていればマップ処理を行い、非表示となっていればアンマップのままとする。逆に、該ウィンドウの所属するグループが通常ウィンドウの中でスタック最上位でなくなった際には、前記マップフラグが表示となっていればアンマップ処理を行い、非表示となっていれば何もしない。これにより、通常ウィンドウの中の最上位グループよりスタック下位のグループが何を表示しようとしても，表示装置に表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。
【０１３３】
また、通常ウィンドウの最上位グループに属する全ウィンドウの中のスタック最下位のウィンドウの直下に、ウィンドウ管理プログラムが生成及びマップする特定のウィンドウを位置させなかったが、位置させることも容易に実現できる。これにより、例えば、前記特定のウィンドウを表示装置のスクリーン一杯に表示しておけば、前記特定のウィンドウのスタック下位のグループが何を表示しようとしても，表示装置に表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。前記特定のウィンドウを使用した場合のスタックの様子を示す例となる模式図を図２６に示し、また、スクリーンに表示されている例となる模式図を図２７に示す。
【０１３４】
また、アプリケーションプログラムが３つの場合を例に示したが、これに限定されるものではなく、１つ以上であれば良い。
【０１３５】
また、各アプリケーションプログラムに１つのグループを割り当てた場合を例に示したが、これに限定されるものではなく、１つのアプリケーションに複数のグループを割り当てても良く、また、複数のアプリケーションに１つのグループを割り当てても構わない。
【０１３６】
また、ウィンドウ管理プログラムをＸウィンドウシステムとウィンドウマネージャとして、両者間でイベントや各種要求を送受信し合う例を示したが、これに限定されるものではなく、Ｘウィンドウシステムである必要は無いし、また、２つに分けてイベントや各種要求を送受信する構成である必要もなく、一体化して実施する場合は、イベントやメッセージのインターフェースを関数ベースに変える事で本実施の形態を容易に応用できる。
【０１３７】
また、通常ウィンドウの最上位グループに属する全ウィンドウの中のスタック最上位のウィンドウの直上に、ウィンドウ管理プログラムが生成する特定のウィンドウを位置させなかったが、位置させることも容易に実現できる。これにより、最上位グループを別のグループに入れ替える際、Ｘウィンドウシステムの場合、ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数を使用する事となるが、ウィンドウ群のスタック移動先を示すために使用できる。もし、最上位グループのウィンドウよりスタック上位にウィンドウが存在しなかった場合、存在する全てのウィンドウの並び順を決め、前記ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）の引数に代入せねばならないが、前記特定のウィンドウがあれば、前記特定のウィンドウと前記ウィンドウ群を引数に代入するだけで済む。
【０１３８】
また、Ｘウィンドウシステムを用いる場合、ウィンドウマネージャは、スタックを操作するためにＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数を使用する。ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数の引数には、ウィンドウ群とそのウィンドウ群の移動先を示すウィンドウを指定するが、それらの何れかが破棄されていた場合、スタック操作が意図した通りに実施されない事がある。そのための対策として、例えば、ウィンドウマネージャは、ウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を受け取った際に、該当するウィンドウ情報を内部データベースから検索し削除し、内部データベース全体に対して必要に応じてスタック位置を更新した後、次に、ウィンドウシステムの該時点でのスタックツリーを問い合わせて獲得し、ウィンドウマネージャが認識していない新規のウィンドウは対象から外し、ウィンドウマネージャのスタックツリーとの整合性をチェックし、ウィンドウマネージャの認識と異なっている場合は、ウィンドウマネージャのスタックツリーに合わせ込むスタック変更要求を発行し、認識が合うまで、ウィンドウシステムの該時点でのスタックツリー問い合わせ、整合性チェック、スタック変更要求の発行を繰り返すようにしても良い。これにより、ウィンドウシステムがスタック変更処理に失敗しても、ウィンドウシステム間とのスタック認識の整合性を確保でき、処理が破綻する事がなくなる。
【０１３９】
また、ウィンドウマネージャが、ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）を実行した際にフラグを立て、ウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を受け取った際に、前記フラグが立っている場合にのみ、前記フラグを下げると共にスタックツリーの整合性のための処理を行うようにしても良い。これにより、スタックツリーの整合性のための処理の実行頻度を軽減できる。
【０１４０】
また、コンピュータ１とは、家庭用コンピュータや携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）、セットトップボックス、デジタルスチルカメラ、カメラ一体型ＶＴＲ等、プログラムが動作するためのＣＰＵとメモリを実装して表示装置に複数のウィンドウを表示しようとする装置であれば何でも良い事は言うまでもない。
【０１４１】
また、表示装置１１をコンピュータ１の一部としたが、物理上で一体化している事を指すものではなく、コンピュータ１と有線／無線を問わず、何らかの形で接続されていさえすれば良い。
【０１４２】
また、本実施の形態のウィンドウスタック制御方法を内臓するプログラムは、ＲＯＭやディスク等に記憶して供給する事ができるほか、ネットワークを介して供給する事が可能である事は言うまでもない。
【０１４３】
（実施の形態２）
本実施の形態のウィンドウスタック制御方法は、実施の形態１を変形したものであり、実施の形態１と実施の形態２の違いは、マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作と、アプリケーションプログラムがウィンドウ種類及びグループ値を設定するタイミングでウィンドウマネージャ１０５はスタック順をグループ毎に纏めてはいけないことだけである。よって、本実施例では、ウィンドウマネージャ１０５のマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作についてのみ説明する。
【０１４４】
マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図２１に示す。
【０１４５】
図２１に示されるように、Ｓ２１０１では、該時点で受け取ったマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）からマップ対象ウィンドウの識別子を獲得して、Ｓ２１０２に進む。
【０１４６】
Ｓ２１０２では、マップ対象ウィンドウの識別子で内部データベースを検索し、対応するウィンドウ情報が存在する場合はＳ２１０３へ進み、存在しない場合はＳ２１１５へ進む。
【０１４７】
Ｓ２１０３では、内部データベースで対象ウィンドウのスタック位置確定フラグが確定済みかどうかをチェックし、確定済みの場合はＳ２１１４に進み、暫定の場合はＳ２１０４に進む。
【０１４８】
Ｓ２１０４では、対象ウィンドウのプロパティ獲得フラグをチェックし、獲得済みの場合はＳ２１０６に進み、未獲得の場合はＳ２１０５に進む。
【０１４９】
Ｓ２１０５では、対象ウィンドウのウィンドウ種類及びグループ値をウィンドウシステムに問い合わせて獲得し、内部データベースに格納し、Ｓ２１０６に進む。
【０１５０】
Ｓ２１０６では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウの場合は、Ｓ２１１４に進み、通常ウィンドウの場合は、Ｓ２１０７に進む。
【０１５１】
Ｓ２１０７では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ２１０８に進む。
【０１５２】
Ｓ２１０８では、対象ウィンドウと同じグループに属する通常ウィンドウを内部データベースから検索してリストアップし、Ｓ２１０９に進む。 Ｓ２１０９では、前記リストアップした中にスタック位置確定フラグが確定済みであるウィンドウが存在するならばＳ２１１０に進み、存在しないならＳ２１１１に進む。
【０１５３】
Ｓ２１１０では、リストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、リストアップした中でスタック位置確定フラグが確定済みであるウィンドウの内の最上位のウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１１４に進む。 Ｓ２１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２２に示す。
【０１５４】
図２２に示されるように、マップ対象ウィンドウ及びマップ対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、前記グループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウの直上に移されているのが解かる。
【０１５５】
図２１において、Ｓ２１１１では、内部データベースにスタック位置確定フラグが確定済みの通常ウィンドウが存在するならばＳ２１１２に進み、存在しないならばＳ２１１３に進む。
【０１５６】
Ｓ２１１２では、Ｓ２１０８でリストアップした中でスタック位置確定フラグが暫定である通常ウィンドウ全てを、それらの中でみたスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済みであるスタック最上位の通常ウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１１４に進む。
【０１５７】
Ｓ２１１２のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２３に示す。 図２３に示されるように、マップ対象ウィンドウ及びマップ対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体のスタック最上位ウィンドウの直上に移されているのが解る。
【０１５８】
図２１において、Ｓ２１１３では、Ｓ２１０８でリストアップした中でスタック位置確定フラグが暫定である通常ウィンドウ全てを、それらの中でみたスタック順はそのままで、全体スタックの最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１１４に進む。
【０１５９】
Ｓ２１１３のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２４に示す。
【０１６０】
図２４に示されるように、マップ対象ウィンドウ及びマップ対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック最下位に移されているのが解る。
【０１６１】
図２１において、Ｓ２１１４では、ウィンドウシステム１２に対してマップ対象ウィンドウのマップ要求を発行し、内部データベースの対象ウィンドウのウィンドウ情報の内、スタック位置確定フラグが未確定を示している場合は確定済みに更新し、また、内部データベース全体に対して必要に応じてスタック位置を更新した上で、Ｓ２１１５に進む。
【０１６２】
Ｓ２１１５では、処理を終了する。
【０１６３】
以上のことにより、ウィンドウ管理プログラムが、マップ対象ウィンドウと同じグループ値を持つスタック位置が暫定の通常ウィンドウ群を、その通常ウィンドウ群の中でのスタック上下関係は保持しつつスタック位置を移してグループ毎に纏めるため、マップによって、同一グループ内でみたスタック順は変更されず、アプリケーションの同一グループ内のスタック順管理の負担が軽減される。更に、実施の形態１で示したように、スタック変更要求受信時にも、対象ウィンドウと同じグループ値を持つスタック位置が暫定の通常ウィンドウ群を、その通常ウィンドウ群の中でのスタック上下関係は保持しつつグループ毎に纏める事で、アプリケーションプログラムは、自グループに属するウィンドウのスタック順をウィンドウの生成順を基本として管理する事ができる。これは、Ｘウィンドウシステムの基本と一致しており、アプリケーションプログラムは、自グループの通常ウィンドウについて、一般的なスタック順決定ルールである生成順ベースで重なりを管理すれば良くなる。
【０１６４】
なお、本実施の形態では、マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）受信時に、ウィンドウマネージャのウィンドウのグループ値取得を行っているが、これに限定されるものではなく、実施の形態１と同様、アプリケーションプログラムがウィンドウ種類及びグループ設定をしたタイミングでグループ値を取得して内部データベースにウィンドウ種類とグループ値とプロパティ獲得済みである事を記憶しておいても良く、その方がむしろ処理効率が良い。しかし、実施の形態１と違い、前記タイミングで、スタック順をグループ毎に纏めてはいけない。
【０１６５】
【発明の効果】
以上のように本発明によれば、ウィンドウ制御方法において、アプリケーションプログラムがウィンドウにグループを指定し、ウィンドウ管理プログラムがウィンドウのスタック順をグループ毎に一連とすることにより、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられる事が無くなり、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事を無くす事ができる。特に、画面が小さく、結果として、ウィンドウの重なり易い携帯電話やＰＤＡ等で、その効果は顕著である。
【図面の簡単な説明】
【図１】本発明の実施の形態１のウィンドウスタック制御方法を実現するシステムの構成例を示す図
【図２】本発明実施の形態１のマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャの動作例となるフロー図
【図３】本発明の実施の形態１の図２のＳ２０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図４】本発明の実施の形態１の図２のＳ２１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図５】本発明の実施の形態１の図２のＳ２１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図６】本発明の実施の形態１のスタック最上位移動要求イベントを受け取った際のウィンドウマネージャの動作例となるフロー図
【図７】本発明の実施の形態１の図６のＳ６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図８】本発明の実施の形態１の図６のＳ６０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図９】本発明の実施の形態１の図６のＳ６１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１０】本発明の実施の形態１の図６のＳ６１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１１】本発明の実施の形態１のスタック最下位移動要求イベントを受け取った際のウィンドウマネージャの動作例となるフロー図
【図１２】本発明の実施の形態１の図１１のＳ１１０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１３】本発明の実施の形態１の図１１のＳ１１０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１４】本発明の実施の形態１の図１１のＳ１１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１５】本発明の実施の形態１の図１１のＳ１１１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１６】本発明の実施の形態１のグループ単位スタック最上位移動要求メッセージを受け取った際のウィンドウマネージャの動作例となるフロー図
【図１７】本発明の実施の形態１の図１６のＳ１６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１８】本発明の実施の形態１の図１６のＳ１６０６のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１９】本発明の実施の形態１のグループ単位スタック最下位移動要求メッセージを受け取った際のウィンドウマネージャの動作例となるフロー図
【図２０】本発明の実施の形態１の図１９のＳ１９０４のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２１】本発明の実施の形態２のマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャの動作例となるフロー図
【図２２】本発明の実施の形態２の図２１のＳ２１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２３】本発明の実施の形態２の図２１のＳ２１１２のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２４】本発明の実施の形態２の図２１のＳ２１１３のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２５】本発明の実施の形態１の代表ウィンドウ使用下でのスタックの様子を示す例となる模式図
【図２６】本発明の実施の形態１の最上位グループに属する全ウィンドウの中のスタック最下位のウィンドウの直下に、ウィンドウ管理プログラムが生成及びマップする特定のウィンドウを位置させて使用した場合のスタックの様子を示す例となる模式図
【図２７】本発明の実施の形態１の最上位グループに属する全ウィンドウの中のスタック最下位のウィンドウの直下に、ウィンドウ管理プログラムが生成及びマップする特定のウィンドウを位置させて使用した場合のスクリーンに表示されている例となる模式図
【図２８】従来例におけるコンピュータ上で動作する３種類のアプリケーションが合計５枚のウィンドウを表示装置であるスクリーンに表示する際の表示例となる模式図
【図２９】従来例におけるウィンドウスタック順の例となる模式図
【図３０】従来例におけるウィンドウスタック順の例となる模式図
【符号の説明】
１ スクリーン
７ コンピュータ
８ ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
９ メモリ
１０ バス
１１ 表示装置
１０１、１０２、１０３ アプリケーションプログラム
１０４ ウィンドウ管理プログラム
１０５ ウィンドウマネージャ
【発明の属する技術分野】
本発明は、コンピュータから表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法に関する。
【０００２】
【従来の技術】
近年、表示装置に複数のウィンドウを表示するコンピュータとして、ワークステーションや家庭用コンピュータが広く普及している。これらの場合、ユーザは、表示装置として比較的大きな画面に複数のウィンドウを表示して、マウスとキーボードを使ってウィンドウの重なりの上下関係であるスタック順の操作を行うのが一般的である。
【０００３】
例えば、Ｕｎｉｘ（Ｒ）ワークステーションで広く普及しているＸ１１ウィンドウシステムの場合、ウィンドウの重なりの上下関係であるスタック順は、ウィンドウの生成時にスタック最上位に位置付けられ、マップされた後は、マウスやアプリケーションの操作によって、スタック位置を上下方向に移動させる。
【０００４】
具体例として、コンピュータ上で動作する３種類のアプリケーションが合計５枚のウィンドウを表示装置であるスクリーンに表示する際の表示例となる模式図を図２８に示す。図２８において、１はＣＲＴモニタや液晶モニタで実現される表示装置のスクリーン、２及び３は第１のアプリケーションが表示するウィンドウ、４及び５は第２のアプリケーションが表示するウィンドウ、６は第３のアプリケーションが表示するウィンドウであり、第１のアプリケーションが表示するウィンドウ２及びウィンドウ３を第１のグループ、第２のアプリケーションが表示するウィンドウ４及びウィンドウ５を第２のグループ、第３のアプリケーションが表示するウィンドウ６を第３のグループとする。
【０００５】
図２８を見ればわかるように、ウィンドウ３はウィンドウ２の上に重なり、ウィンドウ５はウィンドウ４の上に重なっている。この時のウィンドウスタック順の例となる模式図を図２９に示す。図２９を見ればわかるように、ウィンドウ３はウィンドウ２よりスタック上位にあるので、両者が表示上で重なる場合は、ウィンドウ３がウィンドウ２の上に重なる事となり、同様に、ウィンドウ５はウィンドウ４よりスタック上位にあるので、両者が表示上で重なる場合は、ウィンドウ５がウィンドウ４の上に重なって表示される。
【０００６】
そして、このような表示状態、スタック順状態で、第１のアプリケーションが何らかの都合で、例えば、ウィンドウ２をウィンドウ３の前面に表示させたくなった場合、ウィンドウ２をスタック最上位に持ってくる事で対応していた。この時のスタック順の模式図を図３０に示す。図３０を見ればわかるように、ウィンドウ２はウィンドウ３よりスタック上位にあるので、両者が表示上で重なる場合は、ウィンドウ２がウィンドウ３の上に重なって表示されることとなる。また、この操作により、ウィンドウ２が、第２のグループ、第３のグループのウィンドウを跨って、スタック順で下位方向から最上位へ移動した事がわかる。
【０００７】
【特許文献１】
特開昭６２−２９８８８２号公報
【０００８】
【発明が解決しようとする課題】
しかしながら、上記従来のウィンドウスタック制御方法においては、アプリケーションが或るウィンドウに対して、ウィンドウスタック移動、ウィンドウ生成及び表示を行った場合、グループを跨ってスタック制御をするため、意図せず、該ウィンドウが他のアプリケーションの表示するウィンドウの上に重なることがあるという問題があった。
【０００９】
上記課題に鑑み、本発明は、ウィンドウスタックの制御方法において、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事の無いウィンドウスタック制御方法を提供することを目的とする。
【００１０】
【課題を解決するための手段】
この課題を解決するために本発明は、表示装置を含むコンピュータにおいて、前記表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法であって、アプリケーションプログラムがウィンドウにグループを指定し、ウィンドウ管理プログラムがウィンドウのスタック順をグループ毎に一連とする。
【００１１】
これにより、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられて表示される事は無くなり、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事を無くす事ができる。
【００１２】
【発明の実施の形態】
本発明の第１の発明は、表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法であって、１つ以上のウィンドウを前記表示装置に表示する１つ以上のアプリケーションプログラムと、前記１つ以上のアプリケーションプログラムが表示するウィンドウの重ね合わせを管理するウィンドウ管理プログラムとを備え、前記アプリケーションプログラムが前記ウィンドウ管理プログラムに対してウィンドウのグループを指定し、前記ウィンドウ管理プログラムが、前記アプリケーションプログラムからウィンドウの表示要求を受け、該ウィンドウの表示を行う際に、該ウィンドウのスタック順をグループ毎に一連とする制御を行うことを特徴とするウィンドウスタック制御方法であり、スタック順がグループ単位で纏められるため、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられて表示される事が無い。
【００１３】
また、本発明の第２の発明は、第１の発明において、ウィンドウ管理プログラムは、グループ毎に纏めていない第１のウィンドウの表示要求をアプリケーションプログラムから受け取った際に、グループ毎に纏めていない全ウィンドウから、前記第１のウィンドウと同じグループに属する第１のウィンドウ群を、前記第１のウィンドウ群の中でのスタック順関係は保持したまま、既にグループ毎に纏められた前記第１のウィンドウと同じグループに属する第２のウィンドウ群とスタック順を一連にし表示処理を行うことを特徴とするウィンドウスタック制御方法であり、表示要求によって同一グループ内でみたスタック順が変更されることがないので、アプリケーションの同一グループ内のスタック順管理の負担が軽減される。
【００１４】
また、本発明の第３の発明は、第１の発明又は第２の発明において、ウィンドウ管理プログラムは、グループ毎に代表ウィンドウを１枚生成し、ウィンドウのスタック順をグループ毎に一連とする際に、前記ウィンドウを前記代表ウィンドウの子ウィンドウとする事を特徴とするウィンドウスタック制御方法であり、グループ単位のスタック移動やグループ単位のウィンドウの表示／非表示の切り替えを代表ウィンドウに対する制御で実施できる分、グループ内のウィンドウが多いほど、処理負荷を軽減することができるようになる。
【００１５】
また、本発明の第４の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、アプリケーションプログラムからの要求を受けて、グループ内でウィンドウスタックの最上位移動、最下位移動を行うことを特徴とするウィンドウスタック制御方法であり、スタックの操作がグループ内で閉じるので、各アプリケーションプログラムは、他のアプリケーションプログラムのウィンドウ表示を気にする事無くスタック変更を行う事ができる。
【００１６】
また、本発明の第５の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、アプリケーションプログラムからの要求を受けて、グループ単位でウィンドウスタックの最上位移動、最下位移動を行うことを特徴とするウィンドウスタック制御方法であり、ウィンドウの操作をグループ指定で実施できるので、例えば、グループをアプリケーションプログラム単位で振り分けた場合だと、そのアプリケーションに属するウィンドウのメンバーを知らなくても、スタック最前面にそのアプリケーションに属する全通常ウィンドウを移動させる事が可能となる。
【００１７】
また、本発明の第６の発明は、第４の発明又は第５の発明において、ウィンドウ管理プログラムは、第１のウィンドウ又は第１のグループに対するスタック変更要求をアプリケーションプログラムから受け取った際に、グループ毎に纏めていない全ウィンドウから、前記第１のウィンドウと同じグループ又は前記第１のグループに属する第１のウィンドウ群を、前記第１のウィンドウ群の中でのスタック順関係は保持したまま、既にグループ毎に纏められた前記第１のウィンドウと同じグループ又は前記第１のグループに属する第２のウィンドウ群とスタック順を一連にしてスタック変更を行うことを特徴とするウィンドウスタック制御方法であって、スタック変更対象となるグループに属する通常ウィンドウ全てを、その中でのスタック順は保持したままで纏めた上でスタック変更を実施するので、アプリケーションプログラムは、自グループのウィンドウのスタック順を把握し易くなる。
【００１８】
また、本発明の第７の発明は、第１の発明において、ウィンドウ管理プログラムは、アプリケーションプログラムによって指定されたウィンドウをグループに属させず、グループに属して表示された全てのウィンドウより常にスタック上位に位置させることを特徴とするウィンドウスタック制御方法であって、グループ単位のスタック順に関係無くウィンドウを表示できるので、最優先で表示するウィンドウのサービスを提供することができる。
【００１９】
また、本発明の第８の発明は、第１の発明において、ウィンドウ管理プログラムは、最上位グループに属するウィンドウよりスタック下位のウィンドウを常に非表示状態とすることを特徴とするウィンドウスタック制御方法であって、最上位グループよりスタック下位のグループが何を表示しようとしても表示装置には表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。
【００２０】
また、本発明の第９の発明は、第１の発明において、ウィンドウ管理プログラムは、最上位グループに属するウィンドウの中のスタック最下位のウィンドウの直下に、特定のウィンドウを位置させることを特徴とするウィンドウスタック制御方法であって、例えば、前記特定のウィンドウを表示装置のスクリーン一杯に表示しておけば、前記特定のウィンドウのスタック下位のグループが何を表示しようとしても，表示装置に表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。
【００２１】
また、本発明の第１０の発明は、第４の発明又は第５の発明において、ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、最上位グループの直上に特定のウィンドウを位置させることを特徴とするウィンドウスタック制御方法であって、最上位グループを別のグループに入れ替える際、Ｘウィンドウシステムの場合、ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数を使用する事となるが、ウィンドウ群のスタック移動先を示すために使用できる。もし、最上位グループのウィンドウよりスタック上位にウィンドウが存在しなかった場合、存在する全てのウィンドウの並び順を決め、前記ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）の引数に代入せねばならないが、前記特定のウィンドウがあれば、前記特定のウィンドウと前記ウィンドウ群を引数に代入するだけで済む。
【００２２】
また、本発明の第１１の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、ウィンドウマネージャが、ウィンドウ破棄通知受信時に、ウィンドウシステム間とでスタック認識の整合性を確認し、異なっている場合は、ウィンドウシステムのスタック認識をウィンドウマネージャのスタック認識にあわせ込む処理を行うことを特徴とするウィンドウスタック制御方法であって、ウィンドウ破棄通知受信時に整合性確保を図るので、ウィンドウシステムがスタック変更処理に失敗しても、処理が破綻する事がなくなる。
【００２３】
また、本発明の第１２の発明は、第１の発明又は第２の発明又は第３の発明において、ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、ウィンドウマネージャが、ウィンドウシステムにスタック変更を要求する際にフラグを立てる一方で、ウィンドウ破棄通知受信時に、前記フラグが立っている時のみ、ウィンドウシステム間とでスタック認識の整合性を確認し、異なっている場合は、ウィンドウシステムのスタック認識をウィンドウマネージャのスタック認識にあわせ込む処理を行い、前記フラグを下げることを特徴とするウィンドウスタック制御方法であって、ウィンドウマネージャがスタック変更を実施した時のみ、スタック認識の整合性のための処理を行うので、処理の実行頻度を軽減できる。
【００２４】
以下、本発明の実施の形態について、図面を用いて説明する。
【００２５】
（実施の形態１）
本実施の形態では、ウィンドウ管理プログラムが、Ｘウィンドウシステムとウィンドウマネージャから成り、ウィンドウマネージャがルートウィンドウの子ウィンドウであるトップレベルウィンドウのスタック順を制御する場合を例にとって説明する。
【００２６】
図１に本発明の実施の形態１のウィンドウスタック制御方法を実現するシステムの構成例を示す。
【００２７】
図１において、７はコンピュータ、８はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、９は各種プログラムや処理データ等を格納するメモリ、１０は各構成要素に所望の双方向通信を行わせるバス、１１はＣＲＴモニタや液晶モニタといった表示装置、１は表示装置１１のスクリーン、１０１及び１０２，１０３はＣＰＵ８で実行され１枚以上のウィンドウをウィンドウ管理プログラム１０４を介してスクリーン１に表示しようとするアプリケーションプログラム、１０４はＣＰＵ８で実行されアプリケーションプログラムが表示しようとするウィンドウを管理してバス１０を介して表示を行うウィンドウ管理プログラムであり、ウィンドウシステム１２とウィンドウマネージャ１０５から成る、ウィンドウシステム１２は従来のＸウィンドウシステム、１０５はウィンドウマネージャである。
【００２８】
以下、図面を用いて本実施の形態の動作を説明する。
【００２９】
まず、アプリケーションプログラム１０１、１０２、１０３は、ウィンドウ管理プログラム１０４を通じて、スタック制御特性の異なる２種類のトップレベルウィンドウを表示することができるものとし、その２種類を通常ウィンドウ、優先ウィンドウと呼ぶ事とする。両者の違いは、表示された優先ウィンドウは表示された全ての通常ウィンドウより常にスタック上位に表示されることと、通常ウィンドウはグループ単位でスタック順を一連とするが優先ウィンドウでは行わないことである。
【００３０】
アプリケーションプログラム１０１、１０２、１０３は、ウィンドウを表示する場合、ウィンドウシステム１２に対して、ウィンドウ生成要求、ウィンドウ種類及びグループ設定要求、マップ要求を発行する。この内、ウィンドウ種類及びグループ設定要求については、Ｘウィンドウシステムの場合、プロパティ機構を用いる事で、ウィンドウ毎に値を設定することができる。
【００３１】
各ウィンドウは、ウィンドウ生成及びマップという過程を経て初めてスクリーン１に表示されるようになる。
【００３２】
ウィンドウシステム１２は、ウィンドウ生成要求を受け取ると、ウィンドウの重なりであるスタック順の最上位にそのウィンドウを位置させ、ウィンドウマネージャ１０５に対してウィンドウ生成通知イベント（ＣｒｅａｔｅＮｏｔｉｆｙ）を発行する。
【００３３】
ウィンドウマネージャ１０５は、内部データベースとして、ウィンドウ毎にウィンドウ情報を保持する。
【００３４】
（表１）にウィンドウ情報の一例を示す。
【００３５】
【表１】
表１に示されるように、ウィンドウ情報は、ウィンドウ識別子、スタック位置確定フラグ、スタック位置情報、プロパティ獲得フラグ、ウィンドウ種類、グループ値から成る。ウィンドウ識別子は、そのウィンドウ情報がどのウィンドウの情報かを示し、スタック位置確定フラグは、そのウィンドウが、ウィンドウマネージャにとって、スタック位置が暫定か確定済みなのかを示し、スタック位置情報は、そのウィンドウのスタック位置を示し、プロパティ獲得フラグは、そのウィンドウのウィンドウ種類とグループ値をウィンドウマネージャが獲得済みかどうかを示し、ウィンドウ種類は、前記プロパティ獲得フラグが獲得済みとなっている場合は、そのウィンドウが優先ウィンドウか通常ウィンドウのどちらであるかを示し、グループ値は、前記プロパティ獲得フラグが獲得済みとなっている場合は、そのウィンドウのグループ値を示す。
【００３７】
図１のウィンドウマネージャ１０５は、ウィンドウ生成通知イベント（ＣｒｅａｔｅＮｏｔｉｆｙ）を受け取ることで、新規にウィンドウが生成された事を知り、そのウィンドウ生成通知イベント（ＣｒｅａｔｅＮｏｔｉｆｙ）からウィンドウ識別子を獲得し、内部データベースに新規にウィンドウ情報格納領域を設け、そのウィンドウ情報のウィンドウ識別子に格納し、また、同ウィンドウのスタック位置確定フラグを暫定に、スタック位置情報をスタック最上位に、プロパティ獲得フラグを未獲得に、各々初期化する。
【００３８】
次に、ウィンドウシステム１２は、ウィンドウ種類及びグループ設定要求を受け取り、該ウィンドウのプロパティとして記憶する。
【００３９】
次に、ウィンドウシステム１２は、アプリケーションプログラム１０１や１０２、１０３からマップ要求を受け取り、内部処理は特にせずに、ウィンドウマネージャ１０５にマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を発行する。
【００４０】
マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図２に示す。
【００４１】
図２に示されるように、Ｓ２０１では、該時点で受け取ったマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）からマップ対象ウィンドウの識別子を獲得して、Ｓ２０２に進む。
【００４２】
Ｓ２０２では、マップ対象ウィンドウの識別子で内部データベースを検索し、対応するウィンドウ情報が存在する場合はＳ２０３へ進み、存在しない場合はＳ２１４へ進む。
【００４３】
Ｓ２０３では、内部データベースで対象ウィンドウのスタック位置確定フラグが確定済みかどうかをチェックし、確定済みの場合はＳ２１３に進み、暫定の場合はＳ２０４に進む。
【００４４】
Ｓ２０４では、対象ウィンドウのプロパティ獲得フラグをチェックし、獲得済みの場合はＳ２０６に進み、未獲得の場合はＳ２０５に進む。
【００４５】
Ｓ２０５では、対象ウィンドウのウィンドウ種類及びグループ値をウィンドウシステムに問い合わせて獲得し、内部データベースに格納し、Ｓ２０６に進む。
【００４６】
Ｓ２０６では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウの場合は、Ｓ２１３に進み、通常ウィンドウの場合は、Ｓ２０７に進む。
【００４７】
Ｓ２０７では、内部データベースに、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウがあるかどうかをチェックし、有る場合はＳ２０８進み、無い場合はＳ２０９に進む。
【００４８】
Ｓ２０８では、対象ウィンドウが、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウの内のスタック最上位のウィンドウの直上となるようウィンドウシステム１２にスタック変更要求を発行する。
【００４９】
Ｓ２０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図３に示す。
【００５０】
図３に示されるように、通常ウィンドウである対象ウィンドウが、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが確定済みのウィンドウの内のスタック最上位のウィンドウの直上に移されているのが解る。 Ｓ２０９では、内部データベースから、通常ウィンドウ全体を対象にスタック位置確定フラグが確定済みのウィンドウを検索し、存在する場合はＳ２１０に進み、存在しない場合はＳ２１１に進む。
【００５１】
Ｓ２１０では、内部データベースにあるスタック位置確定フラグが確定済みの通常ウィンドウのうち、スタック位置が最上位のウィンドウの直上に対象ウィンドウが位置するよう、ウィンドウシステム１２に対してスタック変更要求を発行し、Ｓ２１２に進む。
【００５２】
Ｓ２１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図４に示す。
図４に示されるように、通常ウィンドウである対象ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体の内のスタック最上位のウィンドウの直上に移されているのが解る。
【００５３】
Ｓ２１１では、スタック位置の最下位に対象ウィンドウが位置するよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１２に進む。
【００５４】
Ｓ２１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図５に示す。
図５に示されるように、通常ウィンドウである対象ウィンドウが、スタック最下位に移されているのが解る。
【００５５】
Ｓ２１２では、ウィンドウシステム１２に対してマップ対象ウィンドウのマップ要求を発行し、内部データベースの対象ウィンドウのウィンドウ情報の内、スタック位置確定フラグが暫定を示している場合は確定済みに更新し、また、内部データベース全体に対して必要に応じてスタック位置情報を更新した上で、Ｓ２１３に進む。
【００５６】
Ｓ２１３では、処理を終了する。
【００５７】
ウィンドウシステム１２は、図２のＳ２０８やＳ２１０、Ｓ２１１に起因するスタック変更要求をウィンドウマネージャ１０５から受け取り、要求に従ってウィンドウのスタック順を変更する。また、図２のＳ２１２に起因するマップ要求をウィンドウマネージャ１０５から受け取り、要求に従ってウィンドウのマップする。マップされたウィンドウは、ウィンドウの重なり具合にもよるが、他のウィンドウの下に隠れていなければ、スクリーン１に表示されるようになる。
【００５８】
図２の処理によって、アプリケーション１０１、１０２、１０３が生成及びウィンドウ種類及びグループ設定した通常ウィンドウは、表示までに必ず、スタック位置情報が確定済みとなり、また、スタック位置がグループ毎に纏められ、また、優先ウィンドウのスタック上位に表示される事もない。また、優先ウィンドウは、スタック位置が変更されることなく表示される。
【００５９】
図１において、アプリケーションプログラム１０１、１０２、１０３は、生成及びウィンドウ種類及びグループ設定した通常ウィンドウに対して、スタック変更要求として、グループ内スタック最上位移動をウィンドウシステム１２に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、グループ内スタック最上位移動要求にＸＲａｉｓｅＷｉｎｄｏｗ（）関数を割り当てれば良い。また、優先ウィンドウに対して、スタック変更要求として、優先ウィンドウスタック最上位移動要求をウィンドウシステム１２に対して発行する事ができ、例えば、グループ内スタック最上位移動要求と同じＸＲａｉｓｅＷｉｎｄｏｗ（）関数を割り当てる。
【００６０】
アプリケーションプログラムがＸＲａｉｓｅＷｉｎｄｏｗ（）を実施した場合、ウィンドウシステム１２はスタック変更をせず、ウィンドウマネージャ１０５に対してスタック最上位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）を発行する。
【００６１】
スタック最上位移動要求イベントを受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図６に示す。
【００６２】
図６に示されるように、Ｓ６０１では、該時点で受け取ったスタック最上位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）から対象ウィンドウの識別子を獲得して、Ｓ６０２に進む。
【００６３】
Ｓ６０２では、対象ウィンドウの識別子で内部データベースを検索し、対応するデータが存在する場合はＳ６０３へ進み、存在しない場合はＳ６１２へ進む。
【００６４】
Ｓ６０３では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ６０４に進む。
【００６５】
Ｓ６０４では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウであればＳ６０５に進み、通常ウィンドウであればＳ６０６に進む。
【００６６】
Ｓ６０５では、内部データベースからウィンドウ種類が優先ウィンドウであるものの内、スタック最上位のウィンドウを検索し、そのウィンドウが対象ウィンドウ自身であれば、何もせずＳ６１２に進み、そのウィンドウが対象ウィンドウ自身でなければ、そのウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１２に進む。
【００６７】
Ｓ６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図７に示す。
【００６８】
図７に示されるように、対象ウィンドウのみが優先ウィンドウの中のスタック最上位のウィンドウの直上に移されているのが解る。
Ｓ６０６では、対象ウィンドウと同じグループに属する通常ウィンドウを内部データベースから検索してリストアップし、Ｓ６０７に進む。
【００６９】
Ｓ６０７では、前記リストアップした中にスタック位置確定フラグが確定済みであるウィンドウが存在するならばＳ６０８に進み、存在しないならＳ６０９に進む。
【００７０】
Ｓ６０８では、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば、それら全てを、それらの中でみたスタック順はそのままで、リストアップした中でスタック位置確定フラグが確定済みであるウィンドウの内の最上位のウィンドウの直上に位置させ、更に対象ウィンドウをリストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１０に進む。 Ｓ６０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図８に示す。
【００７１】
図８に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定のウィンドウが、同じグループ値を持つスタック位置確定フラグが確定済みのウィンドウの直上に移され、同一グループ値を持つウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００７２】
図６において、Ｓ６０９では、内部データベースにスタック位置確定フラグが確定済みのウィンドウが存在するならばＳ６１０に進み、存在しないならばＳ６１１に進む。
【００７３】
Ｓ６１０では、Ｓ６０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済みであるスタック最上位の通常ウィンドウの直上に位置させ、更に対象ウィンドウを前記リストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１２に進む。
【００７４】
Ｓ６１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図９に示す。
【００７５】
図９に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体のスタック最上位ウィンドウの直上に移され、同一グループ値を持つウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００７６】
図６において、Ｓ６１１では、Ｓ６０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、全体スタックの最下位とし、更に対象ウィンドウをリストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ６１２に進む。
【００７７】
Ｓ６１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１０に示す。
【００７８】
図１０に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック最下位に移され、同一グループ値を持つ通常ウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００７９】
図６において、Ｓ６１２では、処理を終了する。
【００８０】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成及びウィンドウ種類及びグループ設定したウィンドウに対して、グループ内スタック最下位移動をウィンドウシステム１２に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、グループ内スタック最下位移動にＸＬｏｗｅｒＷｉｎｄｏｗ（）関数を割り当てれば良い。また、優先ウィンドウに対して、スタック変更要求として、優先ウィンドウスタック最下位移動要求をウィンドウシステム１２に対して発行する事ができ、例えば、グループ内スタック最下位移動要求と同じＸＬｏｗｅｒＷｉｎｄｏｗ（）関数を割り当てる。
【００８１】
アプリケーションプログラムがＸＬｏｗｅｒＷｉｎｄｏｗ（）を実施した場合、ウィンドウシステム１２はスタック変更をせず、ウィンドウマネージャ１０５に対してスタック最下位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）を発行する。スタック最下位移動要求イベントを受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図１１に示す。
【００８２】
図１１に示されるように、Ｓ１１０１では、該時点で受け取ったスタック最下位移動要求イベント（ＣｏｎｆｉｇｕｒｅＲｅｑｕｅｓｔ）から対象ウィンドウの識別子を獲得して、Ｓ１１０２に進む。
【００８３】
Ｓ１１０２では、対象ウィンドウの識別子で内部データベースを検索し、対応するデータが存在する場合はＳ１１０３へ進み、存在しない場合はＳ１１１２へ進む。
【００８４】
Ｓ１１０３では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ１１０４に進む。
【００８５】
Ｓ１１０４では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウの場合はＳ１１０５へ進み、通常ウィンドウの場合はＳ１１０６へ進む。
【００８６】
Ｓ１１０５では、内部データベースからウィンドウ種類が優先ウィンドウであるものの内、スタック最下位のウィンドウを検索し、そのウィンドウが対象ウィンドウ自身であれば、何もせずＳ１１１２へ進み、そのウィンドウが対象ウィンドウ自身でなければ、そのウィンドウの直下となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００８７】
Ｓ１１０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１２に示す。
【００８８】
図１２に示されるように、対象ウィンドウのみが優先ウィンドウの中のスタック最下位のウィンドウの直下に移されているのが解る。
【００８９】
図１１において、Ｓ１１０６では、対象ウィンドウと同じグループに属する通常ウィンドウを内部データベースから検索してリストアップし、Ｓ１１０７に進む。
【００９０】
Ｓ１１０７では、前記リストアップした中にスタック位置確定フラグが確定済みであるウィンドウが存在するならばＳ１１０８に進み、存在しないならＳ１１０９に進む。
【００９１】
Ｓ１１０８では、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば、それら全てを、それらの中でみたスタック順はそのままで、リストアップした中でスタック位置確定フラグが確定済みであるウィンドウの内の最上位のウィンドウの直上に位置させ、更に対象ウィンドウをリストアップしたウィンドウの中で最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００９２】
Ｓ１１０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１３に示す。図１３に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、同じグループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウの直上に移され、同一グループ値を持つ通常ウィンドウ全体の中で対象ウィンドウのスタック最下位移動がなされているのが解る。
【００９３】
図１１において、Ｓ１１０９では、内部データベースにスタック位置確定フラグが確定済みの通常ウィンドウが存在するならばＳ１１１０に進み、存在しないならばＳ１１１１に進む。
【００９４】
Ｓ１１１０では、Ｓ１１０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済みであるスタック最上位の通常ウィンドウの直上に位置させ、更に対象ウィンドウを前記リストアップしたウィンドウの中で最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００９５】
Ｓ１１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１４に示す。
【００９６】
図１４に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体のスタック最上位ウィンドウの直上に移され、同一グループ値を持つウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【００９７】
図１１において、Ｓ１１１１では、Ｓ１１０６でリストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、全体スタックの最下位とし、更に対象ウィンドウをリストアップしたウィンドウの中で最上位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップしたウィンドウのスタック位置確定フラグを確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１１１２に進む。
【００９８】
Ｓ１１１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１５に示す。
【００９９】
図１５に示されるように、対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック最下位に移され、同一グループ値を持つ通常ウィンドウ全体の中で対象ウィンドウのスタック最上位移動がなされているのが解る。
【０１００】
図１１において、Ｓ１１１２では、処理を終了する。
【０１０１】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成及びウィンドウ種類及びグループ設定した通常ウィンドウに対して、グループ単位スタック最上位移動をウィンドウマネージャ１０５に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、クライアントメッセージ機構を利用する事で容易に実現できる。今後、クライアントメッセージでウィンドウマネージャ１０５に対して発行するグループ単位スタック最上位移動要求のメッセージの事をグループ単位スタック最上位移動要求メッセージと呼ぶ事とする。そして、このグループ単位スタック最上位移動要求メッセージには、移動したいグループ値が含まれているものとする。
【０１０２】
アプリケーションプログラムがグループ単位スタック最上位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）を発行した場合、ウィンドウシステム１２経由でウィンドウマネージャ１０５に転送される。 グループ単位スタック最上位移動要求メッセージを受け取った際のウィンドウマネージャ１０５の動作例となるフローを図１６に示す。
【０１０３】
図１６に示されるように、Ｓ１６０１では、該時点で受け取ったグループ単位スタック最上位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）から対象グループ値を獲得して、Ｓ１６０２に進む。
【０１０４】
Ｓ１６０２では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ１６０３に進む。
【０１０５】
Ｓ１６０３では、対象グループ値を持つ通常ウィンドウ情報を内部データベースから検索してリストアップし、Ｓ１６０４に進む。
【０１０６】
Ｓ１６０４では、内部データベースにスタック位置確定情報が確定済み且つグループ値情報が対象グループ値とは異なる通常ウィンドウが存在すればＳ１６０５に進み、存在しなければＳ１６０６に進む。
【０１０７】
Ｓ１６０５では、リストアップした中でのスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済み且つグループ値情報が対象グループ値とは異なる通常ウィンドウの内でスタック最上位のウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１６０７に進む。
【０１０８】
Ｓ１６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１７に示す。
【０１０９】
図１７に示されるように、対象グループ値を持つ通常ウィンドウが、スタック位置確定フラグが確定済み且つグループ値情報が対象グループ値とは異なる通常ウィンドウ全体のスタック最上位ウィンドウの直上に移されているのが解る。
【０１１０】
図１６におけるＳ１６０６では、リストアップした中でのスタック順はそのままで、全体スタックの最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１６０７に進む。
Ｓ１６０６のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図１８に示す。
【０１１１】
図１８に示されるように、対象グループ値を持つ通常ウィンドウが、全体スタックの最下位に移されているのが解る。
【０１１２】
図１６において、Ｓ１６０７では、処理を終了する。
【０１１３】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成及びウィンドウ種類及びグループ設定した通常ウィンドウに対して、グループ単位スタック最下位移動をウィンドウマネージャ１０５に対して発行する事ができる。Ｘウィンドウシステムの場合、例えば、クライアントメッセージ機構を利用する事で容易に実現できる。今後、クライアントメッセージでウィンドウマネージャ１０５に対して発行するグループ単位スタック最下位移動要求のメッセージの事をグループ単位スタック最下位移動要求メッセージと呼ぶ事とする。そして、このグループ単位スタック最下位移動要求メッセージには、移動したいグループ値が含まれているものとする。
【０１１４】
アプリケーションプログラムがグループ単位スタック最下位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）を発行した場合、ウィンドウシステム１２経由でウィンドウマネージャ１０５に転送される。
【０１１５】
グループ単位スタック最下位移動要求メッセージを受け取った際のウィンドウマネージャ１０５の動作例となるフローを図１９に示す。
【０１１６】
図１９に示されるように、Ｓ１９０１では、該時点で受け取ったグループ単位スタック最下位移動要求メッセージ（ＣｌｉｅｎｔＭｅｓｓａｇｅ）から対象グループ値を獲得して、Ｓ１９０２に進む。
【０１１７】
Ｓ１９０２では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ１９０３に進む。
【０１１８】
Ｓ１９０３では、対象グループ値を持つ通常ウィンドウを内部データベースから検索してリストアップし、Ｓ１９０４に進む。
【０１１９】
Ｓ１９０４では、リストアップした中でのスタック順はそのままで、全体スタックの最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、次に、リストアップした中でスタック位置確定フラグが暫定であるウィンドウがあれば確定済みに更新し、また、内部データベース全体に対してスタック位置情報を更新した上で、Ｓ１９０５に進む。
【０１２０】
Ｓ１９０４のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２０に示す。
【０１２１】
図２０に示されるように、対象グループ値を持つ通常ウィンドウが、全体スタックの最下位に移されているのが解る。
【０１２２】
図１９におけるＳ１９０５では、処理を終了する。
【０１２３】
図１において、アプリケーションプログラム１０１，１０２、１０３は、生成したウィンドウに対して破棄要求を発行する。
【０１２４】
ウィンドウシステム１２は、破棄要求を受け取ると、該当するウィンドウを管理から外して削除する。そして、ウィンドウマネージャ１０５にウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を発行する。
【０１２５】
ウィンドウマネージャ１０５は、ウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を受け取ると、そこからウィンドウ識別子を抽出して、該当するウィンドウ情報を内部データベースから検索し削除した後、内部データベース全体に対して必要に応じてスタック位置を更新し、処理を終了する。
【０１２６】
以上のことにより、各通常ウィンドウはそのウィンドウの表示までに、ウィンドウのスタック順がグループ毎に纏められるので、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられて表示される事が無くなる。また、ウィンドウ管理プログラムが、スタック変更要求を受け取る事を切っ掛けにして、スタック変更対象となるグループに属する通常ウィンドウ全てを、その中でのスタック順は保持したままで纏めた上でスタック変更を実施するので、アプリケーションプログラムは、自グループのウィンドウのスタック順を把握し易くなる。また、ウィンドウ管理プログラムにグループ内のスタック最上位移動とグループ内のスタック最下位移動の機能を設ける事で、グループ内で通常ウィンドウのスタック順を操作できるので、各アプリケーションプログラムは、他のアプリケーションプログラムの通常ウィンドウ表示を気にする事無く、スタック変更を行う事ができる。また、ウィンドウ管理プログラムにグループ単位のスタック最上位移動と最下位移動の機能を設ける事で、例えば、グループをアプリケーションプログラム単位で振り分けた場合だと、そのアプリケーションに属するウィンドウのメンバーを知らなくても、スタック最前面にそのアプリケーションに属する全通常ウィンドウを移動させる事が可能となる。また、優先ウィンドウを設ける事で、グループ単位のスタック順に関係無く、最優先で表示するウィンドウのサービスを提供することができる。
【０１２７】
なお、本実施の形態では、ウィンドウマネージャのウィンドウのウィンドウ種類及びグループ値取得のタイミングをマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）受信時及びスタック変更要求受信時としたが、これに限定されるものではなく、アプリケーションプログラムがウィンドウ種類及びグループ設定をしたタイミングで取得して内部データベースに記憶しておいても良く、その方がむしろ処理効率が良い。更に、このタイミングで、スタック順をグループ毎に纏めても構わない。また、ウィンドウ種類及びグループ値の変更を認めても良いし、認めなくても良い。認める場合は、ウィンドウ種類及びグループ設定のタイミングで、ウィンドウ種類が優先ウィンドウから通常ウィンドウに変更された場合は、スタック位置確定フラグを暫定に変更する。逆にウィンドウ種類が通常ウィンドウから優先ウィンドウに変更された場合は、該時点のスタック最上位に該ウィンドウを位置させるようにスタック変更を行う。また、ウィンドウ種類に変更が無く、グループ値が変更となった場合は、スタック位置確定フラグを暫定に変更する。そして、内部データベースを更新すれ場良い。また、認めない場合は、ウィンドウ種類及びグループ設定のタイミングで、プロパティ獲得フラグをチェックして、獲得済みであれば、該設定を無視すれば良い。
【０１２８】
また、ウィンドウ種類として優先ウィンドウと通常ウィンドウの２種類を制御する例を示したが、通常ウィンドウの１種類だけであっても容易に実施できる事は言うまでも無い。
【０１２９】
また、ウィンドウマネージャがルートウィンドウの子ウィンドウであるトップレベルウィンドウのスタック順を制御する場合を例に示したが、トップレベルウィンドウの子孫ウィンドウに対しても実施する事ができる事は言うまでも無い。
【０１３０】
また、ウィンドウ管理プログラムをＸウィンドウシステムとウィンドウマネージャとして、アプリケーションプログラムとのインターフェースにウィンドウ生成要求、マップ要求を用いたが、これに限定されるものではなく、表示要求に相当するインターフェースさえあれば良く、その場合、ウィンドウ管理プログラムは、ウィンドウ表示要求受信時に、本実施の形態で示したウィンドウ生成要求受信時の処理とマップ要求受信時の処理を纏めて行えば良い。
【０１３１】
また、ウィンドウのスタック順をグループ毎に一連とする際、単にウィンドウのスタック順を変更するだけであったが、例えば、ウィンドウ管理プログラムが、グループ毎に代表ウィンドウを１枚生成し、ウィンドウのスタック順をグループ毎に一連とする際に、前記ウィンドウを前記代表ウィンドウの子ウィンドウとするようにして制御することも容易である。そうすることによって、グループ単位のスタック移動やグループ単位のウィンドウの表示／非表示の切り替えを代表ウィンドウに対する制御で実施できる分、グループ内のウィンドウが多いほど、処理負荷を軽減することができる。代表ウィンドウ使用下でのスタックの様子を示す例となる模式図を図２５に示す。
【０１３２】
また、最上位グループよりスタック下位のウィンドウ表示について、ウィンドウ管理プログラムでは非表示とするような制御はしていないが、非表示とする制御を行う事も容易に実現できる。その場合、ウィンドウ情報に表示／非表示を示すマップフラグを追加して、アプリケーションプログラムの表示要求状態を記憶しておき、該ウィンドウの所属するグループが通常ウィンドウの中でスタック最上位となった時、前記マップフラグをチェックし、表示となっていればマップ処理を行い、非表示となっていればアンマップのままとする。逆に、該ウィンドウの所属するグループが通常ウィンドウの中でスタック最上位でなくなった際には、前記マップフラグが表示となっていればアンマップ処理を行い、非表示となっていれば何もしない。これにより、通常ウィンドウの中の最上位グループよりスタック下位のグループが何を表示しようとしても，表示装置に表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。
【０１３３】
また、通常ウィンドウの最上位グループに属する全ウィンドウの中のスタック最下位のウィンドウの直下に、ウィンドウ管理プログラムが生成及びマップする特定のウィンドウを位置させなかったが、位置させることも容易に実現できる。これにより、例えば、前記特定のウィンドウを表示装置のスクリーン一杯に表示しておけば、前記特定のウィンドウのスタック下位のグループが何を表示しようとしても，表示装置に表示されないので、最上位グループのウィンドウで覆われない部分に中途半端に映り込む心配が無い。前記特定のウィンドウを使用した場合のスタックの様子を示す例となる模式図を図２６に示し、また、スクリーンに表示されている例となる模式図を図２７に示す。
【０１３４】
また、アプリケーションプログラムが３つの場合を例に示したが、これに限定されるものではなく、１つ以上であれば良い。
【０１３５】
また、各アプリケーションプログラムに１つのグループを割り当てた場合を例に示したが、これに限定されるものではなく、１つのアプリケーションに複数のグループを割り当てても良く、また、複数のアプリケーションに１つのグループを割り当てても構わない。
【０１３６】
また、ウィンドウ管理プログラムをＸウィンドウシステムとウィンドウマネージャとして、両者間でイベントや各種要求を送受信し合う例を示したが、これに限定されるものではなく、Ｘウィンドウシステムである必要は無いし、また、２つに分けてイベントや各種要求を送受信する構成である必要もなく、一体化して実施する場合は、イベントやメッセージのインターフェースを関数ベースに変える事で本実施の形態を容易に応用できる。
【０１３７】
また、通常ウィンドウの最上位グループに属する全ウィンドウの中のスタック最上位のウィンドウの直上に、ウィンドウ管理プログラムが生成する特定のウィンドウを位置させなかったが、位置させることも容易に実現できる。これにより、最上位グループを別のグループに入れ替える際、Ｘウィンドウシステムの場合、ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数を使用する事となるが、ウィンドウ群のスタック移動先を示すために使用できる。もし、最上位グループのウィンドウよりスタック上位にウィンドウが存在しなかった場合、存在する全てのウィンドウの並び順を決め、前記ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）の引数に代入せねばならないが、前記特定のウィンドウがあれば、前記特定のウィンドウと前記ウィンドウ群を引数に代入するだけで済む。
【０１３８】
また、Ｘウィンドウシステムを用いる場合、ウィンドウマネージャは、スタックを操作するためにＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数を使用する。ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）関数の引数には、ウィンドウ群とそのウィンドウ群の移動先を示すウィンドウを指定するが、それらの何れかが破棄されていた場合、スタック操作が意図した通りに実施されない事がある。そのための対策として、例えば、ウィンドウマネージャは、ウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を受け取った際に、該当するウィンドウ情報を内部データベースから検索し削除し、内部データベース全体に対して必要に応じてスタック位置を更新した後、次に、ウィンドウシステムの該時点でのスタックツリーを問い合わせて獲得し、ウィンドウマネージャが認識していない新規のウィンドウは対象から外し、ウィンドウマネージャのスタックツリーとの整合性をチェックし、ウィンドウマネージャの認識と異なっている場合は、ウィンドウマネージャのスタックツリーに合わせ込むスタック変更要求を発行し、認識が合うまで、ウィンドウシステムの該時点でのスタックツリー問い合わせ、整合性チェック、スタック変更要求の発行を繰り返すようにしても良い。これにより、ウィンドウシステムがスタック変更処理に失敗しても、ウィンドウシステム間とのスタック認識の整合性を確保でき、処理が破綻する事がなくなる。
【０１３９】
また、ウィンドウマネージャが、ＸＲｅｓｔａｃｋＷｉｎｄｏｗｓ（Ｒ）を実行した際にフラグを立て、ウィンドウ破棄通知イベント（ＤｅｓｔｒｏｙＮｏｔｉｆｙ）を受け取った際に、前記フラグが立っている場合にのみ、前記フラグを下げると共にスタックツリーの整合性のための処理を行うようにしても良い。これにより、スタックツリーの整合性のための処理の実行頻度を軽減できる。
【０１４０】
また、コンピュータ１とは、家庭用コンピュータや携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｃｅ）、セットトップボックス、デジタルスチルカメラ、カメラ一体型ＶＴＲ等、プログラムが動作するためのＣＰＵとメモリを実装して表示装置に複数のウィンドウを表示しようとする装置であれば何でも良い事は言うまでもない。
【０１４１】
また、表示装置１１をコンピュータ１の一部としたが、物理上で一体化している事を指すものではなく、コンピュータ１と有線／無線を問わず、何らかの形で接続されていさえすれば良い。
【０１４２】
また、本実施の形態のウィンドウスタック制御方法を内臓するプログラムは、ＲＯＭやディスク等に記憶して供給する事ができるほか、ネットワークを介して供給する事が可能である事は言うまでもない。
【０１４３】
（実施の形態２）
本実施の形態のウィンドウスタック制御方法は、実施の形態１を変形したものであり、実施の形態１と実施の形態２の違いは、マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作と、アプリケーションプログラムがウィンドウ種類及びグループ値を設定するタイミングでウィンドウマネージャ１０５はスタック順をグループ毎に纏めてはいけないことだけである。よって、本実施例では、ウィンドウマネージャ１０５のマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作についてのみ説明する。
【０１４４】
マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャ１０５の動作例となるフロー図を図２１に示す。
【０１４５】
図２１に示されるように、Ｓ２１０１では、該時点で受け取ったマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）からマップ対象ウィンドウの識別子を獲得して、Ｓ２１０２に進む。
【０１４６】
Ｓ２１０２では、マップ対象ウィンドウの識別子で内部データベースを検索し、対応するウィンドウ情報が存在する場合はＳ２１０３へ進み、存在しない場合はＳ２１１５へ進む。
【０１４７】
Ｓ２１０３では、内部データベースで対象ウィンドウのスタック位置確定フラグが確定済みかどうかをチェックし、確定済みの場合はＳ２１１４に進み、暫定の場合はＳ２１０４に進む。
【０１４８】
Ｓ２１０４では、対象ウィンドウのプロパティ獲得フラグをチェックし、獲得済みの場合はＳ２１０６に進み、未獲得の場合はＳ２１０５に進む。
【０１４９】
Ｓ２１０５では、対象ウィンドウのウィンドウ種類及びグループ値をウィンドウシステムに問い合わせて獲得し、内部データベースに格納し、Ｓ２１０６に進む。
【０１５０】
Ｓ２１０６では、対象ウィンドウのウィンドウ種類をチェックし、優先ウィンドウの場合は、Ｓ２１１４に進み、通常ウィンドウの場合は、Ｓ２１０７に進む。
【０１５１】
Ｓ２１０７では、内部データベースにあるプロパティ獲得フラグが未獲得である全ウィンドウについて、ウィンドウシステム１２に対してウィンドウ種類及びグループ値を問い合わせ、獲得できたウィンドウについては、そのウィンドウ種類及びグループ値とプロパティ獲得済みである事を内部データベースに記憶し、Ｓ２１０８に進む。
【０１５２】
Ｓ２１０８では、対象ウィンドウと同じグループに属する通常ウィンドウを内部データベースから検索してリストアップし、Ｓ２１０９に進む。 Ｓ２１０９では、前記リストアップした中にスタック位置確定フラグが確定済みであるウィンドウが存在するならばＳ２１１０に進み、存在しないならＳ２１１１に進む。
【０１５３】
Ｓ２１１０では、リストアップした中でスタック位置確定フラグが暫定であるウィンドウ全てを、それらの中でみたスタック順はそのままで、リストアップした中でスタック位置確定フラグが確定済みであるウィンドウの内の最上位のウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１１４に進む。 Ｓ２１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２２に示す。
【０１５４】
図２２に示されるように、マップ対象ウィンドウ及びマップ対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、前記グループ値を持つスタック位置確定フラグが確定済みの通常ウィンドウの直上に移されているのが解かる。
【０１５５】
図２１において、Ｓ２１１１では、内部データベースにスタック位置確定フラグが確定済みの通常ウィンドウが存在するならばＳ２１１２に進み、存在しないならばＳ２１１３に進む。
【０１５６】
Ｓ２１１２では、Ｓ２１０８でリストアップした中でスタック位置確定フラグが暫定である通常ウィンドウ全てを、それらの中でみたスタック順はそのままで、内部データベースの中でスタック位置確定フラグが確定済みであるスタック最上位の通常ウィンドウの直上となるよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１１４に進む。
【０１５７】
Ｓ２１１２のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２３に示す。 図２３に示されるように、マップ対象ウィンドウ及びマップ対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック位置確定フラグが確定済みの通常ウィンドウ全体のスタック最上位ウィンドウの直上に移されているのが解る。
【０１５８】
図２１において、Ｓ２１１３では、Ｓ２１０８でリストアップした中でスタック位置確定フラグが暫定である通常ウィンドウ全てを、それらの中でみたスタック順はそのままで、全体スタックの最下位となるよう、ウィンドウシステム１２にスタック変更要求を発行し、Ｓ２１１４に進む。
【０１５９】
Ｓ２１１３のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図を図２４に示す。
【０１６０】
図２４に示されるように、マップ対象ウィンドウ及びマップ対象ウィンドウと同じグループ値を持つスタック位置確定フラグが暫定の通常ウィンドウが、スタック最下位に移されているのが解る。
【０１６１】
図２１において、Ｓ２１１４では、ウィンドウシステム１２に対してマップ対象ウィンドウのマップ要求を発行し、内部データベースの対象ウィンドウのウィンドウ情報の内、スタック位置確定フラグが未確定を示している場合は確定済みに更新し、また、内部データベース全体に対して必要に応じてスタック位置を更新した上で、Ｓ２１１５に進む。
【０１６２】
Ｓ２１１５では、処理を終了する。
【０１６３】
以上のことにより、ウィンドウ管理プログラムが、マップ対象ウィンドウと同じグループ値を持つスタック位置が暫定の通常ウィンドウ群を、その通常ウィンドウ群の中でのスタック上下関係は保持しつつスタック位置を移してグループ毎に纏めるため、マップによって、同一グループ内でみたスタック順は変更されず、アプリケーションの同一グループ内のスタック順管理の負担が軽減される。更に、実施の形態１で示したように、スタック変更要求受信時にも、対象ウィンドウと同じグループ値を持つスタック位置が暫定の通常ウィンドウ群を、その通常ウィンドウ群の中でのスタック上下関係は保持しつつグループ毎に纏める事で、アプリケーションプログラムは、自グループに属するウィンドウのスタック順をウィンドウの生成順を基本として管理する事ができる。これは、Ｘウィンドウシステムの基本と一致しており、アプリケーションプログラムは、自グループの通常ウィンドウについて、一般的なスタック順決定ルールである生成順ベースで重なりを管理すれば良くなる。
【０１６４】
なお、本実施の形態では、マップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）受信時に、ウィンドウマネージャのウィンドウのグループ値取得を行っているが、これに限定されるものではなく、実施の形態１と同様、アプリケーションプログラムがウィンドウ種類及びグループ設定をしたタイミングでグループ値を取得して内部データベースにウィンドウ種類とグループ値とプロパティ獲得済みである事を記憶しておいても良く、その方がむしろ処理効率が良い。しかし、実施の形態１と違い、前記タイミングで、スタック順をグループ毎に纏めてはいけない。
【０１６５】
【発明の効果】
以上のように本発明によれば、ウィンドウ制御方法において、アプリケーションプログラムがウィンドウにグループを指定し、ウィンドウ管理プログラムがウィンドウのスタック順をグループ毎に一連とすることにより、グループ最上位のウィンドウは、他のグループのウィンドウの下に重ねられる事が無くなり、最前面でウィンドウを表示中のアプリケーションのウィンドウ表示に、他のアプリケーションが不用意に影響を及ぼす事を無くす事ができる。特に、画面が小さく、結果として、ウィンドウの重なり易い携帯電話やＰＤＡ等で、その効果は顕著である。
【図面の簡単な説明】
【図１】本発明の実施の形態１のウィンドウスタック制御方法を実現するシステムの構成例を示す図
【図２】本発明実施の形態１のマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャの動作例となるフロー図
【図３】本発明の実施の形態１の図２のＳ２０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図４】本発明の実施の形態１の図２のＳ２１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図５】本発明の実施の形態１の図２のＳ２１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図６】本発明の実施の形態１のスタック最上位移動要求イベントを受け取った際のウィンドウマネージャの動作例となるフロー図
【図７】本発明の実施の形態１の図６のＳ６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図８】本発明の実施の形態１の図６のＳ６０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図９】本発明の実施の形態１の図６のＳ６１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１０】本発明の実施の形態１の図６のＳ６１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１１】本発明の実施の形態１のスタック最下位移動要求イベントを受け取った際のウィンドウマネージャの動作例となるフロー図
【図１２】本発明の実施の形態１の図１１のＳ１１０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１３】本発明の実施の形態１の図１１のＳ１１０８のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１４】本発明の実施の形態１の図１１のＳ１１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１５】本発明の実施の形態１の図１１のＳ１１１１のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１６】本発明の実施の形態１のグループ単位スタック最上位移動要求メッセージを受け取った際のウィンドウマネージャの動作例となるフロー図
【図１７】本発明の実施の形態１の図１６のＳ１６０５のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１８】本発明の実施の形態１の図１６のＳ１６０６のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図１９】本発明の実施の形態１のグループ単位スタック最下位移動要求メッセージを受け取った際のウィンドウマネージャの動作例となるフロー図
【図２０】本発明の実施の形態１の図１９のＳ１９０４のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２１】本発明の実施の形態２のマップ要求イベント（ＭａｐＲｅｑｕｅｓｔ）を受け取った際のウィンドウマネージャの動作例となるフロー図
【図２２】本発明の実施の形態２の図２１のＳ２１１０のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２３】本発明の実施の形態２の図２１のＳ２１１２のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２４】本発明の実施の形態２の図２１のＳ２１１３のスタック変更要求によってスタックがどのように変化するかを示す具体例となる模式図
【図２５】本発明の実施の形態１の代表ウィンドウ使用下でのスタックの様子を示す例となる模式図
【図２６】本発明の実施の形態１の最上位グループに属する全ウィンドウの中のスタック最下位のウィンドウの直下に、ウィンドウ管理プログラムが生成及びマップする特定のウィンドウを位置させて使用した場合のスタックの様子を示す例となる模式図
【図２７】本発明の実施の形態１の最上位グループに属する全ウィンドウの中のスタック最下位のウィンドウの直下に、ウィンドウ管理プログラムが生成及びマップする特定のウィンドウを位置させて使用した場合のスクリーンに表示されている例となる模式図
【図２８】従来例におけるコンピュータ上で動作する３種類のアプリケーションが合計５枚のウィンドウを表示装置であるスクリーンに表示する際の表示例となる模式図
【図２９】従来例におけるウィンドウスタック順の例となる模式図
【図３０】従来例におけるウィンドウスタック順の例となる模式図
【符号の説明】
１ スクリーン
７ コンピュータ
８ ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）
９ メモリ
１０ バス
１１ 表示装置
１０１、１０２、１０３ アプリケーションプログラム
１０４ ウィンドウ管理プログラム
１０５ ウィンドウマネージャ
Claims (12)
- 表示装置に複数のウィンドウを表示する際のウィンドウの重ね合わせを管理するウィンドウスタック制御方法であって、
１つ以上のウィンドウを前記表示装置に表示する１つ以上のアプリケーションプログラムと、
前記１つ以上のアプリケーションプログラムが表示するウィンドウの重ね合わせを管理するウィンドウ管理プログラムとを備え、
前記アプリケーションプログラムが前記ウィンドウ管理プログラムに対してウィンドウのグループを指定し、前記ウィンドウ管理プログラムが、前記アプリケーションプログラムからウィンドウの表示要求を受け、該ウィンドウの表示を行う際に、該ウィンドウのスタック順をグループ毎に一連とする制御を行うことを特徴とするウィンドウスタック制御方法。 - ウィンドウ管理プログラムは、グループ毎に纏めていない第１のウィンドウの表示要求をアプリケーションプログラムから受け取った際に、グループ毎に纏めていない全ウィンドウから、前記第１のウィンドウと同じグループに属する第１のウィンドウ群を、前記第１のウィンドウ群の中でのスタック順関係は保持したまま、既にグループ毎に纏められた前記第１のウィンドウと同じグループに属する第２のウィンドウ群とスタック順を一連にし表示処理を行うことを特徴とする請求項１に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、グループ毎に代表ウィンドウを１枚生成し、ウィンドウのスタック順をグループ毎に一連とする際に、前記ウィンドウを前記代表ウィンドウの子ウィンドウとする事を特徴とする請求項１または２に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、アプリケーションプログラムからの要求を受けて、グループ内でウィンドウスタックの最上位移動、最下位移動を行うことを特徴とする請求項１から３のいずれかに記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、アプリケーションプログラムからの要求を受けて、グループ単位でウィンドウスタックの最上位移動、最下位移動を行うことを特徴とする請求項１から３のいずれかに記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、第１のウィンドウ又は第１のグループに対するスタック変更要求をアプリケーションプログラムから受け取った際に、グループ毎に纏めていない全ウィンドウから、前記第１のウィンドウと同じグループ又は前記第１のグループに属する第１のウィンドウ群を、前記第１のウィンドウ群の中でのスタック順関係は保持したまま、既にグループ毎に纏められた前記第１のウィンドウと同じグループ又は前記第１のグループに属する第２のウィンドウ群とスタック順を一連にしてスタック変更を行うことを特徴とする請求項４または５に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、アプリケーションプログラムによって指定されたウィンドウをグループに属させず、グループに属して表示された全てのウィンドウより常にスタック上位に位置させることを特徴とする請求項１に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、最上位グループに属するウィンドウよりスタック下位のウィンドウを常に非表示状態とすることを特徴とする請求項１に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、最上位グループに属するウィンドウの中のスタック最下位のウィンドウの直下に、特定のウィンドウを位置させることを特徴とする請求項１に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、最上位グループの直上に特定のウィンドウを位置させることを特徴とする請求項４または５に記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、ウィンドウマネージャが、ウィンドウ破棄通知受信時に、ウィンドウシステム間とでスタック認識の整合性を確認し、異なっている場合は、ウィンドウシステムのスタック認識をウィンドウマネージャのスタック認識にあわせ込む処理を行うことを特徴とする請求項１から３のいずれかに記載のウィンドウスタック制御方法。
- ウィンドウ管理プログラムは、Ｘウィンドウシステムとウィンドウマネージャとを備え、ウィンドウマネージャが、ウィンドウシステムにスタック変更を要求する際にフラグを立てる一方で、ウィンドウ破棄通知受信時に、前記フラグが立っている時のみ、ウィンドウシステム間とでスタック認識の整合性を確認し、異なっている場合は、ウィンドウシステムのスタック認識をウィンドウマネージャのスタック認識にあわせ込む処理を行い、前記フラグを下げることを特徴とする請求項１から３のいずれかに記載のウィンドウスタック制御方法。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003106393A JP2004310655A (ja) | 2003-04-10 | 2003-04-10 | ウィンドウスタック制御方法 |
| KR1020057019181A KR20060002964A (ko) | 2003-04-10 | 2004-03-29 | 윈도우 스택 제어방법, 윈도우 관리 프로그램, 및 윈도우관리장치 |
| PCT/JP2004/004414 WO2004090712A1 (ja) | 2003-04-10 | 2004-03-29 | ウィンドウスタック制御方法、ウィンドウ管理プログラム、ウィンドウ管理装置 |
| US10/550,728 US20060190838A1 (en) | 2003-04-10 | 2004-03-29 | Window stack control method, window management program, and window management apparatus |
| CNA2004800094431A CN1771475A (zh) | 2003-04-10 | 2004-03-29 | 窗口堆栈控制方法、窗口管理程序及窗口管理装置 |
| EP04724165A EP1617323A4 (en) | 2003-04-10 | 2004-03-29 | WINDOW STACK CONTROL METHOD, WINDOW MANAGEMENT PROGRAM AND WINDOW MANAGEMENT DEVICE |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003106393A JP2004310655A (ja) | 2003-04-10 | 2003-04-10 | ウィンドウスタック制御方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004310655A true JP2004310655A (ja) | 2004-11-04 |
Family
ID=33156912
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003106393A Pending JP2004310655A (ja) | 2003-04-10 | 2003-04-10 | ウィンドウスタック制御方法 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US20060190838A1 (ja) |
| EP (1) | EP1617323A4 (ja) |
| JP (1) | JP2004310655A (ja) |
| KR (1) | KR20060002964A (ja) |
| CN (1) | CN1771475A (ja) |
| WO (1) | WO2004090712A1 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010108304A (ja) * | 2008-10-30 | 2010-05-13 | Fuji Xerox Co Ltd | 表示制御装置、画像形成装置及びプログラム |
Families Citing this family (30)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8137200B2 (en) * | 1996-11-14 | 2012-03-20 | Bally Gaming, Inc. | Networked gaming system having a browser manager |
| JP3509060B2 (ja) * | 1998-05-28 | 2004-03-22 | 松下電器産業株式会社 | 表示制御装置および方法 |
| US9207717B2 (en) * | 2010-10-01 | 2015-12-08 | Z124 | Dragging an application to a screen using the application manager |
| US9223426B2 (en) | 2010-10-01 | 2015-12-29 | Z124 | Repositioning windows in the pop-up window |
| US9182937B2 (en) * | 2010-10-01 | 2015-11-10 | Z124 | Desktop reveal by moving a logical display stack with gestures |
| JP4150026B2 (ja) * | 2005-05-12 | 2008-09-17 | 株式会社東芝 | 携帯型電子機器及びウィンドウ制御システム |
| US7620905B2 (en) * | 2006-04-14 | 2009-11-17 | International Business Machines Corporation | System and method of windows management |
| US8627225B2 (en) * | 2006-06-09 | 2014-01-07 | Honeywell International Inc. | Apparatus and methods for ensuring closure of displays |
| JP5219407B2 (ja) * | 2007-05-31 | 2013-06-26 | 株式会社エヌ・ティ・ティ・ドコモ | 情報処理装置及びプログラム |
| JP4877831B2 (ja) * | 2007-06-27 | 2012-02-15 | 久美子 石井 | 確認システム、情報提供システム、ならびに、プログラム |
| JP5031588B2 (ja) * | 2008-01-07 | 2012-09-19 | 株式会社エヌ・ティ・ティ・ドコモ | 情報処理装置及びプログラム |
| US9372618B2 (en) * | 2010-10-01 | 2016-06-21 | Z124 | Gesture based application management |
| US9001149B2 (en) | 2010-10-01 | 2015-04-07 | Z124 | Max mode |
| CN102063302B (zh) * | 2010-12-20 | 2014-07-02 | 北京握奇数据系统有限公司 | 窗口管理方法、系统及终端 |
| US20130080932A1 (en) | 2011-09-27 | 2013-03-28 | Sanjiv Sirpal | Secondary single screen mode activation through user interface toggle |
| US9395868B2 (en) * | 2011-12-06 | 2016-07-19 | Google Inc. | Graphical user interface window spacing mechanisms |
| WO2014047831A1 (en) * | 2012-09-27 | 2014-04-03 | Motorola Mobility Llc | Method and apparatus for displaying computer application or computer activity |
| CN104598097A (zh) * | 2013-11-07 | 2015-05-06 | 腾讯科技（深圳）有限公司 | 即时通信im窗口的排序方法和装置 |
| CN105516782B (zh) * | 2015-12-10 | 2018-08-14 | 四川长虹电器股份有限公司 | Android系统智能电视悬浮界面互斥功能的实现方法及系统 |
| US10394449B2 (en) | 2016-09-23 | 2019-08-27 | Apple Inc. | Dynamic function row management |
| US10732996B2 (en) | 2016-09-23 | 2020-08-04 | Apple Inc. | Dynamic function row constraints |
| US10261667B2 (en) * | 2016-09-23 | 2019-04-16 | Apple Inc. | Dynamic function row item discovery and context |
| US10223128B2 (en) | 2016-09-23 | 2019-03-05 | Apple Inc. | Booting and power management |
| KR101840007B1 (ko) * | 2017-07-21 | 2018-03-19 | (주)신호테크 | 엘리베이터용 천장조립체 제작시스템의 보조부재 절단 및 분류 장치 |
| CN109569214B (zh) * | 2018-12-24 | 2021-07-16 | 海信视像科技股份有限公司 | 分屏模式下的应用显示方法及装置、显示设备 |
| CN110347459B (zh) * | 2019-06-11 | 2021-09-07 | 广州视源电子科技股份有限公司 | 一种窗口最小化方法、装置、存储介质及交互智能平板 |
| CN111191164B (zh) * | 2019-11-29 | 2023-08-22 | 泰康保险集团股份有限公司 | 一种窗口显示控制方法和装置 |
| CN113535287B (zh) * | 2020-04-17 | 2022-12-13 | 中标软件有限公司 | 一种Linux操作系统桌面环境窗口自动排列的方法 |
| CN113407293B (zh) * | 2021-08-19 | 2021-11-09 | 北京鲸鲮信息系统技术有限公司 | 窗口管理方法、装置、设备和存储介质 |
| CN113821142B (zh) * | 2021-11-24 | 2022-03-25 | 腾讯科技（深圳）有限公司 | 一种界面窗口的管理方法以及相关装置 |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS62182979A (ja) * | 1986-02-07 | 1987-08-11 | Fujitsu Ltd | 階層的マルチウインドウ制御方式 |
| JP2503995B2 (ja) * | 1986-09-05 | 1996-06-05 | カシオ計算機株式会社 | マルチウィンドウ表示方法 |
| JPH02244323A (ja) * | 1989-03-17 | 1990-09-28 | Fujitsu Ltd | マルチウィンドウのグループ制御方式 |
| JPH0380323A (ja) * | 1989-08-23 | 1991-04-05 | Fujitsu Ltd | ウインドウ表示制御方式 |
| DE69115762T2 (de) * | 1990-06-19 | 1996-06-13 | Fujitsu Ltd | Verfahren und Einrichtung zur Anzeigesteuerung von Mehrfenstern |
| JPH05282119A (ja) * | 1992-03-31 | 1993-10-29 | Nippon Telegr & Teleph Corp <Ntt> | マルチウィンドウ表示システム |
| JPH0644031A (ja) * | 1992-04-23 | 1994-02-18 | Nec Corp | マルチウィンドウ表示装置 |
| US5412776A (en) * | 1992-12-23 | 1995-05-02 | International Business Machines Corporation | Method of generating a hierarchical window list in a graphical user interface |
| US5615326A (en) * | 1993-12-30 | 1997-03-25 | Taligent, Inc. | Object-oriented viewing framework having view grouping |
| US5675755A (en) * | 1995-06-07 | 1997-10-07 | Sony Corporation | Window system preventing overlap of multiple always-visible windows |
| JP3344528B2 (ja) * | 1995-06-29 | 2002-11-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ウィンドウの表示方法およびそのシステム |
| US5874960A (en) * | 1995-07-05 | 1999-02-23 | Microsoft Corporation | Method and system for sharing applications between computer systems |
| US5995103A (en) * | 1996-05-10 | 1999-11-30 | Apple Computer, Inc. | Window grouping mechanism for creating, manipulating and displaying windows and window groups on a display screen of a computer system |
| US5835091A (en) * | 1996-08-21 | 1998-11-10 | International Business Machines Corporation | Manipulating and displaying a plurality of views in a graphical user interface |
| US6909443B1 (en) * | 1999-04-06 | 2005-06-21 | Microsoft Corporation | Method and apparatus for providing a three-dimensional task gallery computer interface |
| JP2001060134A (ja) * | 1999-08-24 | 2001-03-06 | Hitachi Ltd | マルチウィンドウ制御システム |
-
2003
- 2003-04-10 JP JP2003106393A patent/JP2004310655A/ja active Pending
-
2004
- 2004-03-29 CN CNA2004800094431A patent/CN1771475A/zh active Pending
- 2004-03-29 EP EP04724165A patent/EP1617323A4/en not_active Withdrawn
- 2004-03-29 WO PCT/JP2004/004414 patent/WO2004090712A1/ja active Application Filing
- 2004-03-29 KR KR1020057019181A patent/KR20060002964A/ko not_active Application Discontinuation
- 2004-03-29 US US10/550,728 patent/US20060190838A1/en not_active Abandoned
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2010108304A (ja) * | 2008-10-30 | 2010-05-13 | Fuji Xerox Co Ltd | 表示制御装置、画像形成装置及びプログラム |
| US8503010B2 (en) | 2008-10-30 | 2013-08-06 | Fuji Xerox Co., Ltd. | Display control device, display control method, image-forming device, computer readable medium, and computer data signal |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20060002964A (ko) | 2006-01-09 |
| EP1617323A1 (en) | 2006-01-18 |
| WO2004090712A1 (ja) | 2004-10-21 |
| CN1771475A (zh) | 2006-05-10 |
| US20060190838A1 (en) | 2006-08-24 |
| EP1617323A4 (en) | 2008-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004310655A (ja) | ウィンドウスタック制御方法 | |
| EP3971736A1 (en) | Topological structure diagram displaying method, device, apparatus, and storage medium | |
| US10275433B2 (en) | Remote browsing and searching | |
| US8751939B2 (en) | Side tab navigation and page views personalization systems and methods | |
| US7774366B2 (en) | Systems and methods for implementing multi-application tabs and tab sets | |
| US7415671B2 (en) | Interactive hierarchical status display | |
| US9047388B2 (en) | System, method, and software application for displaying data from a web service in a visual map | |
| US8990190B2 (en) | Contextual help article provider | |
| US9336321B1 (en) | Remote browsing and searching | |
| JP4552005B2 (ja) | 電子新聞表示装置 | |
| US20090164945A1 (en) | Information processing device and integrated information system | |
| EP2761570B1 (en) | Extending a conversation across applications | |
| US10530876B2 (en) | System and method for managing thematic information aggregations | |
| JP2004348380A (ja) | シンクライアントシステム、シンクライアント端末機、中継装置、サーバ装置及びシンクライアント端末画面表示方法 | |
| CN105577822A (zh) | 基于cdn节点的缓存集中管理系统 | |
| WO2010141506A1 (en) | System and method for enabling content aggregation by user proximity | |
| US20080159139A1 (en) | Method and system for a context manager for a converged services framework | |
| CN1852145A (zh) | 一种利用关联查询进行鉴权的系统及其方法 | |
| US8250480B2 (en) | Interactive navigation of a dataflow process image | |
| US9253281B2 (en) | Cells and/or vantage points in streaming media | |
| CN108881025B (zh) | 基于云终端方式的多电网调控系统画面统一浏览集成方法 | |
| CN102932185A (zh) | 服务器用户管理系统 | |
| JP5342531B2 (ja) | ネットワークシステム、共有フォルダアイコン表示方法、サーバ及びプログラム | |
| JP3884989B2 (ja) | ネットワーク構成情報管理システム及び該システムによるシステム構成情報取得方法、ネットワーク構成情報表示装置及び該装置を利用したネットワーク構成情報提供サービス方法 | |
| US20110202865A1 (en) | Perspective view |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060407 |
|
| RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20060512 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080513 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080916 |