JP4858313B2 - ワークスペース管理方式 - Google Patents

ワークスペース管理方式 Download PDF

Info

Publication number
JP4858313B2
JP4858313B2 JP2007146482A JP2007146482A JP4858313B2 JP 4858313 B2 JP4858313 B2 JP 4858313B2 JP 2007146482 A JP2007146482 A JP 2007146482A JP 2007146482 A JP2007146482 A JP 2007146482A JP 4858313 B2 JP4858313 B2 JP 4858313B2
Authority
JP
Japan
Prior art keywords
window
docking
docked
windows
workspace
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.)
Active
Application number
JP2007146482A
Other languages
English (en)
Other versions
JP2008299689A (ja
Inventor
博仁 柴田
義文 松永
晃雅 小村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujifilm Business Innovation Corp
Original Assignee
Fuji Xerox Co Ltd
Fujifilm Business Innovation Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fuji Xerox Co Ltd, Fujifilm Business Innovation Corp filed Critical Fuji Xerox Co Ltd
Priority to JP2007146482A priority Critical patent/JP4858313B2/ja
Priority to US12/265,533 priority patent/US8607157B2/en
Publication of JP2008299689A publication Critical patent/JP2008299689A/ja
Application granted granted Critical
Publication of JP4858313B2 publication Critical patent/JP4858313B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
    • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • User Interface Of Digital Computer (AREA)
  • Digital Computer Display Output (AREA)

Description

本発明は、アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェースのワークスペースとして管理するワークスペース管理方式に関する。
近年、ますます情報が多様化し、その量も膨大になっている。個人の パーソナルコンピュータ（ＰＣ）内においても例外ではない。ユーザは、ＰＣ上でさまざまなアプリケーションを起動し、さまざまなドキュメントを同時に開いて作業を行う。多様な情報を表示したり、編集したりする場合には、多様なアプリケーションを利用することになる。これは、目的や情報の種類によって操作体系が異なるためである。例えば、テキスト文章はワードプロセッサ、お絵かきをする場合にはドローツール、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. 特許第２７１５４２１号 特開平１−７６１１４号 特開平２−２８７１６号
上記した従来技術を以下の３つの評価基準から比較してみる。
１．ワークスペースの構築・切り替えが支援されるか否か。
２．ウィンドウの重なりをなくすよう、ウィンドウ間での調整がどの程度行われているか。
３．既存のアプリケーションが利用可能かどうか、可能ならどの程度の困難さで可能か。
Figure 0004858313
これら従来技術に対して、本発明が解決しようとする課題は２つある。
１．ワークスペースの構築と切り替えに関する機能上の課題
２．既存アプリケーションを活用するための実現方式に関する課題
１．ワークスペースの構築と切り替えに関する機能上の課題
先に述べた従来研究のうち、ワークスペースの構築を可能とするものは、表１に示すように、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イベントは検出しないものとする。
図６は、イベント検出方式の構成を示すブロック図である。同図に示すように、イベント検出方式を実行するマネージャ１００は、ウィンドウをドッキングするドッキング手段１１０、ドッキングされるウィンドウにのりしろを表示するのりしろ表示手段１２０、ドッキング対象となる近隣のウィンドウを検出する近隣ウィンドウ検出手段１３０、イベント検出手段１４０およびウィンドウ管理手段１５０を含んでいる。
イベント検出手段
まずは、イベント検出手段１４０から説明する。イベント検出手段１４０は、定期的にアクティブなウィンドウ状態を取得し、ウィンドウ・イベント・テーブルを参照しながら以前のウィンドウ状態と比較することにより、イベントの検出を行う。
ウィンドウ・イベント・テーブルのデータ構造を表２に示す。ウィンドウ・イベント・テーブルは、以下のカラムをもつ。
「ウィンドウＩＤ」は、ウィンドウの識別子を保持する。
「位置」は、ウィンドウの左上の座標を保持する。
「サイズ」は、ウィンドウの幅と高さを保持する。
「アクティブ」は、ウィンドウが現在アクティブか否かを示すフラグを保持する。
「イベント」は、アクティブなウィンドウに対して直前に発生したイベントを保持する。
Figure 0004858313
図７にイベント検出手段の動作フローを示す。同図に示すように、イベント検出手段１４０は、定期的にアクティブウィンドウＷのウィンドウＩＤ(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の「イベント」カラムに検出されたイベントを書き込む。
ウィンドウ管理手段
「ウィンドウ管理手段」は、個々のウィンドウのイベント送信手段からイベントメッセージを受け取ったら、「ウィンドウテーブル」「ドッキングテーブル」を参照し、必要なウィンドウに操作を行う。まずは、ウィンドウテーブル、ドッキングテーブルのデータ構造を説明し、次いでウィンドウ管理手段の振る舞いを示す。
「ウィンドウテーブル」は、起動中の全てのウィンドウを管理する。そのデータ構造を表３に示す。ウィンドウテーブルは、以下のカラムをもつ。
「ウィンドウＩＤ」は、ウィンドウのＩＤを保持する。
「位置」は、各ウィンドウの左上の座標を保持する。
「サイズ」は、各ウィンドウの幅と高さを保持する。
「ドッキングＩＤ」は、ウィンドウがドッキングされている場合、ドッキングされているウィンドウのウィンドウＩＤの集合を保持する。ウィンドウがどのウィンドウともドッキングされていない場合、このカラムは空になる。
Figure 0004858313
表３では、７つのウィンドウが現在ＰＣ上で開かれており、そのうち、W003, W004がドッキングされており(ドッキングの情報は、ドッキングテーブルの D001 の行にある)、また、W005, W006, W007もまたドッキングされていることを示している(ドッキングの情報は、ドッキングテーブルの D002 の行にある)。
「ドッキングテーブル」は、起動中の全てのドッキングウィンドウを管理する。そのデータ構造を表４に示す。ウィンドウテーブルは、以下のカラムをもつ。
「ドッキングＩＤ」は、ドッキングウィンドウのＩＤを保持する。
「位置」は、各ドッキングウィンドウの左上の座標を保持する。
「サイズ」は、各ドッキングウィンドウの幅と高さを保持する。
「ドッキング集合」は、ドッキングされているウィンドウのウィンドウＩＤの集合を保持する。
Figure 0004858313
表４では、現在起動中のドッキングウィンドウが２つあり、一方は２つのサブウィンドウから、他方は３つのサブウィンドウから構成されることを示している。
ウィンドウ管理手段に話を戻すと、ウィンドウ管理手段は、ウィンドウＷのイベント送信手段からイベントメッセージを受けると、受け取ったイベントの種類に応じて、ウィンドウテーブルやドッキングテーブルを参照し、必要なウィンドウに対して必要な処理を行う。各々のイベント毎の動作を示す。
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を保持する。
「イベントの種類」は、送信するイベントの種類を示す。
Figure 0004858313
ウィンドウ管理手段
ウィンドウ管理手段２２０は、基本的には上記したイベント検出方式と同じである。ただし、Exitイベントの管理が新たに加わっているから、その差分のみを説明する。
ウィンドウ管理手段２２０でExit以外のイベントを受信した場合は、イベント検出方式の実施例での動作と同じである。Exitイベントを受信した場合の動作を説明する。
Exitの場合
Exitイベントを検出したときの動作フローを図１５に示す。Ｗがドッキングウィンドウか否かによって動作が異なる。Ｗがドッキングウィンドウか否かをチェックし（ステップＳ６０）、Ｗがドッキングウィンドウの場合、ウィンドウテーブルからＷのサブウィンドウの情報を削除し（ステップＳ６１）、次いで、ドッキングテーブルからＷの情報を削除する（ステップＳ６２）。Ｗが非ドッキングウィンドウの場合は、単にウィンドウテーブルからＷの情報を削除する（ステップＳ６３）。
先にも述べたが、Exitイベントを受信して、クローズされたウィンドウをウィンドウテーブル、ドッキングテーブルから削除することで、テーブルのサイズが小さくなる。これは、処理の効率化へとつながる。
３．ウィンドウ状態／ドキュメント状態の保存と再現のシステム
まずは、ウィンドウの状態保存において、２つの保存形態があることを明記しておく。
ウィンドウ状態の保存
ウィンドウ状態の保存では、以下の情報を保持する。
個々のウィンドウのアプリケーション
個々のウィンドウの位置とサイズ
ドキュメント状態の保存
ドキュメント状態の保存では、ウィンドウ状態に加え、以下の情報を保持する。
個々のウィンドウで開いているドキュメント
個々のウィンドウでのスクロール位置
個々のウィンドウでのカーソル位置
ドキュメント状態を保存する構成は、ウィンドウ状態を保存する構成を包含しているので、ここではドキュメント状態の保存と再現について説明する。また、ここでの実施例は、イベント通知方式をベースとして説明する。
図１６は、ウィンドウ状態／ドキュメント状態の保存と再現を実行するシステムの構成を示すブロック図である。先の実施例に対して、ウィンドウマネージャ２１２側には、状態保存手段３００および状態再現手段３１０のモジュールが加わっている。また、ウィンドウテーブルのデータ構造が、これまでのものと異なる。ここでは、その差分のみを説明する。
ウィンドウテーブル
ウィンドウ管理手段２２０に含まれるウィンドウテーブルのデータ構造は、表６のように拡張される。「ウィンドウＩＤ」、「位置」、「サイズ」、「ドッキングＩＤ」は、表３のものと同じであり、表６は、以下のフィールドを拡張している。
「ドキュメント」は、ウィンドウで開くドキュメントのパスやURLを示す。ドキュメントを指定しない場合は空にする。
「スクロール位置」は、ドキュメントのスクロール位置 (ドキュメントの長さに対する比率) を保持する。「ドキュメント」フィールドが空の場合は、スクロールされることもないので、このフィールドも空になる。
「カーソル位置」は、ドキュメントにおけるカーソル位置 (先頭からの文字数) を保持する。「ドキュメント」フィールドが空の場合は、カーソルが置かれることもないので、このフィールドも空になる。
Figure 0004858313
表６のW003のウィンドウでは、ドキュメント “C:\work\paper.doc”が開かれており、スクロールは全体の57%の位置、カーソルはドキュメントの先頭から1922文字目であることを示している。
状態保存手段
ドッキングIDがD001のドッキングウィンドウの保存が指定された場合、状態保存手段３００は、表６からD001に関する部分を抜き出した情報（表７を参照）を含む構造化データをユーザが指定した、あるいは予め指定されているファイルに保存する。
Figure 0004858313
状態再現手段
状態再現手段３１０は、ファイルを読み込み、上記のデータ構造に基づいて、ドッキングウィンドウを再現する。まずは、指定されたアプリケーションを利用してサブウィンドウを開き、ウィンドウの位置とサイズを定める。さらに、指定されたドキュメントを開き、スクロール位置、カーソル位置を設定する。
４．ドッキング対象ウィンドウ候補を提示するシステム
ドッキング対象ウィンドウ候補の提示を行うシステム構成を図１７に示す。ここでは、上記したイベント通史方式に対して、ウィンドウマネージャ２１４側に、候補ドキュメント検索手段４００、候補ドキュメントお知らせ手段４１０、候補ドキュメント提示手段４２０およびウィンドウ生成手段４３０が追加されている。
候補ドキュメント検索手段４００は、ドッキング対象のドキュメントを以下のようなタイミングでユーザのＰＣから自動的に検索する。
ユーザがウィンドウをドッキングするとき
ユーザから候補ドキュメントの検索が指示されたとき
検索方法として、以下のようなものが考えられる。
（ａ）現在アクティブなウィンドウで表示しているドキュメントと日時属性 (作成日時、更新日時、参照日時) が近いものを検索する。アクティブなウィンドウがドッキングウィンドウである場合、そのサブウィンドウで表示しているドキュメントと日時属性が近いものを検索する。
（ｂ）現在アクティブなウィンドウで表示しているドキュメントとかつて一緒に利用したことのあるドキュメントを検索する。アクティブなウィンドウがドッキングウィンドウである場合、そのサブウィンドウで表示しているドキュメントとかつて一緒に利用したことのあるドキュメントを検索する。これを実現するためには、これまでのドキュメントの利用を履歴として保持しておく必要がある。
（ｃ）現在アクティブなウィンドウで表示しているドキュメントと他のワークスペース (ドッキングウィンドウ) で一緒に利用されているドキュメントを検索する。アクティブなウィンドウがドッキングウィンドウである場合、そのサブウィンドウで表示しているドキュメントと他のワークスペースで一緒に利用されているドキュメントを検索する。これを実現するためには、ドッキングウィンドウでのドキュメントの利用を履歴として保持しておく必要がある。
ここで、ウィンドウマネージャは、ＯＳの実行中に常に起動されている常駐型のアプリケーションである。ここでは、Windows（登録商標）のタスクトレイ(タスクバーの右にあり、常駐アプリケーションのアイコンが表示されている) にあるものとする。
候補ドキュメント検索手段での検索により候補ドキュメントが存在した場合、候補ドキュメントお知らせ手段４１０は、タスクトレイでのウィンドウマネージャのアイコンの状態を変化させ、ドッキングの候補ドキュメントが存在することをユーザに知らせる。
ウィンドウマネージャのアイコンの状態を変化したのを見てユーザがアイコンをクリックした場合、候補ドキュメント提示手段４２０は、候補ドキュメントをリストアップする。その例を図１８に示す。同図に示すように、クリックすると、メニューが表示され、候補ドキュメントがリストアップされ、ドキュメントを選択すると、そのドキュメントが開かれ、ドラッグ可能な状態となる。
リストアップされたメニューにおいて、ユーザが特定のドキュメントを選択した場合、ウィンドウ生成手段４３０は、そのドキュメントを対応するアプリケーションで開く。そして、生成されたウィンドウをドラッグ可能な状態にする。これにより、ユーザはドッキングしたいドキュメントを即座に見つけ、それを直ちに他のウィンドウとドッキングすることができるようになる。ワークスペース生成を支援するための提案である。
５．ワークスペース内での最適なウィンドウ配置を推薦するシステム
ウィンドウ配置の推薦を行うためのシステム構成を図１９に示す。イベント通知方式の実施例に対して、ウィンドウマネージャ２１６側に、利用ログ取得手段５００、利用ログ分析手段５１０、およびレイアウト推薦手段５２０が追加される。
利用ログ取得手段
利用ログ取得手段５００は、ドッキングウィンドウ内でのサブウィンドウに対する操作のログを取得し、利用ログテーブルに履歴を格納する。利用ログテーブルは、ドッキングウィンドウに対するユーザの操作履歴を保持するテーブルである。データ構造の一例を表８に示す。テーブルは以下のフィールドをもつ。
「日時」は、操作が発生した日時を保持する。
「ドッキングＩＤ」は、操作が行われたドッキングウィンドウのIDを保持する。ここで、ドッキングＩＤは、ドッキングウィンドウの起動毎に異ならないものとする。
「ウィンドウＩＤ」は、ドッキングウィンドウのサブウィンドウのウィンドウＩＤを保持する。ここで、ウィンドウＩＤは、起動毎に異ならないものとする。
「操作の種類」は、ユーザからどのような操作があったのかを保持する。とりあえずアクティブ、スクロール、クリック、入力などの操作を保持するが、その中で最も重要なのはアクティブである。下で述べる利用ログ分析手段のアルゴリズムではアクティブの履歴を解析することで推薦を行う。
Figure 0004858313
利用ログ分析手段５１０では、利用ログＤＢ５３０を分析し、ドッキングウィンドウ内での最適なサブウィンドウの配置を探す。
ここでは、その一例として、ドッキングウィンドウＤにおける最適なサブウィンドウの配置を推薦するための方式を示す。まずは、２つの指標を導入する。
（ａ）サブウィンドウの利用頻度
（ｂ）サブウィンドウ間の類似度
サブウィンドウ間の類似度は、異なるサブウィンドウが (比較的短い時間内で) 同時に利用される可能性の高さとして算出する。時間区間を一定時間間隔Ｔ毎に区切る。そして、行がサブウィンドウ、列が長さＴで区切られた時間、要素がその時間内にサブウィンドウがアクティブになった回数となるような行列を作成する。サブウィンドウＡとＢの類似度は、ＡとＢに対応する行ベクトルの余弦として定義する。結果として、一定の時間区間内で一緒に利用された回数の多いウィンドウ同士の類似度が高くなる。上記の行列と類似度の関係を概念的に示したものが図２０である。
まずは、この段階のもの(すなわち、サブウィンドウの利用頻度とサブウィンドウ間の類似度)をユーザに提示するだけでも効果があると考える。ユーザは、利用頻度の高いものが使いにくい場所にあったり、一緒に利用する頻度高い２つのサブウィンドウが離れて配置されているなどという、自分のワークスペースにおける問題点に気づく可能性があるためである。
次に、上記の２つの指標を用いてワークスペース内でのサブウィンドウの配置を推薦する方式について述べる。実は、このアルゴリズムはウィンドウのサイズも考慮する必要があるため複雑である。ここでは、極めてシンプルな方法を紹介する。
(1) 最も利用頻度の高いサブウィンドウを一番左に置く。
(2) それと最も類似度の高いウィンドウを左から２番目におく。
(3) まだ配置の決まっていないサブウィンドウの中で左から２番目のサブウィンドウと最も類似度が高いものを左から３番目におく。
(4) (3) の処理を繰り返すことで、全てのサブウィンドウの配置 (左からの順番) を決める。
(5) サブウィンドウのサイズは、もともとのサブウィンドウの面積に比例するように、横幅を定める。
上記のスタンスでの配置の決定により、一緒に利用する可能性の高いウィンドウが隣合うように並べられることになる。また、もともとのサブウィンドウの形は変化するが、面積の比率は保持されることになる。
レイアウト提示手段５２０は、レイアウトのサンプルとユーザに提示する。ユーザはそれを見ながら、自分でワークスペース内のサブウィンドウのレイアウトを変更する。
サブウィンドウの配置に関する推薦だけでなく、あまり使われていないサブウィンドウをワークスペースから除外したり、サイズを小さくしたりすることを推薦することも可能である。
６．埋め込みドッキング
上記に述べたとおり、埋め込みドッキングには、その動作に関して次のような特徴がある。ドッキングの前後で(ドロップされた側の)ウィンドウ全体のサイズが変化しない。「のりしろ」が、ウィンドウの複数の辺に表示される。
ここでは、イベント通知手段の実施例を拡張するかたちでの埋め込みドッキングの実現方式について説明する。埋め込みドッキングのためのシステム構成図を図２１に示す。
イベント通知方式のシステム構成図に対して、マネージャ２１８には、近傍サブウィンドウ検出手段６００が追加されている。さらに、近傍ウィンドウ検出手段６００、のりしろ表示手段２４０、および「ドッキング手段２３０の動作がイベント通知方式と異なる。これらについて説明する。
近傍ウィンドウ検出手段
イベント通知方式の近傍ウィンドウ検出手段６００は、２つのウィンドウがレフト（Left）-ライト（Right）、トップ（Top）-ボトム（Bottom）の関係にあるウィンドウのみを検出したが、本実施例では、２つのウィンドウが重なっている場合も検出する。
拡張ドッキングと埋め込みドッキングの区別は、図２２Ａに示すように、ウィンドウに重なりがない場合には拡張ドッキング、図２２Ｂに示すように、重なりがある場合には埋め込みドッキングとする。図では、ウィンドウの外形を示す太い線３０がのりしろを示している。２つのウィンドウに重なりがない拡張ドッキングの場合には、近傍サブウィンドウ検出手段を必要とせずに、これまでと同じように処理を行なえばよい。
近傍サブウィンドウ検出手段
近傍サブウィンドウ検出手段６００は、近傍ウィンドウ検出手段で埋め込みドッキングと判断された場合、ドッキングウィンドウのどのサブウィンドウのどの位置を押しのけて新たにウィンドウをドッキングさせるかを決定する。概念的には図２３に示すようになる。
近傍サブウィンドウ検出手段６００では、次の２つのステップをとる。
(1) 押しのける対象のサブウィンドウを検出する。
(2) 押しのける対象のサブウィンドウで、押しのける位置を検出する。
ここでは、図２３のように、２つのウィンドウＡとＢがドッキングされたドッキングウィンドウＡＢのどこかに新たなウィンドウＣを埋め込みドッキングさせる場合を例に説明する。
ステップ1では、押しのける対象のサブウィンドウを検出する。Ａの重心(ウィンドウの長方形の中心)とＢの重心を算出する。これらとＣの重心との距離を算出し、距離的に近い方がウィンドウＣのドッキング対象のウィンドウとなる。ここでは、Ｂがドッキング対象であったとする。
ステップ２では、ウィンドウＢのどの位置を押しのけるかを決定する。まずは、Ｂのウィンドウ領域を図２４に示すように、２つの対角線で区切られる４つの領域の分割する。次いで、Ｂの４つの領域の各重心からＣの重心への距離を算出する。もっとも距離の近い領域が、Ｂに対するＣの埋め込み位置となる。例えば、Ｃの重心がＢの左領域の重心に近いなら(図２３Ｃの例)、ＣはＢの右位置に埋め込まれてドッキングされることになる。
のりしろ表示手段
のりしろ表示手段２４０は、近傍サブウィンドウ検出手段６００で検出されたサブウィンドウ(先の例ではＢ)の埋め込み位置(先の例では左)、それからドラッグ中のウィンドウ(先の例ではＣ)の対応する位置にのりしろを表示する。ここで、対応する位置とは、図２３Ａ、図２３Ｂ、図２３Ｃに示すように、ドッキングした結果、他のサブウィンドウと接することになる辺４０Ｂ、４０Ｃ、４２Ｂ、４２Ｃ、４４Ｂ、４４Ｃのことである。
ドッキング手段
ドッキング手段２３０は、のりしろ表示手段２４０で表示したのりしろの部分に新たなウィンドウ(先の例ではＣ)をドッキングする。
図２５は、本実施例に係るワークスペース管理方式を実行する処理装置の一例を示す図である。本実施例に係る処理装置７００は、キーボード、マウス、タッチパネル、画像スキャナ、その他の入力を含む入力装置７０２、外部のネットワーク等と情報の送受を可能にする外部インタフェース（Ｉ／Ｆ）７０４、表示装置７０６、プリンタ等の出力装置７０８、種々のデータを記憶可能な記憶装置７１０、ＯＳ、プログラム、アプリケーションソフト等を格納するメモリ７１２、プログラムに従い各部の動作を制御可能なＣＰＵ（Central Processing Unit）７１４を含んで構成される。
ＣＰＵ７１４は、メモリ７１２に格納されたアプリケーションを起動することで、表示装置７０６にユーザインタフェースのためのウィンドウを表示し、ユーザにワークスペースを与える。本実施例のワークスペース管理方式は、ＯＳおよび／またはアプリケーションソフトに組み込まれ、上記したようなウィンドウのドッキング等を実行可能にする。表示装置７０６上に表示されたウィンドウは、マウス等の入力装置７０２を介してユーザによって操作される。
以上、本発明の好ましい実施の形態について詳述したが、本発明は、係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
図１Ａは、ウィンドウＡの近くにウィンドウＢがドラッグされている状態を示し、図１Ｂは、ウィンドウＢがウィンドウＡにドッキングされた状態を示す図である。 図２は、ドッキングされたウィンドウのサブウィンドウのサイズ変更を説明するずであり、図２Ａは、サブウィンドウＢのサイズ変更を示し、図２Ｂは、サブウィンドウＡのサイズ変更を示す図である。 図３は、ウィンドウＡ、Ｂ、Ｃがドッキングされたウィンドウにおいてサブウィンドウのサイズが変更された状態を説明し、図３Ａは、サブウィンドウＡのサイズ変更を示し、図３Ｂは、サブウィンドウＢ、Ｃのサイズ変更を示す図である。 図４は、ウィンドウＡ、Ｂ、Ｃ、Ｄがドッキングされたウィンドウにおいてサブウィンドウのサイズが変更された状態を説明し、図４Ａは、サブウィンドウＡのサイズ変更を示し、図４Ｂは、サブウィンドウＢ、Ｃ、Ｄのサイズ変更を示す図である 図５は、埋め込みドッキングを説明する図であり、図５Ａは、ウィンドウＣがドッキングウィンドウＡ、Ｂにドッキングされる前の状態を示し、図５Ｂは、ウィンドウＣがドッキンされた後の状態を示す図である。 本発明の実施例に係るワークスペース管理方式のイベント検出方式の構成を示すブロック図である。 本実施例のイベント検出手段の動作フローを示す図である。 本実施例のウィンドウ管理手段のExecuteの場合の動作フローを示す図である。 本実施例のウィンドウ管理手段のMoveの場合の動作フローを示す図である。 本実施例のウィンドウ管理手段のDropの場合の動作フローを示す図である。 本実施例のウィンドウ管理手段のResizeの場合の動作フローを示す図である。 近傍ウィンドウ手段の動作説明図である。 図１３Ａは、のりしろ表示手段の動作説明図、図１３Ｂは、ドッキング手段の動作説明図である。 本実施例におけるイベント通知方式の構成を示すブロック図である。 イベント通知方式におけるウィンドウ管理手段のExitの場合の動作フローを示す図である。 本実施例のウィンドウ状態／ドキュメント状態の保存と再現を実行するシステムの構成を示すブロック図である。 本実施例のドッキング対象ウィンドウ候補の提示を行うシステム構成を示すブロック図である。 候補ドキュメント提示手段により候補ドキュメントのリストアップの例を示す図である。 本実施例のウィンドウ配置の推薦を行うためのシステム構成を示すブロック図である。 本実施例におけるサブウィンドウ間の類似度算出の概念を説明する図である。 本実施例の埋め込みドッキングのためのシステム構成を示すブロック図である。 図２２Ａは、拡張ドッキングの例を示し、図２２Ｂは、埋め込みドッキングの例を示す図である。 近傍サブウィンドウ検出手段の動作を説明する図である。 ウィンドウ内での領域の分割例を示す図である。 本実施例に係るワークスペース管理方式、ワークスペース管理方法、ワークスペース管理プログラムを実行するための処理装置の構成例を示す図である。
符号の説明
１０、１２、１４ｂ、１６、３０：のりしろ表示、
４０Ｂ、４０Ｃ、４２Ｂ、４２Ｃ、４４Ｂ、４４Ｃ：のりしろ表示
１００：マネージャ
１１０：ドッキング手段
１２０：のりしろ表示手段
１３０：近傍ウィンドウ検出手段
１４０：イベント検出手段
１５０：ウィンドウ管理手段
２００：イベント送信手段
２１０、２１２、２１４、２１６、２１８：マネージャ
２２０：ウィンドウ管理手段
２３０：ドッキング手段
２４０：のりしろ表示手段
２５０：近傍ウィンドウ検出手段
３００：状態情報保存
３１０：状態再現手段
４００：候補ドキュメント検索手段
４１０：候補ドキュメントお知らせ手段
４２０：候補ドキュメント提示手段
４３０：ウィンドウ生成手段
５００：利用ログ取得手段
５１０：利用ログ分析手段
５２０：レイアウト提示手段
６００：近傍サブウィンドウ検出手段

Claims (32)

  1. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方法であって、
    ディスプレイ上に表示された複数のウィンドウに関する管理情報を管理する管理ステップと、
    ウィンドウの状態の変化を検出する検出ステップと、
    前記検出ステップにより複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍に存在する他のウィンドウを検出するウィンドウ検出ステップと、
    ウィンドウ検出ステップにより他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウとが対向する辺のそれぞれに、ドッキングされる位置を示すのりしろを表示する表示ステップと、
    前記検出ステップにより前記１つのウィンドウの移動の停止が検出されたとき、前記１のウィンドウと前記他のウィンドウとを前記のりしろを介してドッキングするドッキングステップと、
    を含むワークススペース管理方法。
  2. 前記複数のウィンドウは、それぞれ異なるアプリケーションによって起動される、請求項１に記載のワークスペース管理方法。
  3. 前記複数のウィンドウは矩形状であり、前記１つのウィンドウは、他のウィンドウの１辺のサイズに適合するサイズでドッキングされ、ドッキングされたウィンドウは矩形状である、請求項１に記載の管理方法。
  4. 前記表示ステップは、前記１つのウィンドウと前記他のウィンドウの各々の少なくとも２辺にドッキング位置を示すのりしろを表示する、請求項１に記載の管理方法。
  5. ワークスペース管理方法はさらに、前記検出ステップによりドッキングされたウィンドウに含まれるサブウィンドウのサイズが変更されたことが検出されたとき、前記管理情報を参照してドッキングされたウィンドウに含まれる他のサブウィンドウのサイズを同時に変更するサイズ変更ステップを含む、請求項１に記載の管理方法。
  6. ワークスペース管理方法はさらに、前記検出ステップによりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを全体として移動するステップを含む、請求項１に記載の管理方法。
  7. 管理方法はさらに、ドッキングされたウィンドウのドッキングを解除するステップを含む、請求項１ないし６いずれか１つに記載の管理方法。
  8. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方法であって、
    １つのウィンドウがドラッグされて他のウィンドウに接近されたとき、１つのウィンドウと他のウィンドウとが対向する辺のそれぞれに、ドッキングされる位置を示すのりしろを表示し、
    前記のりしろが表示された状態で１つのウィンドウのドラッグが停止されたとき、１つのウィンドウが他のウィンドウに前記のりしろを介してドッキングされ、１つのウィンドウになる、
    管理方法。
  9. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方式であって、
    ディスプレイ上に表示された複数のウィンドウに関する管理情報を記憶するウィンドウ管理手段と、
    ウィンドウの状態の変化を検出する検出手段と、
    前記検出手段により複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍に存在する他のウィンドウを検出するウィンドウ検出手段と、
    ウィンドウ検出手段により他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウとが対向する辺のそれぞれに、ドッキング可能である位置を示すのりしろを提示する提示手段と、
    前記検出手段により前記１つのウィンドウの移動の停止が検出されたとき、前記１つのウィンドウと前記他のウィンドウとを、前記提示されたのりしろ介してドッキングするドッキング手段と、
    を有するワークスペース管理方式。
  10. 前記提示手段は、前記１つのウィンドウと前記他のウィンドウとが対向する辺のそれぞれに前記のりしろを表示する表示手段を含む、請求項９に記載の管理方式。
  11. 前記表示手段は、ウィンドウの特定の辺に他の辺と識別可能な表示を与える、請求項１０に記載の管理方式。
  12. 前記検出手段は、定期的にアクティブなウィンドウの状態を監視し、アクティブなウィンドウのイベントの変化を検出する、請求項９に記載の管理方式。
  13. 前記検出手段は、ウィンドウに対して操作されたイベントの種類を検出する、請求項９に記載の管理方式。
  14. 複数のウィンドウは、それぞれ異なるアプリケーションによって起動される、請求項９に記載の管理方式。
  15. 前記管理情報は、少なくともウィンドウを識別する識別情報、ウィンドウの位置情報、ウィンドウのサイズ情報を含む、請求項９に記載の管理方式。
  16. 前記複数のウィンドウは矩形状であり、前記ドッキング手段は、前記１つのウィンドウを、他のウィンドウの１辺のサイズに適合するサイズでドッキングし、ドッキングされたウィンドウは矩形状である、請求項９に記載の管理方式。
  17. 前記提示手段は、前記１つのウィンドウが、複数の他のウィンドウに接近したとき、前記１つのウィンドウと前記他のウィンドウの各々の少なくとも２辺にドッキング位置を表示する、請求項１０に記載の管理方式。
  18. ワークスペース管理方式はさらに、前記検出手段によりドッキングされたウィンドウに含まれるサブウィンドウのサイズが変更が検出されたとき、前記管理情報を参照して、ドッキングされたウィンドウに含まれる他のサブウィンドウのサイズを同時に変更するサイズ変更手段を含む、請求項９に記載の管理方式。
  19. ワークスペース管理方式はさらに、前記検出手段によりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを移動する移動手段を含む、請求項９に記載の管理方式。
  20. ワークスペース管理方式はさらに、ドッキングされたウィンドウの状態を保存する状態保存手段と、前記状態保存手段により保存された状態に基づきドッキングウィンドウを再現する状態再現手段とを含む、請求項９に記載の管理方式。
  21. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方式であって、
    １つのウィンドウがドラッグされて他のウィンドウに接近されたとき、１つのウィンドウと他のウィンドウとが対向する辺のそれぞれにドッキングされる位置を示すのりしろを表示する表示手段と、
    １つのウィンドウと他のウィンドウとを前記のりしろを介してドッキングするドッキング手段と、
    ドッキングされたドッキングウィンドウ内のサブウィンドウに対する操作履歴情報を保持する利用履歴保持手段と、
    前記操作履歴情報に基づきドッキングされたウィンドウ内のサブウィンドウの配置を推薦する配置推薦手段と、
    を有するワークスペース管理方式。
  22. 配置推薦手段は、前記操作履歴情報に基づき少なくともサブウィンドウの利用頻度またはサブウィンドウ間の類似度を算出し、その算出結果に応じてサブウィンドウの配置を決定する、請求項２１に記載のワークスペース管理方式。
  23. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理方式であって、
    １つのウィンドウがドラッグされて他のウィンドウに接近されたことを検出する手段と、
    前記検出に応答して１つのウィンドウと他のウィンドウとが対向する辺のそれぞれに、ドッキングされる位置を示すのりしろを表示する表示手段と、
    前記のりしろが表示された状態で１つのウィンドウのドラッグが停止されたとき、１つのウィンドウと他のウィンドウとを、前記のりしろを介してドッキングし、１つのウィンドウを生成するドッキング手段と、
    を有する管理方式。
  24. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理プログラムであって、
    ディスプレイ上に表示された複数のウィンドウに関する管理情報を記憶するウィンドウ管理手段と、
    ウィンドウの状態の変化を検出する検出手段と、
    前記検出手段により複数のウィンドウのうちの１つのウィンドウの移動が検出されたとき、前記管理情報を参照して、当該１つのウィンドウの近傍に存在する他のウィンドウを検出するウィンドウ検出手段と、
    ウィンドウ検出手段により他のウィンドウが検出されたとき、前記１つのウィンドウと前記他のウィンドウとが対向する辺のそれぞれに、ドッキングされる位置を示すのりしろ表示する表示手段と、
    前記検出手段により前記１つのウィンドウの移動の停止が検出されたとき、前記１つのウィンドウと前記他のウィンドウとを、前記のりしろを介してドッキングするドッキング手段と、
    を有するワークスペース管理プログラム。
  25. 前記複数のウィンドウは矩形状であり、前記ドッキング手段は、前記１つのウィンドウを、他のウィンドウの１辺のサイズに適合するサイズでドッキングし、ドッキングされたウィンドウは矩形状である、請求項２４に記載の管理プログラム。
  26. ワークスペース管理方式はさらに、前記検出手段によりドッキングされたウィンドウの移動が検出されたとき、ドッキングされたウィンドウを移動する移動手段を含む、請求項２４に記載の管理プログラム。
  27. ワークスペース管理方式はさらに、ドッキングされたウィンドウの状態を保存する状態保存手段と、前記状態保存手段により保存された状態に基づきドッキングウィンドウを再現する状態再現手段とを含む、請求項２４に記載の管理プログラム。
  28. アプリケーションの起動に応答して表示されたウィンドウをユーザインタフェース用のワークスペースとして管理するワークスペース管理プログラムであって、
    １つのウィンドウがドラッグされて他のウィンドウに接近されたことを検出する手段と、
    前記検出に応答して１つのウィンドウと他のウィンドウとが対向するそれぞれの辺に、ドッキングされる位置を示すのりしろを表示する表示手段と、
    前記のりしろが表示された状態で１つのウィンドウのドラッグが停止されたとき、１つのウィンドウと他のウィンドウとを前記のりしろを介してドッキングし、１つのウィンドウを生成するドッキング手段と、
    を有する管理プログラム。
  29. 前記表示手段は、ウィンドウの特定の辺に他の辺と識別可能な表示を与える、請求項２８に記載の管理プログラム。
  30. 前記検出手段は、定期的にアクティブなウィンドウの状態を監視し、アクティブなウィンドウのイベントの変化を検出する、請求項２８に記載の管理プログラム。
  31. 前記検出手段は、ウィンドウに対して操作されたイベントの種類を検出する、請求項２８に記載の管理プログラム。
  32. 複数のウィンドウは、それぞれ異なるアプリケーションによって起動される、請求項２８に記載の管理プログラム。
JP2007146482A 2007-06-01 2007-06-01 ワークスペース管理方式 Active JP4858313B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007146482A JP4858313B2 (ja) 2007-06-01 2007-06-01 ワークスペース管理方式
US12/265,533 US8607157B2 (en) 2007-06-01 2008-11-05 Workspace management method, workspace management system, and computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007146482A JP4858313B2 (ja) 2007-06-01 2007-06-01 ワークスペース管理方式

Publications (2)

Publication Number Publication Date
JP2008299689A JP2008299689A (ja) 2008-12-11
JP4858313B2 true JP4858313B2 (ja) 2012-01-18

Family

ID=40173139

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007146482A Active JP4858313B2 (ja) 2007-06-01 2007-06-01 ワークスペース管理方式

Country Status (2)

Country Link
US (1) US8607157B2 (ja)
JP (1) JP4858313B2 (ja)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245423A (ja) * 2008-03-13 2009-10-22 Panasonic Corp 情報機器およびウインドウ表示方法
US8970448B2 (en) 2009-06-18 2015-03-03 Hiperwall, Inc. Systems, methods, and devices for manipulation of images on tiled displays
US9400659B2 (en) * 2009-09-29 2016-07-26 Verizon Patent And Licensing Inc. Graphical user interface window attachment
WO2011122402A1 (ja) * 2010-03-31 2011-10-06 株式会社 日立メディコ 検査情報表示装置及び方法
US8667416B2 (en) * 2010-04-12 2014-03-04 International Business Machines Corporation User interface manipulation for coherent content presentation
US9372618B2 (en) * 2010-10-01 2016-06-21 Z124 Gesture based application management
CA2798291C (en) * 2011-12-07 2016-11-01 Research In Motion Limited Presenting context information in a computing device
EP2608010A3 (en) 2011-12-21 2017-10-04 Ixonos OYJ Master application for touch screen apparatus
CN102799385B (zh) * 2012-07-19 2016-12-21 腾讯科技（深圳）有限公司 桌面控制方法和装置
KR101957173B1 (ko) 2012-09-24 2019-03-12 삼성전자 주식회사 터치 디바이스에서 멀티윈도우 제공 방법 및 장치
US8984439B2 (en) * 2013-02-14 2015-03-17 Citibank, N.A. Methods and systems for managing a graphical user interface
US20140298219A1 (en) * 2013-03-29 2014-10-02 Microsoft Corporation Visual Selection and Grouping
KR20140133072A (ko) * 2013-05-09 2014-11-19 삼성디스플레이 주식회사 모바일 장치 및 이의 구동 방법
JP5785998B2 (ja) * 2013-08-08 2015-09-30 東芝テック株式会社 情報処理装置、プログラム
JP6059114B2 (ja) * 2013-08-28 2017-01-11 京セラ株式会社 携帯端末、結合制御プログラムおよび結合制御方法
KR102153366B1 (ko) 2013-08-30 2020-10-15 삼성전자 주식회사 전자 기기의 화면 전환 방법 및 장치
USD749610S1 (en) * 2013-09-03 2016-02-16 Samsung Electronics Co., Ltd. Display screen or portion thereof with graphical user interface
USD749109S1 (en) * 2013-09-03 2016-02-09 Samsung Electronics Co., Ltd. Display screen or portion thereof with graphical user interface
US20160299666A1 (en) * 2013-11-28 2016-10-13 Sony Corporation Information processing apparatus, information processing method, and program
CN104094210B (zh) * 2013-12-20 2018-09-21 华为技术有限公司 一种文件夹内的文件开启方法和终端
US9933922B2 (en) * 2014-03-27 2018-04-03 Sybase, Inc. Child container control of parent container of a user interface
JP6598441B2 (ja) * 2014-09-09 2019-10-30 シャープ株式会社 情報処理装置、情報処理方法及びプログラム
JP5908046B1 (ja) 2014-10-21 2016-04-26 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ 複数領域を結合して表示する方法、装置及びプログラム。
GB2532940B (en) * 2014-12-01 2021-12-15 Advanced Risc Mach Ltd Method of and apparatus for providing an output surface in a data processing system
US10558344B2 (en) * 2015-06-01 2020-02-11 Apple Inc. Linking multiple windows in a user interface display
JP6610138B2 (ja) * 2015-09-30 2019-11-27 富士通クライアントコンピューティング株式会社 表示制御装置、表示制御方法及び表示制御プログラム
JP6455466B2 (ja) * 2016-03-02 2019-01-23 京セラドキュメントソリューションズ株式会社 表示操作装置およびプログラム
JP6455467B2 (ja) * 2016-03-03 2019-01-23 京セラドキュメントソリューションズ株式会社 表示制御装置
JP6693279B2 (ja) * 2016-06-03 2020-05-13 コニカミノルタ株式会社 医療情報表示装置、表示制御方法及びプログラム
JP6322272B2 (ja) * 2016-12-22 2018-05-09 シャープ株式会社 表示装置、設定方法、コンピュータプログラム及びそれを記録した記録媒体
US10678566B2 (en) * 2017-01-20 2020-06-09 International Business Machines Corporation Cognitive screen sharing with contextual awareness
JP2019101474A (ja) * 2017-11-28 2019-06-24 富士通株式会社 グループ化制御方法、グループ化制御プログラム、情報処理装置及び情報共有システム
CN110347315A (zh) * 2018-04-08 2019-10-18 中兴通讯股份有限公司 一种数据处理方法、终端及存储介质
CN111641797B (zh) * 2020-05-25 2022-02-18 北京字节跳动网络技术有限公司 视频通话界面显示控制方法、装置、存储介质及设备
CN116670627A (zh) * 2020-12-31 2023-08-29 苹果公司 对环境中的用户界面进行分组的方法
WO2023060454A1 (en) * 2021-10-13 2023-04-20 Citrix Systems, Inc. Computing device with window docking and related systems and methods
US11868160B2 (en) * 2022-02-09 2024-01-09 Microsoft Technology Licensing, Llc Just-in-time snap layouts

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6476114A (en) 1987-09-18 1989-03-22 Hitachi Ltd Screen area displaying control system
JP2715421B2 (ja) 1987-11-27 1998-02-18 富士ゼロックス株式会社 ワークステーションにおける電子文書管理方式
JPH0228716A (ja) 1988-07-18 1990-01-30 Matsushita Electric Ind Co Ltd マルチウィンドウ装置
JP3730670B2 (ja) * 1994-07-20 2006-01-05 富士通株式会社 データ処理装置
US5819055A (en) * 1994-12-13 1998-10-06 Microsoft Corporation Method and apparatus for docking re-sizeable interface boxes
US5917483A (en) * 1995-09-18 1999-06-29 Oracle Corporation Advanced windows management for a computer system
US5873106A (en) * 1995-09-18 1999-02-16 Oracle Corporation Geometry management for displaying objects on a computer
US5712995A (en) * 1995-09-20 1998-01-27 Galileo Frames, Inc. Non-overlapping tiling apparatus and method for multiple window displays
US5801699A (en) * 1996-01-26 1998-09-01 International Business Machines Corporation Icon aggregation on a graphical user interface
US5808610A (en) * 1996-08-28 1998-09-15 Macromedia, Inc. Method and system of docking panels
US5796403A (en) * 1996-09-27 1998-08-18 Adams; James S. Method of display categorization in a multi-window display
US5734380A (en) * 1996-09-27 1998-03-31 Adams; James S. Method for controlling the presentation of displays in a multi-window computer environment
US5977973A (en) * 1997-05-14 1999-11-02 Microsoft Corporation Window linking
US6008809A (en) * 1997-09-22 1999-12-28 International Business Machines Corporation Apparatus and method for viewing multiple windows within a dynamic window
US6590594B2 (en) * 1999-03-25 2003-07-08 International Business Machines Corporation Window scroll-bar
JP3942305B2 (ja) * 1999-04-12 2007-07-11 富士通株式会社 複数ディスプレイ構成に対応したウィンドウ配置管理システム
US7289964B1 (en) * 1999-08-31 2007-10-30 Accenture Llp System and method for transaction services patterns in a netcentric environment
US6550057B1 (en) * 1999-08-31 2003-04-15 Accenture Llp Piecemeal retrieval in an information services patterns environment
US7434177B1 (en) * 1999-12-20 2008-10-07 Apple Inc. User interface for providing consolidation and access
JP3604993B2 (ja) 2000-03-16 2004-12-22 シャープ株式会社 画像符号化装置、画像符号化方法、画像復号装置、および画像復号方法
JP2002215683A (ja) * 2001-01-22 2002-08-02 Amu:Kk キャドソフト
US6771292B2 (en) * 2001-03-29 2004-08-03 International Business Machines Corporation Method and system for providing feedback concerning a content pane to be docked in a host window
US20030107604A1 (en) * 2001-12-12 2003-06-12 Bas Ording Method and system for automatic window resizing in a graphical user interface
JP2003241359A (ja) * 2001-12-13 2003-08-27 Dainippon Screen Mfg Co Ltd レイアウト処理装置、レイアウト処理方法、および記録媒体並びにプログラム
JP4430908B2 (ja) * 2003-09-04 2010-03-10 株式会社リコー マルチウィンドウ表示制御装置およびこれを使用するコンピュータシステム
US7817163B2 (en) * 2003-10-23 2010-10-19 Microsoft Corporation Dynamic window anatomy
US7839419B2 (en) * 2003-10-23 2010-11-23 Microsoft Corporation Compositing desktop window manager
US20050125742A1 (en) * 2003-12-09 2005-06-09 International Business Machines Corporation Non-overlapping graphical user interface workspace
US7543244B2 (en) * 2005-03-22 2009-06-02 Microsoft Corporation Determining and displaying a list of most commonly used items
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US10503342B2 (en) * 2006-08-04 2019-12-10 Apple Inc. User interface spaces

Also Published As

Publication number Publication date
US20090064035A1 (en) 2009-03-05
US8607157B2 (en) 2013-12-10
JP2008299689A (ja) 2008-12-11

Similar Documents

Publication Publication Date Title
JP4858313B2 (ja) ワークスペース管理方式
KR20100056594A (ko) 워크스페이스 관리 방법, 워크스페이스 관리 방식 및 컴퓨터 판독 가능한 기억매체
US20230049473A1 (en) Method and device for managing tab window indicating application group including heterogeneous applications
CN101739196B (zh) 工作空间管理方法及工作空间管理系统
US10152192B2 (en) Scaling application windows in one or more workspaces in a user interface
JP5704825B2 (ja) 情報処理装置およびその制御方法およびプログラム
JP4303311B2 (ja) 操作支援コンピュータプログラム、操作支援コンピュータシステム
US20100192066A1 (en) Method and system for a graphical user interface
US20090019385A1 (en) Management of Icons in a Display Interface
EP2669777A1 (en) Terminal device and icon management method
US5594847A (en) System and method for selecting free form objects associated with a selection region displayed by a computer
CN115269094A (zh) 管理用户界面中的工作空间
JP5167850B2 (ja) Ｇｕｉシステム、ｇｕｉ生成方法、プログラムおよび記録媒体
EP2437184A1 (en) Host apparatus and method of displaying content by the same
JPH1153161A (ja) 情報処理方法及び装置及び前記方法を実行する制御プログラムを記憶した記憶媒体
JP5039312B2 (ja) 複数ポインタを制御するプログラム、方法および装置
EP4086755B1 (en) Robotic process automation (rpa) comprising automatic document scrolling
AU2008243141B2 (en) Workspace management method, workspace management system, and workspace management program
JP2001290574A (ja) 情報表示方法および情報処理装置
KR20170126213A (ko) 리스트 상의 복수의 아이템에 대한 기능 실행 방법 및 그 장치
JP5772280B2 (ja) プログラムおよび情報処理装置
JP6624972B2 (ja) 表示を制御する方法、装置、およびプログラム
JP2019079324A (ja) 情報処理装置及びプログラム
US11487406B1 (en) Windowing container
JP2007018089A (ja) 情報処理装置、情報処理方法及びプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090825

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110617

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110705

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110830

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111004

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111017

R150 Certificate of patent or registration of utility model

Ref document number: 4858313

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20141111

Year of fee payment: 3

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350