(57)【要約】【課題】  ウィンドウの重なりや無駄なスペースのないワークスペースを構成するための直感的なユーザインタフェースを提供する。【解決手段】  ディスプレイ上に表示されたウィンドウＡの近くにウィンドウＢがマウス等の操作によりドラッグされ、ウィンドウＢがウィンドウＡに一定の距離に接近すると、ウィンドウＡ、Ｂのそれぞれの対向する辺にドッキング位置を示すのりしろ１０、１２が表示される。そして、ウィンドウＢのドラッグが停止されると、ウィンドウＢがウィンドウＡにドッキングされ、１つのウィンドウが形成される。【選択図】  図１
2008299689.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方法であって、
ディスプレイ上に表示された複数のウィンドウに関する管理情報を管理する管理ステップと、
ウィンドウの状態の変化を検出する検出ステップと、
前記検出ステップにより複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍または重複する他のウィンドウを検出するウィンドウ検出ステップと、
ウィンドウ検出ステップにより他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウのそれぞれにドッキングされる位置を表示する表示ステップと、
前記検出ステップにより前記１つのウィンドウの移動の停止が検出されたとき、前記１のウィンドウを前記他のウィンドウに前記ドッキング位置を介してドッキングするドッキングステップと、
を含むワークススペース管理方法。
【請求項２】
前記複数のウィンドウは、それぞれ異なるアプリケーションによって起動される、請求項１に記載のワークスペース管理方法。
【請求項３】
前記複数のウィンドウは矩形状であり、前記１つのウィンドウは、他のウィンドウの１辺のサイズに適合するサイズでドッキングされ、ドッキングされたウィンドウは矩形状である、請求項１に記載の管理方法。
【請求項４】
前記表示ステップは、前記１つのウィンドウと前記他のウィンドウの各々の少なくとも２辺にドッキング位置を表示する、請求項１に記載の管理方法。
【請求項５】
ワークスペース管理方法はさらに、前記検出ステップによりドッキングされたウィンドウに含まれるサブウィンドウのサイズが変更されたことが検出されたとき、前記管理情報を参照してドッキングされたウィンドウに含まれる他のサブウィンドウのサイズを同時に変更するサイズ変更ステップを含む、請求項１に記載の管理方法。
【請求項６】
ワークスペース管理方法はさらに、前記検出ステップによりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを全体として移動するステップを含む、請求項１に記載の管理方法。
【請求項７】
管理方法はさらに、ドッキングされたウィンドウのドッキングを解除するステップを含む、請求項１ないし６いずれか１つに記載の管理方法。
【請求項８】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方法であって、
１つのウィンドウがドラッグされて他のウィンドウに接近されたとき、１つのウィンドウと他のウィンドウとのドッキングされる位置を表示し、
ドッキング位置が表示された状態で１つのウィンドウのドラッグが停止されたとき、１つのウィンドウが他のウィンドウにドッキングされ、１つのウィンドウになる、
管理方法。
【請求項９】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方式であって、
ディスプレイ上に表示された複数のウィンドウに関する管理情報を記憶するウィンドウ管理手段と、
ウィンドウの状態の変化を検出する検出手段と、
前記検出手段により複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍または重複する他のウィンドウを検出するウィンドウ検出手段と、
ウィンドウ検出手段により他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウがドッキング可能であることを提示する提示手段と、
前記検出手段により前記１つのウィンドウの移動の停止が検出されたとき、前記１つのウィンドウを前記他のウィンドウに前記提示されたドッキング位置を介してドッキングするドッキング手段と、
を有するワークスペース管理方式。
【請求項１０】
前記提示手段は、前記１つのウィンドウが前記他のウィンドウにドッキングされる位置を表示する表示手段を含む、請求項９に記載の管理方式。
【請求項１１】
前記表示手段は、ウィンドウの特定の辺に他の辺と識別可能な表示を与える、請求項１０に記載の管理方式。
【請求項１２】
前記検出手段は、定期的にアクティブなウィンドウの状態を監視し、アクティブなウィンドウのイベントの変化を検出する、請求項９に記載の管理方式。
【請求項１３】
前記検出手段は、ウィンドウに対して操作されたイベントの種類を検出する、請求項９に記載の管理方式。
【請求項１４】
複数のウィンドウは、それぞれ異なるアプリケーションによって起動される、請求項９に記載の管理方式。
【請求項１５】
前記管理情報は、少なくともウィンドウを識別する識別情報、ウィンドウの位置情報、ウィンドウのサイズ情報を含む、請求項９に記載の管理方式。
【請求項１６】
前記複数のウィンドウは矩形状であり、前記ドッキング手段は、前記１つのウィンドウを、他のウィンドウの１辺のサイズに適合するサイズでドッキングし、ドッキングされたウィンドウは矩形状である、請求項９に記載の管理方式。
【請求項１７】
前記提示手段は、前記１つのウィンドウが、複数の他のウィンドウに接近したとき、前記１つのウィンドウと前記他のウィンドウの各々の少なくとも２辺にドッキング位置を表示する、請求項１０に記載の管理方式。
【請求項１８】
ワークスペース管理方式はさらに、前記検出手段によりドッキングされたウィンドウに含まれるサブウィンドウのサイズが変更が検出されたとき、前記管理情報を参照して、ドッキングされたウィンドウに含まれる他のサブウィンドウのサイズを同時に変更するサイズ変更手段を含む、請求項９に記載の管理方式。
【請求項１９】
ワークスペース管理方式はさらに、前記検出手段によりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを移動する移動手段を含む、請求項９に記載の管理方式。
【請求項２０】
ワークスペース管理方式はさらに、ドッキングされたウィンドウの状態を保存する状態保存手段と、前記状態保存手段により保存された状態に基づきドッキングウィンドウを再現する状態再現手段とを含む、請求項９に記載の管理方式。
【請求項２１】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方式であって、
１つのウィンドウを他のウィンドウにドッキングするドッキング手段と、
ドッキングされたドッキングウィンドウ内のサブウィンドウに対する操作履歴情報を保持する利用履歴保持手段と、
前記操作履歴情報に基づきドッキングされたウィンドウ内のサブウィンドウの配置を推薦する配置推薦手段と、
を有するワークスペース管理方式。
【請求項２２】
配置推薦手段は、前記操作履歴情報に基づき少なくともサブウィンドウの利用頻度またはサブウィンドウ間の類似度を算出し、その算出結果に応じてサブウィンドウの配置を決定する、請求項２１に記載のワークスペース管理方式。
【請求項２３】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方式であって、
１つのウィンドウがドラッグされて他のウィンドウに接近されたことを検出する手段と、
前記検出に応答して１つのウィンドウと他のウィンドウとのドッキングされる位置を表示する表示手段と、
ドッキング位置が表示された状態で１つのウィンドウのドラッグが停止されたとき、１つのウィンドウが他のウィンドウにドッキングし、１つのウィンドウを生成するドッキング手段と、
を有する管理方式。
【請求項２４】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理プログラムであって、
ディスプレイ上に表示された複数のウィンドウに関する管理情報を記憶するウィンドウ管理手段と、
ウィンドウの状態の変化を検出する検出手段と、
前記検出手段により複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍または重複する他のウィンドウを検出するウィンドウ検出手段と、
ウィンドウ検出手段により他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウのそれぞれにドッキングされる位置を表示する表示手段と、
前記検出手段により前記１つのウィンドウの移動の停止が検出されたとき、前記１つのウィンドウを前記他のウィンドウに前記ドッキング位置を介してドッキングするドッキング手段と、
を有するワークスペース管理プログラム。
【請求項２５】
前記複数のウィンドウは矩形状であり、前記ドッキング手段は、前記１つのウィンドウを、他のウィンドウの１辺のサイズに適合するサイズでドッキングし、ドッキングされたウィンドウは矩形状である、請求項２４に記載の管理プログラム。
【請求項２６】
ワークスペース管理方式はさらに、前記検出手段によりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを移動する移動手段を含む、請求項２４に記載の管理プログラム。
【請求項２７】
ワークスペース管理方式はさらに、ドッキングされたウィンドウの状態を保存する状態保存手段と、前記状態保存手段により保存された状態に基づきドッキングウィンドウを再現する状態再現手段とを含む、請求項２４に記載の管理プログラム。
【請求項２８】
アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理プログラムであって、
１つのウィンドウがドラッグされて他のウィンドウに接近されたことを検出する手段と、
前記検出に応答して１つのウィンドウと他のウィンドウとのドッキングされる位置を表示する表示手段と、
ドッキングされる位置が表示された状態で１つのウィンドウのドラッグが停止されたとき、１つのウィンドウが他のウィンドウにドッキングし、１つのウィンドウを生成するドッキング手段と、
を有する管理プログラム。
【請求項２９】
前記表示手段は、ウィンドウの特定の辺に他の辺と識別可能な表示を与える、請求項２８に記載の管理プログラム。
【請求項３０】
前記検出手段は、定期的にアクティブなウィンドウの状態を監視し、アクティブなウィンドウのイベントの変化を検出する、請求項２８に記載の管理プログラム。
【請求項３１】
前記検出手段は、ウィンドウに対して操作されたイベントの種類を検出する、請求項２８に記載の管理プログラム。
【請求項３２】
複数のウィンドウは、それぞれ異なるアプリケーションによって起動される、請求項２８に記載の管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェースのワークスペースとして管理するワークスペース管理方式に関する。
【背景技術】
【０００２】
近年、ますます情報が多様化し、その量も膨大になっている。個人の パーソナルコンピュータ（ＰＣ）内においても例外ではない。ユーザは、ＰＣ上でさまざまなアプリケーションを起動し、さまざまなドキュメントを同時に開いて作業を行う。多様な情報を表示したり、編集したりする場合には、多様なアプリケーションを利用することになる。これは、目的や情報の種類によって操作体系が異なるためである。例えば、テキスト文章はワードプロセッサ、お絵かきをする場合にはドローツール、Web上のドキュメントを見る場合にはWebブラウザという具合である。
【０００３】
このような状況では、ＰＣ上でさまざまなアプリケーションを起動し、多数のドキュメントを開くことになり、その管理も大変なものとなる。汎用ＯＳ（オペレーティングシステム）であるWindows(登録商標)では、起動しているアプリケーションや開いているドキュメントをタスクバーと呼ばれるバーにアイコンを並べ、現在起動しているアプリケーションや開いているドキュメント(すなわち、ウィンドウ)を外観できるようにしている。しかし、ウィンドウの数が増えると、多くのアイコンが並ぶこととなり、タスクバー上で所望のアイコンを探すことも大変になる。この問題に対処するため、Windowsでは、同じアプリケーション(例えば、Microsoft Word や Internet Explorer)で開いている複数のドキュメントをタスクバー上で一つにまとめてアイコン化している。
【０００４】
しかし、ここに１つ問題がある。ユーザがある目的を達成しようという行為(タスク)は、必ずしもアプリケーションと対応するわけではない。すなわち、１つのタスクが１つのアプリケーションで完結するわけではない。むしろ、１つのタスクの遂行に、複数のアプリケーションが必要になることの方が多い。例えば、技術論文を書く場合には、ワードプロセッサの他に、辞書、自分が読んだ論文、自分がこれまでに書いた自分の論文、図を作成するためのドローツールなどを同時に(対応するアプリケーションを同時に起動して)表示する。また、プログラミングを行う場合には、ソースコードを編集するエディタ、コンパイルやデバッグする環境、マニュアル、(必要に応じて検索できるよう)Web ブラウザなどが同時に利用される。メールを作成する場合には、メーラ、カレンダー、スケジュール管理システム、名簿管理システムなどが同時に利用される。さらに、これらタスクにおいて、個々のアプリケーションやドキュメントはユーザの好みに応じてデスクトップ上に並べられ、ユーザの作業空間を構成することになる。このようなユーザのタスクに対応した作業空間を、本明細書では、“ワークスペース”と呼ぶことにする。
【０００５】
通常、ユーザは、さまざまなタスクを並行して作業することが多い。メールを読み書きしてから、他人の論文を読み、さらには自分の論文を書くといった具合である。この際、タスクを切り替えるという作業は、しばしば厄介なものとなる。複数のアプリケーションやドキュメントをアクティブにするために何度もアイコンをクリックする必要が生じたり、同じドキュメントを異なるワークスペースで異なる位置に置けないという問題が生じたりする。ユーザが行いたいことは、タスク、すなわちワークスペースの切り替えであり、管理である。アプリケーションの切り替えや管理は、システム側の都合をユーザに押し付けているにすぎない。さまざまなアプリケーションやドキュメントをユーザの好みに応じて柔軟に配置することでワークスペースの構成を容易にし、タスク切り替えで生じるワークスペースの切り替えを簡単に行えるようにすることが必要である。
【０００６】
ユーザがワークスペースを構成し、その切り替えを容易にするための技術として、非特許文献１に示されたRoomsというシステムでは、部屋メタファーを利用し、ワークスペースの切り替えを支援している。アプリケーションやドキュメント (すなわち、ウィンドウ) の配置をRoomとして保存し、オーバービューでRooms を概観したり、Doorsを使ってRoom(ワークスペース)を切り替えたりする。
【０００７】
非特許文献１のRooms に似たアイデアを三次元に拡張して実現したシステムとして、Task Gallaryが非特許文献２に開示されている。Task Gallary では、壁に特定のウィンドウセットを置いておくなど、三次元の空間記憶を利用してタスク管理が可能である。
【０００８】
また、非特許文献３のScalable Fabricというシステムでは、大きなディスプレイの中央でユーザが主に作業を行うことを想定している。複数のウィンドウを同時に移動することが可能であり、中央の作業スペースからディスプレイの周辺領域にウィンドウを移動すると、ウィンドウ全体が小さくなる。脇に置かれたウィンドウ集合(ワークスペース)を再び中央に移動するとウィンドウ全体が大きくなり、以前の作業状態に戻る。このように、あるタスクの作業中も他のタスクの存在を (ウィンドウイメージの縮小図として) 認知することができ、ワークスペースの切り替えが容易になる。
【０００９】
Windows (登録商標) のタスクバーに工夫を施したものとして、非特許文献４および非特許文献５にはGroupBarというシステムが提案されている。デスクトップ上に表示している複数のウィンドウの状態をグループとしてまとめて保存し、再現できるようにしたものである。この際、タスクバー上ではウィンドウ毎にアイコンが表示されるのではなく、グループごとにアイコンが表示されるので、タスクバーにアイコンが溢れるという問題を回避できる。また、ワークスペースの切り替えはグループに対応するアイコンの切り替えとして容易に行える。
【００１０】
非特許文献６に示されるElastic Windowsでは、複数のウィンドウを入れ子で表示し、ワークスペースを階層的に管理できる。入れ子の下位構造に位置する複数のウィンドウが重なり合わないように配置を自動調整したり、複数のウィンドウに対して、一括した操作 (閉じる、移動する、最小化する、最大化するなど) ができるようになっている。
【００１１】
特許文献１は、複数のドキュメントを仮想的なボードに貼り付けて、再現できるようにする枠組みを提案している。ボードを開くことで、以前に電子ボードを閉じた状態が再現される。ボードをワークスペースのように扱うことにより、以前のワークスペースの状態を簡単に再現したり、切り替えたりできるようになる。
【００１２】
特許文献２には、複数の重なったウィンドウの大きさや位置を簡単な指示によって変更し、互いに重なり合うことのないように再配置する方式を提案している。最後に、特許文献３には、新しくウィンドウを開く際に、他のウィンドウと重なることがないようにウィンドウの位置を自動的に制御する方式を提案している。
【００１３】
【非特許文献１】S. K. Card and A. Henderson. "A multiple, virtual-workspace interface to support user task switching." in Proceedings of CHI, pp. 53-59, 1987.
【非特許文献２】G. Robertson, M. van Dantzich, D. Robbins, M. Czerwinski, K. Hinckley, K. Risden, D. Thiel, V. Gorokhovsky. "The Task Gallery: A 3D window manager." in Proceedings of CHI 2000, 494-501, 2000.
【非特許文献３】G. Robertson, E. Horvitz, M. Czerwinski, P. Baudisch, D. Hutchings, B. Meyers, D. Robins, G. Smith. "Scalable Fabric: Flexible task management," in Proceedings of AVI, pp. 85-89, 2004.
【非特許文献４】G. Smith, P. Baudisch, G. Robertson, M. Czerwinski, B. Meyers, D. Robbins, E. Horvitz, and D. Andrews. "GroupBar: The TaskBar evolved." in Proceedings of OZCHI '03, 2003.
【非特許文献５】M. Czerwinski, E. Horvitz, and S. Wilhite. "A diary study of task switching and interruptions." in Proceedings of CHI, pp. 175-182, 2004.
【非特許文献６】E. Kandogan and B. Shneiderman. "Elastic Windows: Improved spatial layout and rapid multiple window operations." in Proceedings of ACM Advanced Visual Interfaces (AVI), Gubbio, Italy, pp. 29-38, 1996.
【非特許文献７】E. Kandogan, B. Shneiderman. "Elastic Windows: Evaluation of multi-window operations." in Proceedings of CHI, pp. 250-257, 1997.
【特許文献１】特許第２７１５４２１号
【特許文献２】特開平１−７６１１４号
【特許文献３】特開平２−２８７１６号
【発明の開示】
【発明が解決しようとする課題】
【００１４】
上記した従来技術を以下の３つの評価基準から比較してみる。
１．ワークスペースの構築・切り替えが支援されるか否か。
２．ウィンドウの重なりをなくすよう、ウィンドウ間での調整がどの程度行われているか。
３．既存のアプリケーションが利用可能かどうか、可能ならどの程度の困難さで可能か。
【００１５】
【表１】
2008299689.tif 000003
【００１６】
これら従来技術に対して、本発明が解決しようとする課題は２つある。
１．ワークスペースの構築と切り替えに関する機能上の課題
２．既存アプリケーションを活用するための実現方式に関する課題
【００１７】
１．ワークスペースの構築と切り替えに関する機能上の課題
先に述べた従来研究のうち、ワークスペースの構築を可能とするものは、表１に示すように、Rooms（非特許文献１）、Task Gallery（非特許文献２）、 Scalable Fabric（非特許文献３）、 GroupBar（非特許文献４、５）、特許文献１、および Elastic Windows（非特許文献６）である。いかにタスク切り替えを容易にするか、いかにして以前のタスク状態に簡単に戻れるようにするか、そのためのユーザインタフェースを工夫するということがこれら技術の中心課題である。
【００１８】
ワークスペースの構築を可能とする上記の提案において、ワークスペースの構築方法について各々の技術の課題を説明する。
【００１９】
Rooms（非特許文献１）、特許文献１では、ウィンドウの配置に先立ち、部屋、またはボードを用意し、その上に必要なウィンドウを配置する必要がある。すなわち、ワークスペース構築に先立ち、「私はこれから××のワークスペースを構築します」ということをシステムに対して宣言する必要がある。
【００２０】
Task Gallery（非特許文献２）および GroupBar日特許文献４、５） では、ウィンドウを配置し、配置したウィンドウの状態を保存するという操作が必要になる。すなわち、ワークスペースを構築した後に、「私は構築した××をワークスペースとして保持します」ということをシステムに対して宣言する必要がある。
【００２１】
Scalable Fabric（非特許文献３） では、ウィンドウを配置するという行為がそのままワークスペースの構築につながるものの、現在作業中でないワークスペースを周辺のエリアに退避させるため、作業スペースがディスプレイの中央部分に制限されるという問題がある。
【００２２】
Elastic Windows（非特許文献６）では、ウィンドウの配置に先立ち、ウィンドウ内に入れ子の新しいウィンドウを次々と開いていく必要がある。
【００２３】
このように従来の技術はいずれも、ワークスペースの構築に際して、どこに何を置くかというウィンドウの配置に関する操作以外に「どれをワークスペースするか」という指定が必要である。あるいは、ディスプレイ領域を有効に活用できないという問題がある。望ましくは、ウィンドウを配置するという行為がそのままワークスペースの構築につながるような直感的なユーザインタフェースが望まれる。なお、このことは、ディスプレイ領域を有効に活用したうえで実現されることが望まれる。
【００２４】
さらには、Elastic Windows（非特許文献６）を除く従来技術は、単に複数のウィンドウの配置をワークスペースとして保持するだけで、ワークスペース内のウィンドウ配置について何ら調整を行うものではない。通常、一つのタスクを行うには複数のウィンドウの情報を参照する。この際、ウィンドウの重なりをなくしたり、無駄なスペースがなくなるようにウィンドウの並びを最適化することは、ユーザにとっては面倒な作業である。これら技術ではこれが支援されない。ウィンドウの重なりや無駄なスペースをなくすよう、ワークスペース内でのウィンドウ位置を自動的に調整する機能が望まれる。
【００２５】
２．既存アプリケーションを活用するための実現方式に関する課題
先にワークスペース内でのウィンドウが重ならないよう、ウィンドウ位置を自動調整することの必要性を述べた。特許文献２および特許文献３では、この問題を部分的に解決する。すなわち、ユーザからの指示、またはウィンドウを開くタイミングにおいてウィンドウ間の重なりがなくなるようにウィンドウ配置を調整する。しかし、その後にユーザがウィンドウを移動したり、サイズ変更を施した場合には、他のウィンドウが隠れてしまう可能性がある。
【００２６】
上記のウィンドウ配置の問題を解決するため、Elastic Windows（非特許文献６）は、ウィンドウを階層的に管理し、ユーザによるウィンドウの移動、サイズ変更に伴って、他のウィンドウの再配置を行う。この枠組みでは、ウィンドウ間の連携が密になっているため、既存のアプリケーションを取り扱うことができない。Elastic Windows上に独自に構築したアプリケーションしか動作させることができないという点が問題である。
【００２７】
ワークスペース管理方式では、その枠組み上で既存のアプリケーションも (できれば既存アプリケーションに変更を施すことなく、変更が必要であってもできるだけ少なく) 取り扱えることが望まれる。
【００２８】
本発明は、このような従来技術に鑑み、ウィンドウの重なりや無駄なスペースのないワークスペースを構成するための直感的なユーザインタフェースを提供することを目的とする。
さらに本発明は、既存システムに対するできるだけ少ない変更を加えることで、複数のウィンドウの配置を再現することでワークスペースの構成を可能にし、かつ各ワークスペース内でウィンドウが重なり合うことのないようにウィンドウ配置の調整を可能にすることを目的とする。言い方を変えるなら、本発明は、既存システムへの変更をできるだけ少なくし、従来技術に対する３つの評価基準の全てを満足させること、さらにはそのための簡易で直感的なユーザインタフェースを提供することを狙いとする。
【課題を解決するための手段】
【００２９】
本発明に係るワークスペース管理方法は、アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するものであって、ディスプレイ上に表示された複数のウィンドウに関する管理情報を管理する管理ステップと、ウィンドウの状態の変化を検出する検出ステップと、前記検出ステップにより複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍または重複する他のウィンドウを検出するウィンドウ検出ステップと、ウィンドウ検出ステップにより他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウのそれぞれにドッキングされる位置を表示する表示ステップと、前記検出ステップにより前記１つのウィンドウの移動の停止が検出されたとき、前記１のウィンドウを前記他のウィンドウに前記ドッキング位置を介してドッキングするドッキングステップとを含む。
【００３０】
ウィンドウのドッキングは、ウィンドウの結合を意味する。また、ドッキング位置の表示態様は、例えば、ウィンドウの辺の形状が変化したり、ウィンドウの辺の色彩が変化したり、あるいは、ウィンドウの辺の形状と色彩の双方が変化したりすることができる。例えば、ウィンドウにのりしろを表示することができる。これ以外にも、ユーザが視覚的にドッキング位置を認識できる態様であればよく、付加的に他の色彩や形状等のイメージを付加するものであってもよい。
【００３１】
複数のウィンドウは、それぞれ異なるアプリケーションによって起動されるが、これはアプリケーションが複数であることを意味し、複数のアプリケーションは、同一のものであってもよいし、異なるものであってもよい。
【００３２】
好ましくは複数のウィンドウは矩形状であり、前記１つのウィンドウは、他のウィンドウの１辺のサイズに適合するサイズでドッキングされ、ドッキングされたウィンドウは矩形状である。また、表示ステップは、他のウィンドウが複数だるとき、１つのウィンドウと複数の他のウィンドウの各々の少なくとも２辺にのドッキング位置を表示するようにしてもよい。
【００３３】
ワークスペース管理方法はさらに、前記検出ステップによりドッキングされたウィンドウに含まれるサブウィンドウのサイズが変更されたことが検出されたとき、前記管理情報を参照してドッキングされたウィンドウに含まれる他のサブウィンドウのサイズを同時に変更するサイズ変更ステップを含むことができる。
【００３４】
ワークスペース管理方法はさらに、前記検出ステップによりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを全体として移動するステップを含むことができる。
【００３５】
本発明に係るワークスペース管理方式（および管理プログラム）は、アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するものであって、ディスプレイ上に表示された複数のウィンドウに関する管理情報を記憶するウィンドウ管理手段と、ウィンドウの状態の変化を検出する検出手段と、前記検出手段により複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍または重複する他のウィンドウを検出するウィンドウ検出手段と、ウィンドウ検出手段により他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウがドッキング可能であることを提示する提示手段と、前記検出手段により前記１つのウィンドウの移動の停止が検出されたとき、前記１つのウィンドウを前記他のウィンドウに前記提示されたドッキング位置を介してドッキングするドッキング手段とを有する。
【００３６】
好ましくは管理情報は、少なくともウィンドウを識別する識別情報、ウィンドウの位置情報、ウィンドウのサイズ情報を含み、さらに、ドッキングされたウィンドウの識別情報、位置情報およびサイズ情報を含む。好ましくは、提示手段は、前記１つのウィンドウが前記他のウィンドウにドッキングされる位置を表示する表示手段を含み、表示手段は、ウィンドウの特定の辺に他の辺と識別可能な表示を与えることができる。好ましくは、検出手段は、定期的にアクティブなウィンドウの状態を監視し、アクティブなウィンドウのイベントの変化を検出する。あるいは、検出手段は、ウィンドウに対して操作されたイベントの種類を検出するようにしてもよい。好ましくは、複数のウィンドウは、それぞれ異なるアプリケーションによって起動される。
【００３７】
ワークスペース管理方式はさらに、ドッキングされたウィンドウの状態を保存する状態保存手段と、前記状態保存手段により保存された状態に基づきドッキングウィンドウを再現する状態再現手段とを含むことができる。
【００３８】
さらに本発明のワークスペース管理方式は、アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するものであって、１つのウィンドウを他のウィンドウにドッキングするドッキング手段と、ドッキングされたドッキングウィンドウ内のサブウィンドウに対する操作履歴情報を保持する利用履歴保持手段と、前記操作履歴情報に基づきドッキングされたウィンドウ内のサブウィンドウの配置を推薦する配置推薦手段とを有する。
【００３９】
好ましくは、配置推薦手段は、前記操作履歴情報に基づき少なくともサブウィンドウの利用頻度またはサブウィンドウ間の類似度を算出し、その算出結果に応じてサブウィンドウの配置を決定する。
【００４０】
さらに本発明に係るワークスペース管理方式（およびプログラム）は、アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するものであって、ディスプレイ上に表示された複数のウィンドウに関する管理情報を記憶するウィンドウ管理手段と、ウィンドウの状態の変化を検出する検出手段と、前記検出手段により複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍または重複する他のウィンドウを検出するウィンドウ検出手段と、ウィンドウ検出手段により他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウのそれぞれにドッキングされる位置を表示する表示手段と、前記検出手段により前記１つのウィンドウの移動の停止が検出されたとき、前記１つのウィンドウを前記他のウィンドウに前記ドッキング位置を介してドッキングするドッキング手段とを有する。
【発明の効果】
【００４１】
本発明によれば、次のような効果を得ることができる。
（ａ）ウィンドウによるワークスペースを構築する操作が、従来のもの比べて直感的で簡単である。
（ｂ）ワークスペースにおけるウィンドウ配置を自動化することで、ウィンドウ配置が容易になり、無駄なスペースをつくることなく、限られたディスプレイ空間を有効に利用できる。
【発明を実施するための最良の形態】
【００４２】
以下、本発明のワークスペース管理方式の基本的なアイデアについて図面を参照して説明する。本発明のアイデアは、主に２つに大別される。
１．ワークスペースの構築、切り替えを支援するユーザインタフェース
２．１のユーザインタフェースを実現するためのアーキテクチャであり、既存のアプリケーションを発明の枠組みにできるだけ簡易に取り込むための実現方式
【００４３】
１．ユーザインタフェースとその動作
図１Ａは、ディスプレイ上に２つのウィンドウＡ、Ｂが表示され、ウィンドウＡの近くにウィンドウＢがドラッグされている状態を示している。ウィンドウＡ、Ｂは、それぞれ別々のアプリケーションソフトウエアをコンピュータのオペレーティングソフトウエア上で実行することによりディスプレイ上に表示されたものであり、ウィンドウＢは、マウス等の入力装置によって選択され、ドラッグ（移動）される。ウィンドウＡとウィンドウＢがある程度の近さになると、両者がドッキング可能であることを示すギザギザののりしろ１０、１２がウィンドウＡ、Ｂの対向する辺にそれぞれ表示される。この状態で、ウィンドウＢをドロップ（移動を停止）すると、図１Ｂに示すように、両ウィンドウＡ、Ｂはドッキングし、１つのウィンドウになる。この際、ウィンドウＢのサイズは、ウィンドウＡののりしろが表示された辺のサイズに適合するサイズに調整される。
【００４４】
ここで、ドッキングされたウィンドウ（以下、ドッキングウィンドウという）は、ドッキングされていない通常のウィンドウ（以下、非ドッキングウィンドウという）と類似の振る舞いをする。
（ａ）ドッキング後のウィンドウの形は、長方形または矩形状である。
（ｂ）ドッキング後のウィンドウは、一緒になって移動する。つまり、タイトルバーをドラッグすることで、ウィンドウＡ、Ｂ両方が同時に移動する。
（ｃ）ドッキングウィンドウに含まれる個々のサブウィンドウに対して、同時にクローズ、最大化、最小化をすることができる。
【００４５】
また、ドッキングウィンドウは、複数のウィンドウの集合体であるため、以下のような点が通常のウィンドウと異なる。
（ａ）特定のサブウィンドウのサイズを変更することで、他のサブウィンドウ (さらには、全体を統括するドッキングウィンドウ) のサイズも変化する。
（ｂ）ドッキングの解除が可能である。全体を解除する場合もあるだろうし、特定のサブウィンドウだけを解除する場合もあるだろう。
（ｃ）必要に応じて、ドッキングされたことを示すよう、タイトルバーの表示を通常のウィンドウの表示と異ならせてもよい。
（イ）通常の「最小化」、「最大化」、「閉じる」のボタンに対して、「ドッキング解除」のボタンを加える。
（ロ）ウィンドウのアイコンを特殊なものに変える。
（ハ）タイトルバーの背景の色を変える。
【００４６】
次に、サブウィンドウのサイズを変更した場合の動作について説明を行う。図２は、サブウィンドウＢのサイズを変更することで、ウィンドウＡのサイズも変更し、同時に(ウィンドウＡ、Ｂを含めた)ドッキングウィンドウ全体のサイズが変化することを示している。図２Ａに示すように、ウィンドウＢを拡大（高さおよび幅が広がる）すると、図２Ｂに示すように、ウィンドウＡの高さが変化する。但し、ウィンドウＡの幅は変化しない。
【００４７】
図３は、サブウィンドウＡ、Ｂ、Ｃがドッキングされたウィンドウにおいて、ウィンドウＡの幅を広げている。図３Ａに示す状態からサブウィンドウＡの幅が広がると、図３Ｂに示すように、ウィンドウＢとＣは、幅の比率を保持した状態で縮小する。
【００４８】
図４は、サブウィンドウＡ、Ｂ、Ｃ、Ｄがドッキングされたウィンドウにおいて、サブウィンドウＡの幅を拡大している。図４Ａに示す状態からサブウィンドウＡを拡大すると、図４Ｂに示すように、それに応じてウィンドウＣとＤの幅は、縮小している。同時にウィンドウＢの幅は、拡大している。
【００４９】
本発明では、ドッキングしたウィンドウをワークスペースのように利用することを想定する。その意味で、ドッキングウィンドウとワークスペースをしばしば同義で扱う。
【００５０】
２．アーキテクチャ (実現方式)
本発明の上記したアイデアの枠組み(Docking Window Framework (DWF) と呼ぶことにする)を実現するにあたり、オペレーティングシステム（ＯＳ）に機能を追加するだけでDWFを実現することができれば、次のような観点から都合がよい。
（ａ）既存のアプリケーション(例えば、Microsoft Office のアプリケーションなど)に一切の変更を施すことなく、DWFの利点を得ることができる。
（ｂ）システムにバグがあっても、ＯＳに追加したモジュールのみを置き換えればよく、アプリケーションごとに置き換えをする必要がない。このことは、システムのバージョンアップについてもいえる。
【００５１】
しかし、一般にはこのようなことは難しい。アプリケーションの外から、アプリケーションのウィンドウでどういうイベントが発生され、ウィンドウがどういう状態にあるかを知ることが困難なためである。ここでは、この対処法として、２つの方式を提案する。ここで、ＯＳに追加されたウィンドウを管理するモジュールを「マネージャ」と呼ぶことにする。
【００５２】
方式Ａ(イベント検出方式)：イベント検出方式は、マネージャで定期的に全てのウィンドウの状態をチェックし、ウィンドウ状態に変化があった場合、変化の種類からイベントの種類を特定する。
方式Ｂ(イベント通知方式)：イベント通知方式は、各ウィンドウでウィンドウ状態に変更があった場合、ウィンドウからマネージャにイベントが生じたことを通知する。
【００５３】
イベント検出方式は、アプリケーション側には一切の変更を施すことなくDWFを実現できる。しかし、以下のような問題を伴うことになる。
（ａ）マネージャが定期的に全てのウィンドウの状態をチェックするため、コンピュータのリソースを大幅に使うことになる。
（ｂ）定期的なチェックによりイベントを検出するため、実際のイベントの発生からイベントを検知するまでにタイムラグが生じることになる。これが、DWF全体の振る舞いに遅延をもたらすことになる。もちろん、チェックの周期を小さくすることで問題は軽減できるが、周期を小さくすればするほどコンピュータのリソースが消費されることになる。
【００５４】
イベント通知方式は、各アプリケーション側で「必要なタイミングでマネージャにイベントがあったことを通知する」という処理を行う必要がある。すなわち、アプリケーションごとに変更を施すことが必要となる。もちろん、変更は少なければ少ないほどよい。また、マネージャでの機能変更のたびに全てのアプリケーションに変更を施すことも大変であるから、各アプリケーションで実装すべき機能は普遍的(機能変更に対して頑強)であることが望ましい。そこで、アプリケーション側が備えるべき最小限の機能として、「特定のイベントが発生したら、そのことをマネージャに通知する」ことを提起する。ここで重要なことは、アプリケーション側では、イベントの発生をマネージャに知らせるのみで、(マネージャとの双方向通信を含め) それ以外のことは一切行わないということであり、それさえ行えばその他のことは全てマネージャが対処してくれるということである。なお、実施例にて詳細に述べるが、送るべきイベントの種類は、最小限の構成として次があげられる。
【００５５】
アプリケーション起動「Execute」
アプリケーション終了「Exit」
ウィンドウがアクティブ「Active」
ウィンドウの移動「Move」
ウィンドウのドロップ(移動の終了)「Drop」
ウィンドウのサイズ変更「Resize」
【００５６】
実際のところ、Executeに対応させてExitもリストに加えているが、Exitに関しては絶対に必要というわけではない。あった方がスマートであるが、必須ではない。具体的に述べると、Exitが検出できないと、ウィンドウのクローズに対応してテーブルからウィンドウを削除することができないから、ウィンドウがどんどん大きくなっていく。これは処理の増大を招く。また、ウィンドウの「最大化」「最小化」「元に戻す」への対処として、Resize イベントを細分化する可能性もある。参考までに、これらイベントのいくつかはマネージャ側で自動的に検出し、他のものをアプリケーション側から通知するという可能性もある。
【００５７】
ドッキングの種類
図１に示すドッキングは、ドッキングされるウィンドウＡの外側に、ドッキングしたウィンドウＢがくっつく(Ａの外側にＢがはみ出る)かたちでドッキングが行われた。このようなドッキングを「拡張ドッキング」と呼ぶことにする。これに対して、図５Ａ、Ｂに示すドッキングは、ウィンドウＡ、Ｂのドッキングウィンドウに対して、ウィンドウＣがウィンドウＢの領域に割り込むようにドッキングされている。このように既存のウィンドウに入り込むかたちでのドッキングを、「埋め込みドッキング」と呼ぶことにする。
【００５８】
次に、拡張ドッキングと埋め込みドッキングの違いについて説明を加える。第１に、拡張ドッキングは、ドッキングの前後でウィンドウの大きさが変化するのに対して、埋め込みドッキングは、ドッキングの前後でウィンドウの大きさが変化しない。第２に、拡張ドッキングでは、「のりしろ」が表示されるのは、各ウィンドウ毎に１辺のみであるのに対して、埋め込みドッキングでは、各ウィンドウ毎に２辺以上の「のりしろ」が表示される。図５Ａに示すように、ドッキングされたウィンドウＡとＢの各辺にのりしろ１４ａ、１４ｂが表示され、ウィンドウＣの左端、上端にのりしろ１６が表示されているのがそれにあたる。
【００５９】
本発明の最大の特徴は、単独で利用できるアプリケーションをドッキングという操作を通してワークスペースを構成できることにある。従来のように、ウィンドウを並べて配置を保存するということではなく、配置するという操作そのものがワークスペースを構成することにつながる。すなわち、ワークスペースの作成が直感的であり、その結果についてのフィードバックも即座に得られる。なお、その実現における特徴は、既存のアプリケーションに対する変更なく、または変更が少なく、ワークスペースの管理が行える点である。
【００６０】
さらに本発明のワークスペース管理方式は、次のように応用することが可能である。
ドッキングウィンドウに対するインタラクション
（ａ） ワークスペース内の特定のウィンドウを大きくしたり、小さくしたりする。相対的に他のものは小さくなったり、大きくなったりする。最大化、最小化ではなく、拡大、縮小に対応する。
（ｂ）ワークスペース内の特定のウィンドウをシュリンクする。相対的に他のものは大きくなる。
（ｃ）ドッキングウィンドウの状態 (サブウィンドウのアプリケーションと位置関係)を保存し、再現することができる。
（ｄ）ドッキングウィンドウのドキュメント状態 (ウィンドウ状態に加え、各ウィンドウで開いているドキュメント、スクロール位置、カーソル位置など) を保存し、再現することができる。
【００６１】
ワークスペースを構成するウィンドウをシステムが自動で探して候補を提示
本発明を用いたフレームワークをユーザが始めて利用する場合に、ワークスペース構築支援として利用できるだろうし、通常の利用において、ウィンドウをドッキングした際、他に候補となりえるウィンドウを自動的に推薦してもよい。ドッキング候補のアプリケーションやドキュメントは以下のように収集すればよい。
（ａ）ドキュメントの日時属性(作成、更新、参照)が近いもの
（ｂ）かつて一緒に利用したことのあるドキュメント
（ｃ）他のワークスペースで一緒に利用されているドキュメント
【００６２】
ワークスペースにおけるウィンドウ配置において、システムが最適な配置方法を提示
（ａ）ワークスペース内でのユーザの振る舞いにおいて、アクティブなサブウィンドウがどのように推移するかを分析し、適切なウィンドウ配置を推薦する。
（イ）操作の移動や目線移動は少ない方が望ましい。
（ロ）操作は左から右、上から下に移動することが望ましい。
（ハ）頻繁に操作の切り替えが起こるサブウィンドウは隣り合うことが望ましい。
【実施例】
【００６３】
次に、本発明の実施例に係るワークスペース方式ついて説明する。本実施例に係るワークスペース方式は、例えば、パーソナルコンピュータに搭載されたＯＳ上で実行可能なアプリケーションソフトウエアまたはＯＳに組み込まれたプログラムとして実行可能である。
【００６４】
以下の説明では、初めに、１．イベント検出と、２．イベント通知方式の２つのイベント処理方式について述べる。次に、その発展として、３．ウィンドウ状態、ドキュメント状態の保存と再現を行うシステムの実施例を示す。次に、４．ドッキング対象のウィンドウ候補を自動的に提示するシステムの実施例、５．ワークスペース内の最適なウィンドウ配置を提示するシステムの実施例を示す。最後に、６．埋め込みドッキングの実施例を示す。なお、上記の実施例例では、ドッキング方法として、拡張ドッキングを前提として説明している。埋め込みドッキングについては、最後に説明する。なお、拡張ドッキングを単にドッキングと述べるので注意されたい。
【００６５】
１．イベント検出方式
イベント検出方式では、個々のアプリケーションのウィンドウには一切の変更を施す必要はなく、マネージャが全ての処理を行う。また、イベントの検出において、Exitイベントは検出しないものとする。
【００６６】
図６は、イベント検出方式の構成を示すブロック図である。同図に示すように、イベント検出方式を実行するマネージャ１００は、ウィンドウをドッキングするドッキング手段１１０、ドッキングされるウィンドウにのりしろを表示するのりしろ表示手段１２０、ドッキング対象となる近隣のウィンドウを検出する近隣ウィンドウ検出手段１３０、イベント検出手段１４０およびウィンドウ管理手段１５０を含んでいる。
【００６７】
イベント検出手段
まずは、イベント検出手段１４０から説明する。イベント検出手段１４０は、定期的にアクティブなウィンドウ状態を取得し、ウィンドウ・イベント・テーブルを参照しながら以前のウィンドウ状態と比較することにより、イベントの検出を行う。
【００６８】
ウィンドウ・イベント・テーブルのデータ構造を表２に示す。ウィンドウ・イベント・テーブルは、以下のカラムをもつ。
「ウィンドウＩＤ」は、ウィンドウの識別子を保持する。
「位置」は、ウィンドウの左上の座標を保持する。
「サイズ」は、ウィンドウの幅と高さを保持する。
「アクティブ」は、ウィンドウが現在アクティブか否かを示すフラグを保持する。
「イベント」は、アクティブなウィンドウに対して直前に発生したイベントを保持する。
【００６９】
【表２】
2008299689.tif 000004
【００７０】
図７にイベント検出手段の動作フローを示す。同図に示すように、イベント検出手段１４０は、定期的にアクティブウィンドウＷのウィンドウＩＤ(id)、位置(position)、およびサイズ(size)を取得する(ステップＳ１０)。そして、アクティブウィンドウＷが、ウィンドウ・イベント・テーブルに既に登録されているか否かをチェックする（ステップＳ１１）。
【００７１】
アクティブウィンドウＷがテーブルに登録されていないなら、ウィンドウが初めてアクティブになったことがわかるから、イベントは、「Execute」であることがわかる。イベント「Execute」を検出し（ステップＳ１２）、これをウィンドウ・イベント・テーブルにアクティブウィンドウＷのアイテムを追加して終了する。
【００７２】
アクティブウィンドウＷがテーブルに既にあるなら、テーブルからＷがアクティブか否かを取得する（ステップＳ１３）。テーブルのＷがアクティブでなかったら、今回のチェックでアクティブになったからイベント「Active」を検出する（ステップＳ１４）。そして、テーブルの書き換えを行って終了する（ステップＳ１５）。
【００７３】
テーブルのＷが既にアクティブであったら、少なくとも今回始めてアクティブになったわけではないことがわかる。次は、テーブルから以前のサイズ「size_ old」を取得して、アクティブウィンドウＷの現在のサイズ「size」と比較し、サイズ変更されているか否かをチェックする（ステップＳ１６）。「size」と「size_old」の値が異なるなら、アクティブウィンドウＷのサイズが変更されたことがわかるため、イベント「Resize」を検出する（ステップＳ１７）。そして、テーブルの書き換えを行って終了する。
【００７４】
「size」と「size_old」の値が同じなら、サイズ変更が行われたわけではないことがわかる。今度は、テーブルから以前の位置「position_old」を取得して、アクティブウィンドウＷの現在の位置「position」と比較し、位置が変更されているか否かをチェックする（ステップＳ１８）。
【００７５】
「position」と「position_old」が異なる場合、ウィンドウ位置が変更されたことがわかるため、イベントMoveを検出する（ステップＳ１９）。「position」と「position_old」が同じなら、移動は行われなかったことがわかる。この場合、テーブルから以前のイベントを取得し、以前のイベントがMoveであったか否かをチェックし（ステップＳ２０）、Moveの場合は、今回のチェックでMoveが終了したことがわかるから、イベントDropを検出する（ステップＳ２１）。
【００７６】
以上の要領でイベントの検出を行なったら、イベントが検出された場合もされなかった場合もウィンドウ・イベント・テーブルの書き換えが必要である（ステップＳ２２）。まずは、テーブルの「アクティブ」カラムと「イベント」カラムを全てクリアする。次いで、「アクティブ」カラムのWの行をチェックする。さらに、イベントが検出された場合には、Wの「イベント」カラムに検出されたイベントを書き込む。
【００７７】
ウィンドウ管理手段
「ウィンドウ管理手段」は、個々のウィンドウのイベント送信手段からイベントメッセージを受け取ったら、「ウィンドウテーブル」「ドッキングテーブル」を参照し、必要なウィンドウに操作を行う。まずは、ウィンドウテーブル、ドッキングテーブルのデータ構造を説明し、次いでウィンドウ管理手段の振る舞いを示す。
【００７８】
「ウィンドウテーブル」は、起動中の全てのウィンドウを管理する。そのデータ構造を表３に示す。ウィンドウテーブルは、以下のカラムをもつ。
「ウィンドウＩＤ」は、ウィンドウのＩＤを保持する。
「位置」は、各ウィンドウの左上の座標を保持する。
「サイズ」は、各ウィンドウの幅と高さを保持する。
「ドッキングＩＤ」は、ウィンドウがドッキングされている場合、ドッキングされているウィンドウのウィンドウＩＤの集合を保持する。ウィンドウがどのウィンドウともドッキングされていない場合、このカラムは空になる。
【００７９】
【表３】
2008299689.tif 000005
【００８０】
表３では、７つのウィンドウが現在ＰＣ上で開かれており、そのうち、W003, W004がドッキングされており(ドッキングの情報は、ドッキングテーブルの D001 の行にある)、また、W005, W006, W007もまたドッキングされていることを示している(ドッキングの情報は、ドッキングテーブルの D002 の行にある)。
【００８１】
「ドッキングテーブル」は、起動中の全てのドッキングウィンドウを管理する。そのデータ構造を表４に示す。ウィンドウテーブルは、以下のカラムをもつ。
「ドッキングＩＤ」は、ドッキングウィンドウのＩＤを保持する。
「位置」は、各ドッキングウィンドウの左上の座標を保持する。
「サイズ」は、各ドッキングウィンドウの幅と高さを保持する。
「ドッキング集合」は、ドッキングされているウィンドウのウィンドウＩＤの集合を保持する。
【００８２】
【表４】
2008299689.tif 000006
【００８３】
表４では、現在起動中のドッキングウィンドウが２つあり、一方は２つのサブウィンドウから、他方は３つのサブウィンドウから構成されることを示している。
【００８４】
ウィンドウ管理手段に話を戻すと、ウィンドウ管理手段は、ウィンドウＷのイベント送信手段からイベントメッセージを受けると、受け取ったイベントの種類に応じて、ウィンドウテーブルやドッキングテーブルを参照し、必要なウィンドウに対して必要な処理を行う。各々のイベント毎の動作を示す。
【００８５】
Executeの場合
Executeイベントを検出したときの動作フローを図８に示す。Ｗがドッキングウィンドウか否かによって動作が異なる。Ｗがドッキングウィンドウか否かをチェックし（ステップＳ２０）、ドッキングウィンドウの場合、ドッキングテーブルからＷの位置、サイズを取得し（ステップＳ２１）、ドッキングテーブルにＷの情報(ID、位置、サイズ、サブウィンドウの集合)を追加し（ステップＳ２２）、ウィンドウテーブルからサブウィンドウの位置、サイズを取得し（ステップＳ２３）、ウィンドウテーブルにサブウィンドウの情報を追加する（ステップＳ２４）。Ｗが非ドッキングウィンドウの場合は、Ｗのサイズを取得し（ステップＳ２５）、単にウィンドウテーブルにＷの情報を追加する（ステップＳ２６）。
【００８６】
Moveの場合
Moveイベントを検出したときの動作フローを図９に示す。まずは、Ｗの位置を取得し（ステップＳ３０）、ウィンドウテーブルにおけるＷの情報を更新する（ステップＳ３１）。Ｗがドッキングされているか否かチェックし（ステップＳ３２）ドッキングされている場合には、Ｗとドッキングされている他のウィンドウを探し、ウィンドウ位置を再計算する（ステップＳ３３）。次いで、Ｗとドッキングされている他のウィンドウについて、ウィンドウテーブルでの位置情報およびドッキングテーブルでの対応する情報を更新する（ステップＳ３４）。さらに、近傍ウィンドウ検出手段において、ウィンドウテーブルを参照し、近傍にウィンドウが存在するか否かを探す（ステップＳ３５）。近傍のウィンドウがあった場合は、のりしろ表示手段においてのりしろを表示する（ステップＳ３６）。近傍のウィンドウがなかった場合は、のりしろ表示手段においてのりしろを非表示する（ステップＳ３７）。
【００８７】
Dropの場合
Dropイベントを検出したときの動作フローを図１０に示す。まずは、Ｗの位置、サイズを取得する（ステップＳ４０）。次いで、近傍ウィンドウ検出手段において、Ｗの近傍ウィンドウを探す（ステップＳ４１）。近傍ウィンドウが存在しなかった場合には何もせず終了する。近傍ウィンドウＷ’があった場合には（ステップＳ４２）、ドッキング手段において、ＷとＷ’の位置、サイズを再計算し、ウィンドウ位置を設定し、両者をドッキングする（ステップＳ４３）。さらに、ウィンドウテーブルにおける ＷとＷ’の位置およびサイズの情報を更新し（ステップＳ４４）、ドッキングテーブルにおける情報も更新する（ステップＳ４５）。
【００８８】
Resizeの場合
Resizeのイベントを検出したときの動作フローを図１１に示す。まずは、Ｗの位置を取得し（ステップＳ５０）、テーブルウィンドウにおけるＷの情報を更新する（ステップＳ５１）。Ｗが他のウィンドウとドッキングしているか否かをチェックし（ステップＳ５２）、ドッキングしていない場合には、処理を終了する。Ｗが他のウィンドウとドッキングしている場合には、ドッキングしているＷ以外のウィンドウについて、位置とサイズを再計算し、ウィンドウ位置を設定する（ステップＳ５３）。さらに、ウィンドウテーブルにおけるＷとドッキングしているＷ以外のウィンドウの情報を更新し（ステップＳ５４）、ドッキングテーブルにおける Ｗの位置とサイズの情報を更新する（ステップＳ５５）。
【００８９】
近傍ウィンドウ検出手段
ウィンドウＷが移動中(ＷでイベントMoveが検出されている最中)の「近傍ウィンドウ検出手段」の動作を説明する。図１２に示すように、ウィンドウの四辺の位置を示すために、図のように、上をトップ（Top）、下をボトム（Bottom）、左を）レフト（Left）、右をライト（Right）と呼ぶことにする。
【００９０】
２つのウィンドウがドッキングできるのは、ウィンドウの位置関係が以下の組のいずれかの場合である。
ライト（Right）?レフト（Left）
トップ（Top）?ボトム（Bottom）
【００９１】
すなわち、ウィンドウＷは、以下のケースでウィンドウＸとドッキングの可能性がある。
Ｗのライト（Right）とＸのレフト（Left）
Ｗのレフト（Left）とＸのライト（Right）
Ｗのトップ（Top）とＸのボトム（Bottom）
Ｗのボトム（Bottom）とＸのトップ（Top）
【００９２】
上記のウィンドウ位置の距離が、ある一定のしきい値より小さいようなＸをＷの「近傍ウィンドウ」と呼ぶことにする。ここで、Ｗの近傍ウィンドウを探すにあたり、まずはドッキングテーブルに対してＷの近傍ウィンドウを探す。あったらそれを返す。なかったら、今度はウィンドウテーブルに対して近傍ウィンドウを探す。こうして、ドッキングウィンドウまたはドッキングされていない単独のウィンドウに対して、Ｗの近傍ウィンドウをただ一つ探す。
【００９３】
のりしろ表示手段
移動中のＷに対して、近傍ウィンドウ検出手段で近傍ウィンドウＸが検出されたら、のりしろ表示手段は、ＷとＸの両脇に「ＷとＸがドッキング可能」であることを示すのりしろを表示する。ＸがＷの近傍ウィンドウであり、Ｗのレフト（Left）とＷのライト（Right）が接近している場合、のりしろ表示手段は、図１３Ａに示すように、ウィンドウＸにのりしろ２０を、ウィンドウＷにのりしろ２２を表示する。のりしろの表示態様は、例えば、ウィンドウの辺の形状が変化したり、ウィンドウの辺の色彩が変化したり、あるいは、ウィンドウの辺の形状と色彩の双方が変化したりするようにしてもよい。これ以外にも、ユーザが視覚的にドッキング位置を認識できる態様であればよく、付加的に他の色彩や形状等のイメージを付加するものであってもよい。
【００９４】
ドッキング手段
ウィンドウＷからDropイベントが検出された場合、ウィンドウ管理手段は、Ｗの近傍ウィンドウを探す。Ｗの近傍ウィンドウＸが存在する場合、「ドッキング手段」により、実際にＷとＸのドッキング処理が行われる。
【００９５】
ドッキング処理では、Ｗのどの辺がドッキング対象(この辺の位置を「ドッキング位置」と呼ぶことにする)なのかにより動作が異なる。
Ｗのドッキング位置がレフト（Left）の場合；
Ｗの高さを、Ｘの高さと同じにし、Ｘの左にＸと接するようＷを移動させる (図 １３Ｂを参照)。
Ｗのドッキング位置がライト（Right）の場合；
Ｗの高さを、Ｘの高さと同じにし、Ｘの右にＸと接するようＷを移動させる。
Ｗのドッキング位置がトップ（Top）の場合；
Ｗの幅を、Ｘの幅と同じにし、Ｘの下にＸと接するようＷを移動させる。
Ｗのドッキング位置がボトム（Bottom）の場合；
Ｗの幅を、Ｘの幅と同じにし、Ｘの上にＸと接するようＷを移動させる。
【００９６】
２．イベント通知方式
本実施例では、ウィンドウ間のデータやタイミングのやり取りはイベントドリブンにて行うことを前提とするが、実施の形態はイベントドリブンのみに限定されるものではない。メモリやファイルを介して行ってもよい。とりあえず、何らかの手段で、各ウィンドウからマネージャに対してメッセージを送信する。
【００９７】
図１４に、本実施例のイベント通知方式のシステム構成を示す。同図に示すように、イベント通知方式は、個々のウィンドウ毎にイベント送信手段２００をもつ。さらに、ウィンドウを統括するマネージャ２１０は、ウィンドウ管理手段２２０、近傍ウィンドウ検出手段２３０、のりしろ表示手段２４０、およびドッキング手段２５０を含んで構成される。
【００９８】
先の実施例との構成の違いは、各ウィンドウに「イベント送信手段」が加わり、マネージャから「イベント検出手段」がなくなったことである。よって、本実施例では、イベント送信手段２００の動作とウィンドウ管理手段２２０の相違点を説明する。
【００９９】
イベント送信手段
イベント送信手段２００は、自分のウィンドウに以下のような操作が生じた際に、そのイベントをウィンドウ管理手段２２０に送信する。先の実施例では、Exitイベントの検出を行なわなかったが、本実施例では各ウィンドウからExitイベントも送信されるものとする。
【０１００】
イベント送信手段２００がウィンドウ管理手段２２０に送信するイベントメッセージのデータ構造に表５に示す。表５では、ウィンドウＩＤが W001のウィンドウからMoveのイベントが送られたことを示している。
「ソースウィンドウ」は、イベントを送信するウィンドウのウィンドウIDを保持する。
「イベントの種類」は、送信するイベントの種類を示す。
【０１０１】
【表５】
2008299689.tif 000007
【０１０２】
ウィンドウ管理手段
ウィンドウ管理手段２２０は、基本的には上記したイベント検出方式と同じである。ただし、Exitイベントの管理が新たに加わっているから、その差分のみを説明する。
【０１０３】
ウィンドウ管理手段２２０でExit以外のイベントを受信した場合は、イベント検出方式の実施例での動作と同じである。Exitイベントを受信した場合の動作を説明する。
【０１０４】
Exitの場合
Exitイベントを検出したときの動作フローを図１５に示す。Ｗがドッキングウィンドウか否かによって動作が異なる。Ｗがドッキングウィンドウか否かをチェックし（ステップＳ６０）、Ｗがドッキングウィンドウの場合、ウィンドウテーブルからＷのサブウィンドウの情報を削除し（ステップＳ６１）、次いで、ドッキングテーブルからＷの情報を削除する（ステップＳ６２）。Ｗが非ドッキングウィンドウの場合は、単にウィンドウテーブルからＷの情報を削除する（ステップＳ６３）。
【０１０５】
先にも述べたが、Exitイベントを受信して、クローズされたウィンドウをウィンドウテーブル、ドッキングテーブルから削除することで、テーブルのサイズが小さくなる。これは、処理の効率化へとつながる。
【０１０６】
３．ウィンドウ状態／ドキュメント状態の保存と再現のシステム
まずは、ウィンドウの状態保存において、２つの保存形態があることを明記しておく。
ウィンドウ状態の保存
ウィンドウ状態の保存では、以下の情報を保持する。
個々のウィンドウのアプリケーション
個々のウィンドウの位置とサイズ
【０１０７】
ドキュメント状態の保存
ドキュメント状態の保存では、ウィンドウ状態に加え、以下の情報を保持する。
個々のウィンドウで開いているドキュメント
個々のウィンドウでのスクロール位置
個々のウィンドウでのカーソル位置
【０１０８】
ドキュメント状態を保存する構成は、ウィンドウ状態を保存する構成を包含しているので、ここではドキュメント状態の保存と再現について説明する。また、ここでの実施例は、イベント通知方式をベースとして説明する。
【０１０９】
図１６は、ウィンドウ状態／ドキュメント状態の保存と再現を実行するシステムの構成を示すブロック図である。先の実施例に対して、ウィンドウマネージャ２１２側には、状態保存手段３００および状態再現手段３１０のモジュールが加わっている。また、ウィンドウテーブルのデータ構造が、これまでのものと異なる。ここでは、その差分のみを説明する。
【０１１０】
ウィンドウテーブル
ウィンドウ管理手段２２０に含まれるウィンドウテーブルのデータ構造は、表６のように拡張される。「ウィンドウＩＤ」、「位置」、「サイズ」、「ドッキングＩＤ」は、表３のものと同じであり、表６は、以下のフィールドを拡張している。
「ドキュメント」は、ウィンドウで開くドキュメントのパスやURLを示す。ドキュメントを指定しない場合は空にする。
「スクロール位置」は、ドキュメントのスクロール位置 (ドキュメントの長さに対する比率) を保持する。「ドキュメント」フィールドが空の場合は、スクロールされることもないので、このフィールドも空になる。
「カーソル位置」は、ドキュメントにおけるカーソル位置 (先頭からの文字数) を保持する。「ドキュメント」フィールドが空の場合は、カーソルが置かれることもないので、このフィールドも空になる。
【０１１１】
【表６】
2008299689.tif 000008
【０１１２】
表６のW003のウィンドウでは、ドキュメント “C:\work\paper.doc”が開かれており、スクロールは全体の57%の位置、カーソルはドキュメントの先頭から1922文字目であることを示している。
【０１１３】
状態保存手段
ドッキングIDがD001のドッキングウィンドウの保存が指定された場合、状態保存手段３００は、表６からD001に関する部分を抜き出した情報（表７を参照）を含む構造化データをユーザが指定した、あるいは予め指定されているファイルに保存する。
【０１１４】
【表７】
2008299689.tif 000009
【０１１５】
状態再現手段
状態再現手段３１０は、ファイルを読み込み、上記のデータ構造に基づいて、ドッキングウィンドウを再現する。まずは、指定されたアプリケーションを利用してサブウィンドウを開き、ウィンドウの位置とサイズを定める。さらに、指定されたドキュメントを開き、スクロール位置、カーソル位置を設定する。
【０１１６】
４．ドッキング対象ウィンドウ候補を提示するシステム
ドッキング対象ウィンドウ候補の提示を行うシステム構成を図１７に示す。ここでは、上記したイベント通史方式に対して、ウィンドウマネージャ２１４側に、候補ドキュメント検索手段４００、候補ドキュメントお知らせ手段４１０、候補ドキュメント提示手段４２０およびウィンドウ生成手段４３０が追加されている。
【０１１７】
候補ドキュメント検索手段４００は、ドッキング対象のドキュメントを以下のようなタイミングでユーザのＰＣから自動的に検索する。
ユーザがウィンドウをドッキングするとき
ユーザから候補ドキュメントの検索が指示されたとき
【０１１８】
検索方法として、以下のようなものが考えられる。
（ａ）現在アクティブなウィンドウで表示しているドキュメントと日時属性 (作成日時、更新日時、参照日時) が近いものを検索する。アクティブなウィンドウがドッキングウィンドウである場合、そのサブウィンドウで表示しているドキュメントと日時属性が近いものを検索する。
（ｂ）現在アクティブなウィンドウで表示しているドキュメントとかつて一緒に利用したことのあるドキュメントを検索する。アクティブなウィンドウがドッキングウィンドウである場合、そのサブウィンドウで表示しているドキュメントとかつて一緒に利用したことのあるドキュメントを検索する。これを実現するためには、これまでのドキュメントの利用を履歴として保持しておく必要がある。
（ｃ）現在アクティブなウィンドウで表示しているドキュメントと他のワークスペース (ドッキングウィンドウ) で一緒に利用されているドキュメントを検索する。アクティブなウィンドウがドッキングウィンドウである場合、そのサブウィンドウで表示しているドキュメントと他のワークスペースで一緒に利用されているドキュメントを検索する。これを実現するためには、ドッキングウィンドウでのドキュメントの利用を履歴として保持しておく必要がある。
【０１１９】
ここで、ウィンドウマネージャは、ＯＳの実行中に常に起動されている常駐型のアプリケーションである。ここでは、Windows（登録商標）のタスクトレイ(タスクバーの右にあり、常駐アプリケーションのアイコンが表示されている) にあるものとする。
【０１２０】
候補ドキュメント検索手段での検索により候補ドキュメントが存在した場合、候補ドキュメントお知らせ手段４１０は、タスクトレイでのウィンドウマネージャのアイコンの状態を変化させ、ドッキングの候補ドキュメントが存在することをユーザに知らせる。
【０１２１】
ウィンドウマネージャのアイコンの状態を変化したのを見てユーザがアイコンをクリックした場合、候補ドキュメント提示手段４２０は、候補ドキュメントをリストアップする。その例を図１８に示す。同図に示すように、クリックすると、メニューが表示され、候補ドキュメントがリストアップされ、ドキュメントを選択すると、そのドキュメントが開かれ、ドラッグ可能な状態となる。
【０１２２】
リストアップされたメニューにおいて、ユーザが特定のドキュメントを選択した場合、ウィンドウ生成手段４３０は、そのドキュメントを対応するアプリケーションで開く。そして、生成されたウィンドウをドラッグ可能な状態にする。これにより、ユーザはドッキングしたいドキュメントを即座に見つけ、それを直ちに他のウィンドウとドッキングすることができるようになる。ワークスペース生成を支援するための提案である。
【０１２３】
５．ワークスペース内での最適なウィンドウ配置を推薦するシステム
ウィンドウ配置の推薦を行うためのシステム構成を図１９に示す。イベント通知方式の実施例に対して、ウィンドウマネージャ２１６側に、利用ログ取得手段５００、利用ログ分析手段５１０、およびレイアウト推薦手段５２０が追加される。
【０１２４】
利用ログ取得手段
利用ログ取得手段５００は、ドッキングウィンドウ内でのサブウィンドウに対する操作のログを取得し、利用ログテーブルに履歴を格納する。利用ログテーブルは、ドッキングウィンドウに対するユーザの操作履歴を保持するテーブルである。データ構造の一例を表８に示す。テーブルは以下のフィールドをもつ。
「日時」は、操作が発生した日時を保持する。
「ドッキングＩＤ」は、操作が行われたドッキングウィンドウのIDを保持する。ここで、ドッキングＩＤは、ドッキングウィンドウの起動毎に異ならないものとする。
「ウィンドウＩＤ」は、ドッキングウィンドウのサブウィンドウのウィンドウＩＤを保持する。ここで、ウィンドウＩＤは、起動毎に異ならないものとする。
「操作の種類」は、ユーザからどのような操作があったのかを保持する。とりあえずアクティブ、スクロール、クリック、入力などの操作を保持するが、その中で最も重要なのはアクティブである。下で述べる利用ログ分析手段のアルゴリズムではアクティブの履歴を解析することで推薦を行う。
【０１２５】
【表８】
2008299689.tif 000010
【０１２６】
利用ログ分析手段５１０では、利用ログＤＢ５３０を分析し、ドッキングウィンドウ内での最適なサブウィンドウの配置を探す。
【０１２７】
ここでは、その一例として、ドッキングウィンドウＤにおける最適なサブウィンドウの配置を推薦するための方式を示す。まずは、２つの指標を導入する。
（ａ）サブウィンドウの利用頻度
（ｂ）サブウィンドウ間の類似度
【０１２８】
サブウィンドウ間の類似度は、異なるサブウィンドウが (比較的短い時間内で) 同時に利用される可能性の高さとして算出する。時間区間を一定時間間隔Ｔ毎に区切る。そして、行がサブウィンドウ、列が長さＴで区切られた時間、要素がその時間内にサブウィンドウがアクティブになった回数となるような行列を作成する。サブウィンドウＡとＢの類似度は、ＡとＢに対応する行ベクトルの余弦として定義する。結果として、一定の時間区間内で一緒に利用された回数の多いウィンドウ同士の類似度が高くなる。上記の行列と類似度の関係を概念的に示したものが図２０である。
【０１２９】
まずは、この段階のもの(すなわち、サブウィンドウの利用頻度とサブウィンドウ間の類似度)をユーザに提示するだけでも効果があると考える。ユーザは、利用頻度の高いものが使いにくい場所にあったり、一緒に利用する頻度高い２つのサブウィンドウが離れて配置されているなどという、自分のワークスペースにおける問題点に気づく可能性があるためである。
【０１３０】
次に、上記の２つの指標を用いてワークスペース内でのサブウィンドウの配置を推薦する方式について述べる。実は、このアルゴリズムはウィンドウのサイズも考慮する必要があるため複雑である。ここでは、極めてシンプルな方法を紹介する。
(1) 最も利用頻度の高いサブウィンドウを一番左に置く。
(2) それと最も類似度の高いウィンドウを左から２番目におく。
(3) まだ配置の決まっていないサブウィンドウの中で左から２番目のサブウィンドウと最も類似度が高いものを左から３番目におく。
(4) (3) の処理を繰り返すことで、全てのサブウィンドウの配置 (左からの順番) を決める。
(5) サブウィンドウのサイズは、もともとのサブウィンドウの面積に比例するように、横幅を定める。
【０１３１】
上記のスタンスでの配置の決定により、一緒に利用する可能性の高いウィンドウが隣合うように並べられることになる。また、もともとのサブウィンドウの形は変化するが、面積の比率は保持されることになる。
【０１３２】
レイアウト提示手段５２０は、レイアウトのサンプルとユーザに提示する。ユーザはそれを見ながら、自分でワークスペース内のサブウィンドウのレイアウトを変更する。
【０１３３】
サブウィンドウの配置に関する推薦だけでなく、あまり使われていないサブウィンドウをワークスペースから除外したり、サイズを小さくしたりすることを推薦することも可能である。
【０１３４】
６．埋め込みドッキング
上記に述べたとおり、埋め込みドッキングには、その動作に関して次のような特徴がある。ドッキングの前後で(ドロップされた側の)ウィンドウ全体のサイズが変化しない。「のりしろ」が、ウィンドウの複数の辺に表示される。
【０１３５】
ここでは、イベント通知手段の実施例を拡張するかたちでの埋め込みドッキングの実現方式について説明する。埋め込みドッキングのためのシステム構成図を図２１に示す。
【０１３６】
イベント通知方式のシステム構成図に対して、マネージャ２１８には、近傍サブウィンドウ検出手段６００が追加されている。さらに、近傍ウィンドウ検出手段６００、のりしろ表示手段２４０、および「ドッキング手段２３０の動作がイベント通知方式と異なる。これらについて説明する。
【０１３７】
近傍ウィンドウ検出手段
イベント通知方式の近傍ウィンドウ検出手段６００は、２つのウィンドウがレフト（Left）-ライト（Right）、トップ（Top）-ボトム（Bottom）の関係にあるウィンドウのみを検出したが、本実施例では、２つのウィンドウが重なっている場合も検出する。
【０１３８】
拡張ドッキングと埋め込みドッキングの区別は、図２２Ａに示すように、ウィンドウに重なりがない場合には拡張ドッキング、図２２Ｂに示すように、重なりがある場合には埋め込みドッキングとする。図では、ウィンドウの外形を示す太い線３０がのりしろを示している。２つのウィンドウに重なりがない拡張ドッキングの場合には、近傍サブウィンドウ検出手段を必要とせずに、これまでと同じように処理を行なえばよい。
【０１３９】
近傍サブウィンドウ検出手段
近傍サブウィンドウ検出手段６００は、近傍ウィンドウ検出手段で埋め込みドッキングと判断された場合、ドッキングウィンドウのどのサブウィンドウのどの位置を押しのけて新たにウィンドウをドッキングさせるかを決定する。概念的には図２３に示すようになる。
【０１４０】
近傍サブウィンドウ検出手段６００では、次の２つのステップをとる。
(1) 押しのける対象のサブウィンドウを検出する。
(2) 押しのける対象のサブウィンドウで、押しのける位置を検出する。
ここでは、図２３のように、２つのウィンドウＡとＢがドッキングされたドッキングウィンドウＡＢのどこかに新たなウィンドウＣを埋め込みドッキングさせる場合を例に説明する。
【０１４１】
ステップ1では、押しのける対象のサブウィンドウを検出する。Ａの重心(ウィンドウの長方形の中心)とＢの重心を算出する。これらとＣの重心との距離を算出し、距離的に近い方がウィンドウＣのドッキング対象のウィンドウとなる。ここでは、Ｂがドッキング対象であったとする。
【０１４２】
ステップ２では、ウィンドウＢのどの位置を押しのけるかを決定する。まずは、Ｂのウィンドウ領域を図２４に示すように、２つの対角線で区切られる４つの領域の分割する。次いで、Ｂの４つの領域の各重心からＣの重心への距離を算出する。もっとも距離の近い領域が、Ｂに対するＣの埋め込み位置となる。例えば、Ｃの重心がＢの左領域の重心に近いなら(図２３Ｃの例)、ＣはＢの右位置に埋め込まれてドッキングされることになる。
【０１４３】
のりしろ表示手段
のりしろ表示手段２４０は、近傍サブウィンドウ検出手段６００で検出されたサブウィンドウ(先の例ではＢ)の埋め込み位置(先の例では左)、それからドラッグ中のウィンドウ(先の例ではＣ)の対応する位置にのりしろを表示する。ここで、対応する位置とは、図２３Ａ、図２３Ｂ、図２３Ｃに示すように、ドッキングした結果、他のサブウィンドウと接することになる辺４０Ｂ、４０Ｃ、４２Ｂ、４２Ｃ、４４Ｂ、４４Ｃのことである。
【０１４４】
ドッキング手段
ドッキング手段２３０は、のりしろ表示手段２４０で表示したのりしろの部分に新たなウィンドウ(先の例ではＣ)をドッキングする。
【０１４５】
図２５は、本実施例に係るワークスペース管理方式を実行する処理装置の一例を示す図である。本実施例に係る処理装置７００は、キーボード、マウス、タッチパネル、画像スキャナ、その他の入力を含む入力装置７０２、外部のネットワーク等と情報の送受を可能にする外部インタフェース（Ｉ／Ｆ）７０４、表示装置７０６、プリンタ等の出力装置７０８、種々のデータを記憶可能な記憶装置７１０、ＯＳ、プログラム、アプリケーションソフト等を格納するメモリ７１２、プログラムに従い各部の動作を制御可能なＣＰＵ（Central Processing Unit）７１４を含んで構成される。
【０１４６】
ＣＰＵ７１４は、メモリ７１２に格納されたアプリケーションを起動することで、表示装置７０６にユーザインタフェースのためのウィンドウを表示し、ユーザにワークスペースを与える。本実施例のワークスペース管理方式は、ＯＳおよび／またはアプリケーションソフトに組み込まれ、上記したようなウィンドウのドッキング等を実行可能にする。表示装置７０６上に表示されたウィンドウは、マウス等の入力装置７０２を介してユーザによって操作される。
【０１４７】
以上、本発明の好ましい実施の形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【０１４８】
【図１】図１Ａは、ウィンドウＡの近くにウィンドウＢがドラッグされている状態を示し、図１Ｂは、ウィンドウＢがウィンドウＡにドッキングされた状態を示す図である。
【図２】図２は、ドッキングされたウィンドウのサブウィンドウのサイズ変更を説明するずであり、図２Ａは、サブウィンドウＢのサイズ変更を示し、図２Ｂは、サブウィンドウＡのサイズ変更を示す図である。
【図３】図３は、ウィンドウＡ、Ｂ、Ｃがドッキングされたウィンドウにおいてサブウィンドウのサイズが変更された状態を説明し、図３Ａは、サブウィンドウＡのサイズ変更を示し、図３Ｂは、サブウィンドウＢ、Ｃのサイズ変更を示す図である。
【図４】図４は、ウィンドウＡ、Ｂ、Ｃ、Ｄがドッキングされたウィンドウにおいてサブウィンドウのサイズが変更された状態を説明し、図４Ａは、サブウィンドウＡのサイズ変更を示し、図４Ｂは、サブウィンドウＢ、Ｃ、Ｄのサイズ変更を示す図である
【図５】図５は、埋め込みドッキングを説明する図であり、図５Ａは、ウィンドウＣがドッキングウィンドウＡ、Ｂにドッキングされる前の状態を示し、図５Ｂは、ウィンドウＣがドッキンされた後の状態を示す図である。
【図６】本発明の実施例に係るワークスペース管理方式のイベント検出方式の構成を示すブロック図である。
【図７】本実施例のイベント検出手段の動作フローを示す図である。
【図８】本実施例のウィンドウ管理手段のExecuteの場合の動作フローを示す図である。
【図９】本実施例のウィンドウ管理手段のMoveの場合の動作フローを示す図である。
【図１０】本実施例のウィンドウ管理手段のDropの場合の動作フローを示す図である。
【図１１】本実施例のウィンドウ管理手段のResizeの場合の動作フローを示す図である。
【図１２】近傍ウィンドウ手段の動作説明図である。
【図１３】図１３Ａは、のりしろ表示手段の動作説明図、図１３Ｂは、ドッキング手段の動作説明図である。
【図１４】本実施例におけるイベント通知方式の構成を示すブロック図である。
【図１５】イベント通知方式におけるウィンドウ管理手段のExitの場合の動作フローを示す図である。
【図１６】本実施例のウィンドウ状態／ドキュメント状態の保存と再現を実行するシステムの構成を示すブロック図である。
【図１７】本実施例のドッキング対象ウィンドウ候補の提示を行うシステム構成を示すブロック図である。
【図１８】候補ドキュメント提示手段により候補ドキュメントのリストアップの例を示す図である。
【図１９】本実施例のウィンドウ配置の推薦を行うためのシステム構成を示すブロック図である。
【図２０】本実施例におけるサブウィンドウ間の類似度算出の概念を説明する図である。
【図２１】本実施例の埋め込みドッキングのためのシステム構成を示すブロック図である。
【図２２】図２２Ａは、拡張ドッキングの例を示し、図２２Ｂは、埋め込みドッキングの例を示す図である。
【図２３】近傍サブウィンドウ検出手段の動作を説明する図である。
【図２４】ウィンドウ内での領域の分割例を示す図である。
【図２５】本実施例に係るワークスペース管理方式、ワークスペース管理方法、ワークスペース管理プログラムを実行するための処理装置の構成例を示す図である。
【符号の説明】
【０１４９】
１０、１２、１４ｂ、１６、３０：のりしろ表示、
４０Ｂ、４０Ｃ、４２Ｂ、４２Ｃ、４４Ｂ、４４Ｃ：のりしろ表示
１００：マネージャ
１１０：ドッキング手段
１２０：のりしろ表示手段
１３０：近傍ウィンドウ検出手段
１４０：イベント検出手段
１５０：ウィンドウ管理手段
２００：イベント送信手段
２１０、２１２、２１４、２１６、２１８：マネージャ
２２０：ウィンドウ管理手段
２３０：ドッキング手段
２４０：のりしろ表示手段
２５０：近傍ウィンドウ検出手段
３００：状態情報保存
３１０：状態再現手段
４００：候補ドキュメント検索手段
４１０：候補ドキュメントお知らせ手段
４２０：候補ドキュメント提示手段
４３０：ウィンドウ生成手段
５００：利用ログ取得手段
５１０：利用ログ分析手段
５２０：レイアウト提示手段
６００：近傍サブウィンドウ検出手段
【図１】
2008299689.tif 000011
【図２】
2008299689.tif 000012
【図３】
2008299689.tif 000013
【図４】
2008299689.tif 000014
【図５】
2008299689.tif 000015
【図６】
2008299689.tif 000016
【図７】
2008299689.tif 000017
【図８】
2008299689.tif 000018
【図９】
2008299689.tif 000019
【図１０】
2008299689.tif 000020
【図１１】
2008299689.tif 000021
【図１２】
2008299689.tif 000022
【図１３】
2008299689.tif 000023
【図１４】
2008299689.tif 000024
【図１５】
2008299689.tif 000025
【図１６】
2008299689.tif 000026
【図１７】
2008299689.tif 000027
【図１８】
2008299689.tif 000028
【図１９】
2008299689.tif 000029
【図２０】
2008299689.tif 000030
【図２１】
2008299689.tif 000031
【図２２】
2008299689.tif 000032
【図２３】
2008299689.tif 000033
【図２４】
2008299689.tif 000034
【図２５】
2008299689.tif 000035