JPH10500512A - グラフィカルユーザーインタフェースの形態及び動作のカスタマイズ方法及びシステム - Google Patents

Abstract

(57)【要約】 ユーザーに対する融通性を提供し、ユーザーインタフェース上でのオブジェクトの形態と動作の制御を提供する方法及びシステムが示される。明確で完全なインタフェースの印象をユーザーへ提供するためのテーマの中へオブジェクトのセットがグループ化される。これらのテーマは、描画手順の切替ポインタあるいはこれらの手順で供給される切替データによって動的に切り替えられる。本発明に従うグラフィカルユーザーインタフェースの切替可能な態様からアプリケーションを確保すると、インタフェースオブジェクトを実行するために使用される色とパターンが、例えば、パターンルックアップテーブルによってインタフェースから抽出される。

Description

【発明の詳細な説明】 発明の名称 グラフィカルユーザーインタフェースの形態及び動作 のカスタマイズ方法及びシステム 背景 本発明は、コンピュータシステムにおける一般的なグラフィカルユーザーイン タフェースに関するものである。特に、本発明は、グラフィカルユーザーインタ フェースのフレキシブルカスタマイズを提供するオペレーティングシステムと、 アプリケーションとのインタフェース方法及びシステムに関するものである。 コンピュータ産業の発展は、その成長と複雑になる割合において並ぶものはな い。例えば、有限のメモリとテープ駆動による入力とモノクロディスプレイを備 える処理能力の低い計算をすることから始まったパーソナルコンピューターは、 いまやほとんどのデータ処理タスクを取り扱うことができるようになった。著し い処理能力の向上は、アプリケーション開発者やエンドユーザー等の要求を満足 するのに十分であったが、複雑さが増すにつれて、産業による解決の遅れが使用 を容易にするという問題を生じた。このように、開発者は新たな課題に直面した 。つまり、比較的わずかなコンピュータの訓練にでコンピュータに基づく情報へ 他の産業の遷移が円滑に進むように、使用可能な形態でコンピュータの能力を利 用することである。 その結果、１９８０年代の半ばの早い時期に、多くの新しいＩ／Ｏ原理、例え ば、「ユーザーフレンドリー」、「ＷＹＳＩＷＹＧ」、「メニュー操作」が産業 の中心になった。これらの概念は、特に、マイクロコンピュータ、周知のパーソ ナルコンピュータに取り入れることができ、コンピュータに対し以前は不安や不 信感を抱いていたコンピュータユーザーに広く普及している傾向である。これら の概念を備えるコンピュータに対する重要な一面は、一般にグラフィカルユーザ ーインタフェース（以下、ＧＵＩと称する）と呼ばれるインタフェースを用いて 、ユーザがコマンドやデータを入力したり、その結果を受け継ぐことができるイ ンタフェースであり、今もそれは変わらない。 ＧＵＩディスプレイの一つの様式は、「ウインドウズ」という技術用語で定義 される配置が自在な領域において提供されるドキュメント上にある「デスクトッ プ」と呼ばれる作業領域としてモニタ画面が用いられるヴィジュアルメタファに 基づいている。ユーザーとコンピュータは、例えば、デスクトップ上でのオブジ ェクトの移動、メニューからのコマンドの選択、チェックボックスやスクロール バーのようなウインドウ制御の操作によって相互に作用し合う。図１にデスクト ップ画面の一例を再現する。 この様式のインタフェースの成功は、デスクトップ環境をエミュレートした多 くの企業によって明らかにされている。しかしながら、成功した概念でさえも、 産業における急速な発展のペースを保つために継続的に改良されなければならな い。マルチメディアの出現、特に、ＣＤ−ＲＯＭデバイスは、例えば、アプリケ ーションディスプレイの正式成分としての動画とビデオクリップ等の映像能力を 提供するために用いられる大容量の第２記憶媒体を提供する。それらの配列や、 アプリケーションデザイナー等の新規なリソースでは、デスクトップ環境、特に 、デスクトップ上のオブジェクトを含むディスプレイの形態上にますます多くの 制御を必要とする。 ウインドウズは、サイズ、形、色等を仮想的に表現できるデスクトップオブジ ェクトの一例である。ウインドウズのある標準的な様式は、例えば、ドキュメン トウインドウやダイアログボックスを含むインタフェースに対し通常初期設定が なされている。図２Ａに標準的なドキュメントウインドウの一例を示す。この標 準に従うそれぞれのドキュメントウインドウは、システム定義のフォントと色で 描画されているタイトルを含むタイトルバーを有している。アクティブドキュメ ントウインドウは、図２Ａに示される、例えば、クローズボックス、ズームボッ クス、サイズボックス、スクロールバー等の制御を有することができる。これら のウインドウ（同様に標準デスクトップオブジェクトも）の標準的な様式は、ユ ーザーが要求する形態と／あるいは動作の変更の範囲を越えるものである。 これに応じて、アプリケーション開発者は、その要求に応えるべく独自の非標 準的なウインドウ様式を定義することができるが、それぞれの非標準的なウイン ドウはメモリ上のかなりの大きな記憶領域のブロックを必要とする。更に、これ らの非標準的なウインドウの様式は、アプリケーションの詳細であるデスクトッ プオブジェクトの 形態及び動作に対し限られた融通性と制御しか提供できないばかりか、すべての アプリケーションに渡って首尾一貫したインタフェースを供給できない。例えば 、３つの異なるアプリケーションが起動している場合、それぞれがデスクトップ 上に異なる「ルック」提供する。繰り返して述べると、これらの非標準的なウイ ンドウオブジェクトの形態と／あるいは動作に対してユーザーは制御不能である 。 形態、動作、標準的なウインドウの機能、ウインドウ部分を含むウインドウフ ォーマットは、周知のシステムに対して設計されている先天的なアプリケーショ ンとして知られ、これらのアプリケーションは、通常の知識を利用して記述され る。図３において、例えば、アプリケーション１０がウインドウ（デスクトップ 上では表示されていない）内にタイトルバーの色（この例では、ベージュ）の矩 形を描画することを仮定してみる。あらかじめ定義されている標準的なウインド ウ定義２５を用いる時、アプリケーションはタイトルバーの色の知識を引き受け る。そして、このアプリケーションがアプリケーション自身によって生成される ウインドウ定義を用いる場合、アプリケーションは、ウインドウによって定義さ れる実質的な色の知識を持つことになる。これに応じて、アプリケーションは単 にコマンドだけを、ウインドウ内にベージュの矩形が描画されることを指示する インタフェースへ送信するであろう。 どの非標準的なウインドウも標準的なウインドウも従来の対応するウインドウ 定義２５を有している。ウインドウ定義２５には、ウインドウを定義するための 必要なデータがすべて含まれている。図１に示されるアクテイブウインドウを参 照すると、ウインドウ定義２５には、アクティブウインドウに含まれる、例えば 、ウインドウのサイズ、上部の左右の角にあるクローズボックス、ズームボック スの位置関係、それぞれの複数の平行線、その平行線の位置に関係するクローズ ボックスとズームボックス、ウインドウの上部の境界線、特定のウインドウの形 を定義する他の定義すべてに対するデータを含んでいる。アプリケーションは、 たいてい、ウインドウ内のテキストと／あるいは図に対して用いられる色と／あ るいはフォント、デスクトップインタフェース上のウインドウの配置等に用いる 多様なパラメータを供給する。想像できることとしては、ウインドウ定義には、 大量のデータを含み、それゆえ、それぞれの定義に対し大容量のメモリを必要と することである。 加えて、非標準的なウインドウ定義を生成するためには大容量のメモリを必要 とす るので、グラフィカルユーザーインタフェースで多様な形態を提供する従来の方 法では、異なるアプリケーションによってデスクトップ上に描画されるオブジェ クト間で不一致が生じるという問題が生じる。マルチタスキングでは、即ち、デ スクトップ上で同時に複数のアプリケーションを起動する場合では、デスクトッ プ上で複数のアプリケーション自身のウインドウをそれぞれ持って同時に起動す ることは通常のことである。しかしながら、それぞれのアプリケーション自身の 標準的、非標準的なウインドウ定義の組み合わせをそれぞれのアプリケーション が用いると、それぞのアプリケーションは、それ自身の形態と動作を持つことに なる。アプリケーション間の形態と動作の相違は、ユーザーに対しわずらわしく 困惑させることになる。 これに応じて、アプリケーション開発者とアプリケーションユーザーにデスク トップオブジェクトとの形態と動作とそれぞれのオブジェクトの制御に対し付加 的な融通性とより多くの制御を許可することが望まれている。 要約 本発明の実施形態に従えば、形態マネージメントレイヤーの供給によるＧＵＩ が、ユーザー（アプリケーション開発者及びエンドユーザー）に対しデスクトッ プ上の形態と動作をカスタマイズする能力を与えることで改良された視覚的な形 態を提供することができる。このレイヤーは、例えば、エンドユーザー、定義処 理、ディスプレイに対し実際に描画を行うグラフィックサブシステム等のすべて のクライアント間に提供される。このように、概念的なレベルがクライアントと システム間で提供されるので、絶えず変化するインタフェース環境に関して詳細 な知識をクライアントに要求することなくカスタマイズを容易にできる。 テーマは、設計されるデスクトップオブジェクトの設定を含んで生成され、そ のデスクトップオブジェクトは視覚的な形態と動作を持ち、領域にその外観の様 子を映す。ユーザーは動作中であっても、このようなテーマを切り替えて、画面 全体の印象を替えることができる。 図面の簡単な説明 上述のように、本発明の利点、形態、目的等が、以下の図とともに説明する実 施形 態に基づく技術分野によって容易に理解されるであろう。 図１は従来のデスクトップ画面を示す図である。 図２Ａは従来のドキュメントウインドウを示す図である。 図２Ｂは本発明の実施形態に従うドキュメントウインドウを示す図である。 図２Ｃは従来のユーザーインタフェースを示す図である。 図２Ｄは本発明の実施形態に従う第１のテーマ下の操作における図２Ｃのユー ザーインタフェースを示す図である。 図２Ｅは本発明の実施形態に従う第２のテーマ下の操作における図２Ｃのユー ザーインタフェースを示す図である。 図３は本発明の実施形態に従うユーザーインタフェースをカスタマイズするた めのシステムの概観機能を示す図である。 図４は本発明の実施形態に従うテーマとアプリケーションの相互作用を示すア ーキテクチャーの一例を示す図である。 図５は本発明の実施形態に従う特定のテーマに対するドキュメントウインドウ を生成するために用いることができるグリフ（glyphs）の組を示す図である。 図６は本発明の実施形態に従うインタフェースオブジェクトパートの状態遷移 図である。 図７は本発明の実施形態に従う遷移の動作を表現するために用いられるマトリ クスの一例を示す図である。 図８は本発明の実施形態に従う含まれている機能を示すブロック図である。 図９は本発明の実施形態に従うパターン概念を示すブロック図である。 図１０は本発明の他の実施形態に従うパターン概念を示すブロック図である。 図１１は本発明の実施形態に従うコントロールパネルの形態の一例を示す図で ある。 図１２は本発明の実施形態に従うマネージメントレイヤー、アプリケーション 、テーマ間の形態を示す図である。 図１３〜図１５は本発明の実施形態に従うテーマの切替方法の一例を示すフロ ーチャートである。 実施形態の詳細な説明 ここでは、本発明を説明するために参照するコンピュータシステムの図面とし てマッキントッシュコンピュータシステムを例に本発明を詳述する。しかしなが ら、これらの当業者には、本発明に従う方法及びシステムがユーザーインタフェ ースを備えるどのディスプレイシステムの様式にも適用させることができるとい うことを容易に理解できるであろう。更に、本発明の実施形態が一般的なデスク トップオブジェクトの形態及び動作にどのような影響を与えるかを示すためにウ インドウオブジェクトが用いられるが、当業者とは、本発明が、例えば、アイコ ン、メニュー、リスト、制御要素、カーソル、メニューバー等を含むデスクトッ プオブジェクトの形態及び動作を制御するために用いることができることが認識 できるであろう。 ウインドウは様々な方法で特徴付けすることができる。例えば、ウインドウの 色、サイズ、形、同様にそれぞれの成分パーツの色、形、サイズ、位置によって キャラクタライズすることができ、これらのパーツは、例えば、図２Ａのように 定義される。これらのウインドウ及びウインドウパーツの属性は、ウインドウ形 態属性として、ここでは分類される。ウインドウ及びウインドウパーツの属性に は、ユーザーが関連した入力を提供する場合、例えば、クローズボタンあるいは ボックスをクリックすることでウインドウをクローズするような場合を請けおえ る１つ以上の機能が集約されている。これらを機能的属性と定義する。 ウインドウとウインドウパーツに対しては、３番目の属性が存在する。ウイン ドウとウインドウパーツは、オブジェクトの基礎を成す機能から区別されるユー ザーによって実行する時の動作を示している。例えば、マウスを使ってユーザー がクローズボタンをクリックすると、ウインドウが実際にクローズする前に、そ のボタンがくぼむように表示されることでボタンが影になる。 これらの３つの属性の分類は、すなわち、形態、動作、機能であり、本発明の 実施形態は、オブジェクト及びオブジェクトパーツの形態及び動作を変更するた めの能力をユーザー（アプリケーションのエンドユーザー、アプリケーション開 発者もオペレーティングシステムを使用するあるいは請うその他の者も参照する このドキュメントを通して適用されるユーザーと定義する）に提供するが、機能 を基礎にこれらを成すことは好ましくない。ここでの原理がユーザーによって変 更できる機能的な属性に関 するシステム及び方法に同様に適用できることが、当業者によって理解されるで あろう。しかしながら、機能上のシステム標準化はある程度の利点を提供するた め、本実施形態では他の属性の処理から機能上の処理を分けている。 今日、すべての映像及び音響効果に利用できるＧＵＩさえあれば、心地好いイ ンタフェースのオブジェクトの形態及び動作に対するシステム制御を発展させる ことができる多様なデスクトップの「ルックス」を広く想像することができる。 従来の図２Ｃに示すユーザーインタフェース画面と図２Ｄ、２Ｅに示す異なるテ ーマを用いているユーザーインタフェース画面の比較は、本発明に従うユーザー インタフェースにおける形態及び動作の変更に対する強力な能力を理解するのに より良い出発点となる。例えば、図２Ｃに示す「ビュー」タイトルバーと図２Ｄ 、２Ｅに示す「ビュー」タイトルバーの形態の違いに注目されたい。 カスタマイズされたユーザーインタフェースの様式がどのようにして図４の説 明から始まる首尾一貫してかつ切替可能な方法を提供できるかの概要を手短に説 明する。図４に示すように、アプリケーション３８は３つのパス通して形態マネ ージメントレイヤーと相互に作用し合う。つまり、直接、またはユーティリティ ４２（例えば、ツールボックスマネージャー）と通して、また、インタフェース 上でオブジェクトを描画するために基本的な指示（例えば、defprocs）を供給す る描画処理４６を介して、相互に作用し合う。「描画処理」（drawing procedur e）表現は、例えば、ウインドウ定義のようなオブジェクトの形を定義し、イン タフェースオブジェクトの描画を果たすコードの一部を参照するドキュメントに おいて用いられる。 注目すべきことは、アプリケーションは描画処理に直接はアクセスしないで、 形態マネージメントレイヤーとユーティリティによって保持されるポインタ４４ のテーブルを介してアクセスすることである。切替ポインタ４４と描画処理４６ は、それぞれのインタフェースオブジェクトのジオメトリーを与え、首尾一貫し かつ配置替え可能な形態でそれぞれのオブジェクトの制御の動作を計算する基礎 構築ブロックを提供しする。ポインタ４４から描画処理４６に切替、あるいは描 画処理４６にデータの使用による切替によって、インタフェースの形態を動作は 容易に変更することができる。 本発明によってフレキシビリティの提供が与えられ、アプリケーションは、そ れぞれのオブジェクトとその制御に対して用いれるパターンあるいは色に関する 先天的な 知識をもう必要としない。それゆえ、パターンテーブル４８は、他の属性からオ ブジェクトの色と／あるいはパターンを抽出することを促し、情報を参照するよ うに用いられる。本実施形態に従えば、「ペイントバイナンバー」（paint-by-n umber）インタフェース描画に許容する描画コマンドがクライアントによって形 態マネージメントレイヤーへ送信される。替言すれば、アプリケーションは、容 易に、形態マネージメントレイヤー４０に対し、オブジェクトのパターンと／あ るいは色を定義するインデックスを用いるオブジェクトを描画することを指示す ることができ、そのため、色空間から視覚的なジオメトリーが抽出され、アプリ ケーションは現在用いられている特定のジオメトリーと／あるいは色を知る必要 がなくなる。本実施形態に従えば、パターンテーブル４８は、パターン／色のデ ータベースとして動作、クライアントに対し関連するパターンの情報を返答する 。 テーマ間の切替のための機能を供給するために、テーマ切替スイッチ５０とラ ンタイムサポートコントロール５２は形態マネージメントレイヤーとテーマの相 互作用を制御する。ここで用いる、「テーマ」という言葉は、ディスプレイ上で 、異なる視覚的な形態を生成するインタフェースオブジェクトとオブジェクトパ ーツの設計を調整するものである。ロードまたはロードしないテーマ、テーマの 属性を得るためのメカニズムをこれらのルーチンが提供する。多様なルーチンは 、ブロック５４示すインタフェースにおいて、アニメーション、サウンド、デス クトップパターンとスクリーンセーバーの扱いをサポートすることも提供する。切替ポインタと描画処理 ユーザーインタフェースで描画される多くのオブジェクトは軽い処理によって 生成され、システム上の基準コードの一部分が、例えば、ウインドウの枠を描画 するような特定の目的に関わる。これらのコードの一部分は、ここでは、描画処 理あるいは定義処理（defprocs）と呼ばれ、動的なシステムの形態と動作を可能 にするランタイムにおける切替のために設計される。テーマ間の切替に対する処 理及びメカニズムの詳細は後述し、このセクションでは、切替可能なルーチンの 形態を提供するために設計されるこれらの処理方法一例に焦点を当てる。 形態マネージメントレイヤー４０は、ユーザーインタフェースの形態と動作の 切替 を許す複合される多様な変更に対し処理可能である。描画処理が切替可能である ような２つの方法例をここでは説明する。 実施形態に従えば、描画処理の切り替えをサポートするすべてのユーティリテ ィは、特定のユーティリティによってサポートされるインタフェースオブジェク トに対するすべての描画処理に対し「ディスコネクト」（disconnect）と呼ばれ る。要点としては、現存のすべてのユーティリティオブジェクトそれぞれに対す る描画処理に削除メッセージが送信されることである。このユーティリティは、 ポインタ４４と描画処理を取り替えるものといえる。例えば、ウインドウ描画処 理Ａがウインドウ描画処理Ｂによって配置替え可能である場合、ウインドウ描画 ユーティリティは、処理Ｂに関連する内容を持つ処理Ａに関連する内容のすべて を配置替えするように要求される。この過程は、切り替えられる描画処理それぞ れに生じる。最終的には、ユーティリティインタフェース要素に対するすべての 描画処理には初期化メッセージが送信されると、ディスプレイは完全に再描画さ れる。 本発明の他の実施形態に従えば、これらの描画処理は、処理のコードの変更な しに多様な形態と動作の広いサポートをできる処理を許すようなデータ処理がな される。この方法では、テーマは描画処理コードを切り替えることなく切り替え られる。それぞれのテーマは、変数的描画処理に供給されるテーマ自身のデータ 構造を提供する。これらの実施形態について詳述する。 本発明の実施形態に従えば、システムが提供する描画処理は、実行されている 処理から互換性のあるシステムへと直接マップする。例えば、それぞれの描画処 理は周知の処理（例えば、ＷＤＥＦ１，ＣＤＥＦ０，ＣＤＥＦ１）に対応する。 このマッピングは、例えば、以下に示す処理形態でマッピング処理の一例によっ て成し遂げられる。この処理例では、新規な描画処理も周知の描画処理も同じ扱 いでロードすることができる。 上記に示す、第１ステップは、処理のリソースＩＤをコールするために定義さ れるものである。これが、リソースチェインに配置される旧式の処理あるいはシ ステムファイルからのスタッブリソースをロードする。スタッブリソースは、周 知の処理メッセージを要求してデコードし、そのデコードしたメッセージに基づ いて対応する新規な描画処理をコールする時の基本単位である。このように、描 画処理に用いる新規なインタフェースオブジェクトをユーティリティが生成する と、最適なスタッブリソースがロードされ、オブジェクトのデータ構造を扱う処 理領域にそのロードされる量がストアされる。ユーティリティはコールする描画 処理を切り替えることができるので、インタフェースオブジェクトを生成する描 画処理の設定を動的に変更する能力を利用できる。 本発明の他の実施形態に従えば、描画処理は、常にテーマの変更の切替を必要 としないため実質的に変数的にすることができる。その代わり、これらの処理へ のデータ の供給はテーマとともに変更される。この実施形態の説明は、これらの処理動作 で用いられるデータから始める。 本発明の実施形態に従う構造処理を動作させるために用いられるデータ構造は 、インタフェースジオメトリー要素とインタフェース動作要素データとして分類 することができる。簡単な規則に基づくビューシステムと一緒にリンクされる任 意のジオメトリーオブジェクトのリストによって、オブジェクトジオメトリーは 特定される。それぞれのオブジェクトジオメトリーは、任意のサイズと形を有し 、水平あるいは垂直方向に繰り返しても良い。ウインドウ描画処理（例えば、Ｗ ＤＥＦｓ）、メニュー描画処理（例えば、ＭＤＥＦｓ）のような描画処理は、イ ンタフェースオブジェクトの構造領域を描画し計算するためにこれらのジオメト リーリソースを用いることができる。 このジオメトリーモデルを定義するリソースは、テーブルＡに示す４つのパー トに分けられる。第１に、オブジェクトの中でグリフのエッジを特定するために 用いられる水平及び垂直境界線を配置するオペレーションコードのリストがある 。それぞれの境界線は、元となる形の部分（例えば、ウインドウを定義する矩形 、あるいは他のオブジェクト、作業領域）あるいはあらかじめ定義された境界線 であるリファレンスに関連して配置される。オフセットは、一定あるいはシステ ムによって認識される値、例えば、ウインドウタイトルの高さの値にすることが できる。それぞれの境界線が配置される時は、限界境界線とリファレンス境界線 との間で新規な境界線が入るような 限定を特定することができる。限界境界線は、ジオメトリー要素にそれらをサポ ートするために元となる形が小さくなりすぎて消えてしまうことを許可している 。 第２に、ジオメトリーリソースは、グリフのリストを含むことができる。それ ぞれのグリフは、ピクセルパターン、ビットマップイメージあるはアイコンから 引き出すことができる。更に、それぞれのグリフは、正しい方向での描画を与え ることを結びつけるコーナーを特定することもできる。 第３に、２つの水平及び２つの垂直境界線でグリフの１つを合成したものを、 ジオメトリーパーツのリストにすることができる。インタフェースオブジェクト のそれぞれの様式に対しては、必要かつオプション的なパーツにしても良い。例 えば、ウインドウは、クローズボックスあるいはボタンを持つことを必要とされ るが、ウインドウの形態を強調するために用いられる多くのオプション的なパー ツに含ませても良い。 最後に、すべての境界線とパーツは、その存在する状態で特定することができ る。例えば、クローズボックスと１つあるいはそれ以上の境界線はウインドウが インアクティブな状態では存在しない。この特定は、特定の状態で実行されるコ ンピュータ処理と描画の量を減らす。それぞれのインタフェース要素は、ジオメ トリーリソースが遷移する時に用いられるあらかじめ定義された状態の設定を持 っている。このメカニズムに対する他の方法としては、オブジェクトの特定状態 でパートの形態を変更することである。例えば、グリフが非動作であるときのウ インドウの下部のエッジの形態を変更するために、２つの下部のエッジパーツは 異なるグリフを用いて定義される。これらのパーツの一つは、ウインドウがアク ティブのときのみに存在し、その他のパーツは非アクティブのときに存在しても 良い。図２Ｂに示すテーマの一例においてドキュメントウインドウを表現するた めに用いることができるグリフのセットを、図５に添付したグリフのテーブルと して示す。水平及び垂直境界線は、テーマに対し所望する外観を生成するために ウインドウの周囲にすべてのグリフを配置するように構築される。 データ駆動構造処理において用いるデータ構造の第２の分類は、オブジェクト の動作に関連する。これらの状態テーブルは、ある状態からある状態への遷移に 関する情報とともに、これにより表される制御の状態のビットマップあるいはグ リフを含んでいる。それぞれの遷移は、１つあるいはそれ以上の、例えば、アニ メーションシーケ ンス、サウンドあるいはカスタム遷移を実行するためのルーチン、アルゴリズム 的なディスプレイあるいはそれ以外の遷移の影響の様式を含んでも良い。ユーザ ーインタフェースのオブジェクト及びオブジェクトパーツの対する状態図の定義 によって、テーマ開発者が、それぞれの状態遷移に対するカスタマイズされたグ リフの配置や、所望の状態制御の間での遷移をカスタマイズすることも許可する テンプレートが生成される。ウインドウオブジェクトのチェックボックスの制御 に対する共通な状態遷移と可能状態の一例を提供する状態遷移図の一例を図６に 示す。 図６に示されるように、このチェックボックスの一例では、表示することがで きる９つの可能状態を持っている。これらの状態には、３つの制御値のそれぞれ に対し３つのハイライト状態が含まれている。通常に用いる場合で、ユーザーが 未チェックのチェックボックス（状態Ｑ１）をクリックすると、チェックされた 状態（状態Ｑ４）に制御が移動する。マウスが開放された後は、制御は元の状態 （状態Ｑ１）に戻り、ボタンが押下されたことがアプリケーションへ通知される 。アプリケーションは制御値を新規な制御値に切り替えて、チェック（状態Ｑ２ ）されても良い。 本発明に従うデータ駆動テーマにおいて、リソースには、それぞれの制御の状 態に対し新規なグリフあるいはビットマップをつなぐことをテーマ開発者に許可 するためのカスタマイズ可能な制御が存在する。更に、状態と制御状態テーブル との間での遷移をカスタマイズにより融通性を提供するために、これらの遷移に 対するマトリックスが提供される。ここで、図７に示すマトリックスの一例に注 目する。マトリックス内のそれぞれのブロックは、テーマ開発者は、アニメーシ ョン、サウンドのような映像と／あるいは音響出力、例えば、カレイドスコープ ディスプレイあるいはそれらの組み合わせに対するアルゴリズム的な遷移の様式 を実行できるカスタム遷移処理を提供することができる。もちろん 特定されな い遷移形態がないは、テーマ開発者によって遷移マトリックスのすべてのボック スは満たされる必要はなく、あるいはテーマが特定の遷移形態を特定しない場合 、遷移の影響を受けずに新規な状態に対し特定されるグリフあるいはビットマッ プへ直接制御が移る。 上述の２つの実施形態では、コードあるいは描画処理のデータの切替について 説明したが、これらの２つの方法が同じインタフェース上で実行されるというこ とが当業者により認識されるであろう。例えば、インタフェースの高速な再描画 を提供するた めのハードコード化した描画処理を通じて、あるテーマ、例えば、関連性のある 単純なパターンを用いるテーマを生成することで効果が生じる。同様に、例えば 、関連性のあるより複雑な表示がテーマである場合、上述のデータ動作描画処理 を用いたデータを生成することで効果が生じる。これに応じて、ユーザーに選択 に対し多くの異なるテーマの様式を利用できるので、上述した２つの実施形態が 同じインタフェースで配備され、切替可能なポインタが適当なハードコード化さ れた処理あるいは変数的な描画処理を指示することを見越せる。 カスタム描画処理は委任あるい転送として知られる形式を使用する形態を提供 するシステムから受け継ぐことができる。委任は、受け継いだ動作が所望される と、他のオブジェクトに対し制御を以降することを含む。描画処理が動的にイン タフェースを変更してはする特定のオブジェクトを決定するためには、クライア ントがシステム内にコールできるかあるいはシステムがカレントの実行を追跡で きるかのいずれかである。本実施形態に従えば、この負担は再方向の付加的なレ イヤーの提供によるシステム上に配置される。図８に示されるように、ユーティ リティ６１はカスタム描画処理６３をコールする。描画処理６３は適切な実行６ ７あるいは実行６９を委任する切替器６５を受け継ぐ。この受継の様式の一例は メニュー描画処理を用いることで表現される。 テーマは、そのテーマに対する標準メニュー描画を制御するメニュー描画処理 を提供する。多くのアプリケーションでは、カスタマイズされたメニューアイテ ムを有している場合、テーマは、メニューのシングルアイテムの形態あるいは動 作を変更するだけでよい、この間は、システム定義テーマが制御中であるとして メニューの表示と動作は保持され続けている。例えば、切替器オブジェクトのよ うなシステムメニュー描画処理を受け継いでカスタムメニュー描画処理が生成さ れることによって、アプリケーションはユーティリティが発行するコマンドから メニューアイテムを描画するためのコマンドを得ることができる。描画されるメ ニューアイテムは、テーマによってカスタマイズされた形態と／あるいは動作を 持つアイテムであり、テーマメニュー描画処理はそのアイテムを描画するために 用いられる。別の方法では、切替器によって指示される受継コードがアイテムを 描画するためにコールされる。 この例では、テーマはあるメニューアイテムだけをカスタマイズし、テーマカ スタ ムメニュー描画処理は、そのアイテムを描画するためにシステムだけを無視し、 他のアイテムはその学んだコードを用いて描画される。パターンルックアップテーブルと描画サポート パターンルックアップテーブルメカニズム４８について、以下、詳細に説明す る。上述の説明では、本発明のオブジェクトの一つはデスクトップの形態に対す るユーザーの制御を容易にするインタフェースを提供するので、形態マネージメ ントレイヤー４０によって用いられるテーマは、例えば、カラーパターン、ピク セル単位で定義されるパターン、ビットマップイメージ等のインタフェースを描 画するために多様なカラーデータで操作されるべきである。パターンテーブルは 、カラーデータを特定するための方法及びシステムを提供するため、テーマカラ ーの設定はリソース編集ユーティリティを用いたテーマから独立して編集される 。パターンテーブルはペンパターンと色の概念の属性によるサポートを提供し、 アプリケーションあるいはテーマに特定の色設定がロックされることなくインタ フェース部分を描画することを許可する。 パターンルックアップテーブルを含むメカニズムによって本発明の実施形態に 従う機能が提供される。パターンルックアップテーブルのインデックスは色に対 するデータを参照し、ピクセル単位、ビットマップイメージあるいは他のデータ に基づいてパターンを定義するため、クライアントはパターンルックアップテー ブルの入力に含まれるデータタイプについてなにも知る必要がない。データの独 立性の重要性が固定の色のウインドウを持つテーマであることは、例えば、単純 なテーブルの入力の編集によってテーマソースコードを変更しないで複雑なパタ ーンのウインドウを描画する代わりに変更できることである。以下、定義する「 パターン」は、グラフィクポートで描画するためのパターンルックアップテーブ ルで用いられる表示データの様式を表示するためにのものである。このパターン は、例えば、赤、緑、青（ＲＧＢ）の色成分で定義される３原色、あるいは、例 えば、PixPat、あるいは新規なデータ様式のピクセル単位で定義されるパターン でも良い。 パターンテーブルルーチンの多様な形態の詳細を説明する前に、実施形態に従 う色とパターンの抽出の提供のされ方の概要を図９を参照して説明する。クライ アント６０は、形態マネージメントレイヤーに対しThemeFillRect（kColorindex ）コマンドを送 信する。このコマンドは、形態マネージメントレイヤー４０によって実行される 描画の設定の一つである。特に、この実施形態では、このコマンドは、kColorIn dexとして特定されるパターンで満たされる矩形を描画するためのコマンドであ る。kColorIndexの値はデスクトップ上の所定のオブジェクトあるいはオブジェ クトパーツに対応する。例えば、インデックス３はウインドウタイトルカラーに 対応する。しかしながら、クライアント６０が、同一の色とみなす完全なインデ ックスだけがウインドウタイトルカラーとされる特定の色の知識を持つ必要がな いことに注目する。 kColorIndexパラメーターはパートインデックステーブル６２の入力に対応す る。この入力は、テーマパターンルックアップテーブル６４へとマップする。上 述したように、テーマパターンルックアップテーブル６４の入力は、あらゆるフ ォーマットの色あるいはパターンデータの様式を含むことができる。この例の目 的は、kColorIndexの値に対応するパートインデックステーブルの入力が黒と白 の交差パターンを参照する「xpat」と呼ばれるパターンへマップすることを示唆 している。黒と白の交差パターンの描画に対する処理におけるパターン定義処理 テーブル６６で対応する入力を持つ「Xpat」が配置される。「xpat」によって定 義されるコマンドを解釈する処理ポインタ６８を含むテーブルは、ディスプレイ 上でパターンを描画するためのシステムによって使用されるグラフィックシステ ム５６によって認識されるコマンドへ記録される。これらのコマンドは、デスク トップインタフェース上の最適な点でパターンを表示するグラフィックサブシス テムへ送信される。 図８に示す実施形態では、形態マネージメントレイヤーを介してグラフィック サブシステムへコマンドを送信するための描画を使用するクライアントについて 述べたが、本発明の他の実施形態は異なる態様で扱う。本実施形態に従えば、形 態マネージメントレイヤー４０はグラフィックサブシステム５６に命令を発行し ないが、パターン／色データベースとして実質的に振る舞う。例えば、図１０の ブロック図では、獲得するテーマパターンコマンドは、図８の描画の代わりに形 態マネージメントレイヤー４０へ送信される。形態マネージメントレイヤーは、 獲得したテーマパターンコマンドで要求された特定のインタフェースオブジェク トあるいはオブジェクトパートに対して実行中のテーマのグラフィックサブシス テムによって与えられるパターン構造を、デスクトップインタフェース上の最適 なパターンと／あるいは色を描画するために コマンドをグラフィックサブシステムに送信するクライアントへ返答する。 このように、パターンテーブルの使用を通して、デスクトップオブジェクトの 色と／あるいはパターンは、パートインデックステーブル６２と／あるいはパタ ーンルックアップテーブル６４の値の変更によって、あるテーマから他のテーマ へ容易に切り替えることができる。このパターンの切替はアプリケーションに対 し完全に明瞭となる。この結果、アプリケーション自身を変更することなく新規 なパターンが付加される。ここでは、本発明に従うパターンと色の属性の概要を 説明し、次に、上述したルーチンの実行例の詳細な説明を提供する。 実施形態に従う形態マネージメントレイヤーは、可能な描写の命令（primithi ves）の設定が認識され、例えば、システムのグラフィックサブシステム（例え ば、QuickDraw）による使用から引き出される。これらの命令は、グラフィック サブシステムの対応物として同じコーリングシーケンスを持つことができるが、 要求される描画コマンドの色と／あるいはパターンの詳細を特定するためのテー マパターンテーブルへとインデックスが用いられる。以下、描画の命令例をイタ リック表記で示す。 形態マネージメントレイヤーは、標準の形態でビーベルとダイアログ矩形のグ ループをクライアントによって描画するために用いられるグループ、ビーベル、 テキスト、グループ化されたダイアログ矩形の設定を定義することもできる。こ れらのルーチンの実行は、特別な形態を生成するテーマによって無視することが できる。この理由としては、クライアントはユーザーインタフェースオブジェク トパーツに対する形態マネージメントレイヤーとは独立してビーベルを描画すべ きではないからであるが、提供される命令となる言語を代わりに使用すべきであ る。以下、これらの命令例の記述を示す。 パターンルックアップテーブルは、上述の描画を表現するための基礎となる言 語ある。、は単独で描画の要求を扱うパッケージの部分として提供され、また、 テーブルについては、ここで詳細に説明する。 パターンデータ構造は、パターンを描画するために必要なデータを保持する。 例えば、以下に示す構造を持つことができる。 パターンデータ構造は、例えば、パターンと／あるいは色情報をストアするため に８バイト構造とすることができる。パターンに対するデータの要求が８バイト 長以上である場合、作業領域とパターンデータ構造を扱う領域が確保される。以 下、説明するパターン定義処理は、パターンデータ構造の相互作用とロードが果 たされる成分である。 パターンルックアップテーブルは、テーマによって用いられる色とパターンの リストを特定する。パターンルックアップテーブルは、例えば、図９の「xpat」 にpattem Specを記録するような記録のリストを含み、それぞれの記録は、ロード、非ロー ド、描画を行うための特定の処理の参照や分類がなされる。 データ パターンルックアップテーブルの入力を含むデータのカプセル化は、 パターン定義処理の使用を介して果たされ、コードの基本単位は、例えば、図９ のブロック６６の「xpat」のパターン定義処理のような、ロード、非ロード、パ ターンルックアップテーブルの入力データの解釈を果たす。新規なパターン様式 は、単純に追加される新規なパターン定義処理によるアルゴリズム的な色とパタ ーンの生成のような特定の要求に対するテーマによって定義される。パターン定 義処理は、例えば、上述のような入力点のリストを転送するコードの基本単位の 断片あるいは動的にロードされるライブラリーとして定義される。実行されない 入力点に対するデフォルトの形態は、エラーを返答することである。 パターンルックアップテーブルは、アプリケーション内のルックアップテーブ ルの恩恵を許可するアプリケーションによってメモリに生成しても良い。パター ンルックアップテーブルの生成のためのアプリケーションプログラムインタフェ ース（以下、ＡＰＩと称する）例を以下に記述する。 テーマは、アルゴリズム的にパターンを定義するような特別なテーマの特定の 形態の長所を得るための新規なパターン様式を定義することができる。このよう に実行することで、テーマはパターンタイプを定義するリソースあるいはコード の基本単位の断片の登録あるいは動的にロードされるライブラリの使用、例えば 、後述するInstallPattemDefinitionコマンドを提供する。パターン定義処理に はシステムの内部の様式のリストが追加され、ロード、非ロード、様式に対応す るパターンの描画を行うために直接コールされる。このコードはコードの基本単 位の断片あるいは動的にロードされるライブラリーとして記憶され、その様式を 参照するパターンルックアップテーブルの入力があるまではロードが保持される 。この理由としては、他のアプリケーションによって定義が用いられる場合に非 ロードが行われるパターンをテーマが生成した後でさえも、パターン定義がイン ストールを保持できるからである。 パターン定義処理がインストールされると、内部パターン定義テーブルを追加 することができる。速度に対しては、これらのパターン定義処理はパターンルッ クアップテーブルの様式によって参照するよりもインデックスによって参照する ことができる。パターンルックアップテーブルに新規なパターンが追加されると 、パターン定義テーブルが調べられ、パターン様式に対する定義のインデックス が新規なパターンに対する記録の中に加えられる。新規な様式が追加されると、 それらはリストの最後に追 加することができる。 内部パターン定義テーブルに新規なパターン定義処理が追加されると、パター ン定義を含む転送されたポインタを含んだリストが構築される。標準ポインタが 定義されない場合、それらは実行されないエラーを単純に返答するデフォルトの ポインタを設定する。図９を参照した説明において、パターンが描画されると、 ルックアップテーブル内にパターンが発見され、そのパターンに対応するパター ン定義処理が配置され、必要な機能ポインタがコールされる。 以下に示されるパターン定義処理例では、ルックアップテーブルからピクセル 単位で定義されるパターンを得るために処理が用いられ、同様に描画することを グラフィックサブシステムに指示する。 形態マネージメントレイヤーは、すべてのクライアントに対しインデックスが 利用できるように、それぞれのテーマパターンルックアップテーブルに含まれる 共通のパターンインデックスの範囲を定義することもできる。これらの範囲は、 例えば、通常のメニューバーの背景のような、ビーベル、グループ、利用できる 他のパターンを生成するために使用されるパターンの設定を含んでいる。通常の メニューバーの背景のインデックスは、メニューバーの色で形を描画するための 標準的なテーマ描画ルーチンの一つをパスしても良い。以下、この目的に対する 、定義される共通のパターンインデックスの設定例を示す。 加えて、これらの定義される様式例では、テーマが内部で用いられる追加様式 を定義しても良い。これらの追加様式には、例えば、上記の例で与えられる１６ ３８４のような、利用できる２番目に高いインデックスから先頭までシーケンシ ャル的にインデックスが付けられる。 以下に、形態マネージメントレイヤーの使用に対し定義される３つのパターン 様式例を示す。ここでは、RGBcolorコマンドが、オブジェクトあるいはオブジェ クトパートを描画するための赤、青、緑の色の組み合わせを特定する。ColorPat temは、それぞれの色がRGBcolorで特定される前部と背景色を２色の８×８のピ クセルパターンで表現する。ColorPattemの様式の定義例を以下に示す。 PixPat様式はピクセル単位で定義される任意のパターンを特定し、その設計領 域はグラフィックサブシステムによってパターン内容で満たされるあるいは描画 されても良い。PixPat（Pixcel Pattem）データ構造はグラフィックサブシステ ムによって定義され、ピクセル単位のパターンを含むために用いられる。 テーマは、以下に説明される形態マネージメントレイヤーによって用いられる 標準的なパターンルックアップリソースの設定を提供する。パターンルックアッ プテーブルは、テーマによって用いられる色とパターンの設定を定義し、テーマ のパターンルックアップテーブルを構築するために用いられる。パートインデッ クステーブルは、パターンルックアップテーブル内に標準的なテーマパターンイ ンデックスの設定をマップする。PattemLookupTableとPartIndexTableの実行例 は、 上述したように、本発明の他の実施形態は、グラフィックサブシステムに直接 コマンドを指示する形態マネージメントレイヤーよりもむしろクライアントへの 情報の返答によってパターン／色の要旨を提供する。これらの実施形態に従えば 、クライアントは、特定のインデックスに対応する、例えば、PixPat構造のよう な構造に対する形態マネージメントレイヤーに要求し、グラフィックサブシステ ム５６へ最適な描画コールを生成することをアプリケーションに許可するきっか け受け取る。以下、この実施形態の処理を示す。 これらの実施形態に従うパターンルックアップテーブル４８とクライアントが どうのようにして相互に作用するかの他の例を、以下に示す。 ここで説明したパターンルックアップテーブルにおける２つの典型的な実施形 態は、インタフェースからパターンと色を抽出するために用いられ、他の例では 、以下に示す、ビーベルの背景色でウインドウ矩形をファイルし、ウインドウ内 に２つのピクセルを挿入してビーベルを描画する典型的なアプリケーションに適 用される両方の実施形態が提供される。第１に、形成を通して、実施形態の描画 を表現するための基礎となる言語が、形態マネージメントレイヤーに送信される 。 ここで、形態マネージメントレイヤーがクライアントへ返すデータ構造の例を 以下に示す。 もちろん、ここで提供される疑似コードは通常表記で典型的なものとして当業 者に認識されるであろう。テーマおよびテーマ切替 上記では、切替が可能な描画手順及びパターンルックアップテーブルを用いて 、その機能からユーザーインタフェースの形態と動作を抽出するための典型的な システム及び方法を説明した。以下の説明では、共通のテーマを推進するために 互いに混じりあわせる、ユーザーインタフェース上の形態と動作の属性の設定を 示すためにこれらの能力がどのように互いに用いられ得るかを示す。前述のよう に、テーマはインタフェース成分の調整されたデザインであり、これら成分はデ ィスプレイ上の異なる映像的及び音響的環境を生成するために結合される。本発 明の典型的な一実施形態によれば、例えば、デスクトップインタフェース上で動 作され得る形態コントロールパネルから異なるテーマを選ぶことができる。典型 的な形態コントロールパネルは図１１に示す通りである。 図１１において、ポップアップメニュー、プルダウンメニューあるいはドロッ プダウンメニュー１４０は、インストールすべきテーマを選択することにより、 ユーザーがあらゆる形態／動作を指定することを可能とする。セッテイングボッ クス１４０の左下には、ユーザーが各テーマ内で種々のオプションを選択するこ とができるオプションエリア１４２がある。例えば、ユーザーは背景色、フォン ト及びハイライト色を指定できる。オプションエリア１４２の右には、プレビュ ーエリア１４４がある。プレビューエリア１４４には、ボックス１４０で現在選 択されているテーマの典型的なインタフェース成分が示される。これによって、 ユーザーは、選択を行う前にそのテーマがどのようなものであるかをプレビュー することができる。典型的なインタフェース成分は、例えば、デスクトップパタ ーン、メニューバーとメニュー、アクティブウインドウや、ラジオボタン、チェ ックボックス、プッシュボタン及び選択テキスト を有するダイアログボックスを含む。この形態コントロールパネルを用いて、ユ ーザーはデスクトップの形態を速やかにかつ容易に変更することができる。 しかしながら、デスクトップインタフェースの形態や動作に関してより制御す ることを望むユーザーがいるかもしれない。このため、本発明の他の典型的な実 施形態によれば、形態コントロールパネルは、ユーザーインタフェース上に表示 され得る全てのオブジェクトに関してユーザー選択を可能とすることができる。 例えば、形態コントロールパネルは各種のインタフェースオブジェクトのライブ ラリを含むことができる。そしてユーザーは、そのライブラリからユーザー定義 のテーマに含めるためにオブジェクトを選択することができる。インタフェース オブジェクトの異なるタイプの各々の一つを選択した後、ユーザーはテーマ名の 入力を促される。そして、このテーマ名のもとで、適切な描画処理や選択された オブジェクトを実現するための他の情報へのポインタが格納される。本発明の更 に他の典型的な実施形態によれば、形態オブジェクトエディタが提供され得る。 ユーザーは、オブジェクトエディタによって提供されたパーツのライブラリを用 いて、固有のインタフェースオブジェクトを生成することができる。例えば、図 ５に示されるグリフの各々は、多くのバリエーションを有することができ、これ らを用いてユーザーは独自のドキュメントウインドウを生成することができる（ アクティブ状態、インアクティブ状態の両方）。生成されると、その新規なイン タフェースオブジェクトは、インタフェースオブジェクトのライブラリに格納さ れる。そして、ユーザー定義されたテーマはこのライブラリから生成される。 テーマ属性は、システム定義され、テーマ定義されたテーマプロパティの集合 である。テーマプロパティの各々は、形態マネージメントレイヤーファンクショ ンによって要求を受けたり設定されたりすることができる。例えば、以下のプロ パティはシステムによって定義される。 テーマプロパティを得るために、例えば、以下のようにして、テーマプロパティ 獲得 関数がコールされる。 この関数は、現在のテーマ（カレントテーマ）から要求されたプロパティを返す 。カレントテーマが要求されたプロパティを含まない場合は、typeNotFoundErr が返される。 テーマプロパティをセットするために、SetThemeProperty関数をコールする。 SetThemePropertyコマンドは、指定されたテーマプロパティを与えられたデータ に設定する。以上、テーマを概略的に説明するとともに、ユーザーによるテーマ の生成、選択、格納方法を説明した。以下、ユーザーもしくはアプリケーション によってテーマの変更が要求されたときの本発明に係るシステムおよび方法の作 用を説明する。まず始めに、図１２を用いて説明を行う。 図１２は、テーマ７０、形態マネージメントレイヤー４０、アプリケーション ３８の間の相互作用の例を示す図である。ここで、ブロック４８は上述のパター ンテーブルを含み、ブロック５４はブロック５２のランタイムルーチンを補う、 アニメーション及びサウンドユーティリティを含む。更に、例えば、エンドユー ザーがテーマを切り替えるために操作することのできる図１０のパネルのような 形態コントロールパネル６９を図解的に表わすアイコン６８が示される。 カレントテーマのリソースチェーン７２は、テーマ切替５０とランタイムルー チン５２によってオープンされ、管理される。リソースチェーン７２は、例えば 、テーマ属性プロパティリスト（例えば、上述のような動作マトリクス）、テー マプレファレンス（例えば、好みの背景パターン、好みのシステムフォント等） 、テーマデータリソース（例えば、テーマによって使用されるパターンや色のセ ットを定義するパターンテーブル、新規なパターンの様式の定義を可能とするパ ターンコード処理）及びオーバーライドリソース（例えば、システムアイコンを オーバーライドするテーマ用の アイコン）を含むことができる。テーマリソースチェーンは、現在実行中のアプ リケーションのリソースとは別に維持され得るし、アプリケーションあるいはユ ーザー（形態コントロールパネル）の要求に応答してスイッチイン、スイッチア ウトされ得る。形態マネージメントレイヤー４０が何等かのテーマのコードをコ ールするときはいつもテーマのリソースチェーン７２がセットアップされる。 本発明の典型的な実施形態に基づく切替可能な描画処理に関して上述したよう に、形態マネージメントレイヤーが存在する場合は、図１１のブロック７４〜８ ０にある一般的な描画処理（例えば、ＣＤＥＦ、ＬＤＥＦ、ＭＤＥＦ及びＷＤＥ Ｆ）が形態マネージメントレイヤーの切替リソースによって置き替えられる。外 部的には、これらの切替リソースは、伝統的な描画処理と同一の機能をもたらす 。内部的には、それらは、テーマが変更されたとき、ユーティリティによる適切 な描画処理への動的な切替を許可する。この切替は、切替リソース７４〜７８に よって参照される描画処理への新規なポインタ８３〜８８を供給することで達成 され得る。この方法において、上述のようにユーティリティ内へ切替リソースが 呼び戻される場合、ユーティリティはカレントテーマのための描画処理に方向付 けられる。 カレントテーマは形態マネージメントレイヤーのテーマ設定のための関数をコ ールすることで、例えば、以下のコマンドによって、設定される。 テーマ設定関数は、FSSpecパラメータを用いる。このパラメータは、形態マネ ージメントレイヤーによってロードされ、動作されるべきテーマファイルを識別 する。通常動作において、この関数は要求されたテーマファイルをロードし、新 規なテーマに切り替え、旧テーマを解放する。旧テーマは、新規なテーマが完全 にロードされた後に解放される。これは、新規なテーマを動作できなかった場合 に、ユーザーがインタフェース無しといった状態に陥ることの無いように、シス テムがオリジナルのテーマに戻されるようにするためである。 図１３のフローチャートに示されるステップは、新規なテーマファイルをオー プンするために実行される。ブロック１００において新規なテーマの情報（info ）レコードが生成される。このデータ構造は、形態マネージメントレイヤーがカ レントテーマ の状態のトラックをキープするのに用いる全てのグローバル情報を含み、また、 その固有のリソース情報を含む。ここで、リソース情報としては、例えば、切替 器のための処理ポインタテーブル、テーマプロパティリスト、テーマパターンテ ーブル等である。 次に、ブロック１０２において、形態マネージメントレイヤーは新規なリソー スチェーンを生成する。新規なテーマのリソースファイルが１０４でオープンさ れ、その後、テーマのルーチンコードが１０６でロードされ、そのオープン関数 がコールされる。このとき、新規なテーマは、ロードを続行するべきか中止すべ きかを決定するために、システムの動作状態をテストすることができる。ロード を中止すべき場合は、なぜテーマをロードできなかったかについて、そのテーマ がユーザーに警告を提示するようにしてもよい。もし、テーマが固有のプレファ レンスファイルを有するなら、そのファイルはこの時点でテーマによってオープ ンされ得る。 テーマのプロパティリストはブロック１０８にて、例えば、リソース獲得関数 をコールすることでロードされる。これは、プロパティリストが、前のステップ でオープンされたあらゆるプレファレンスファイルから得ることを可能とする。 プロパティリストがみつかると、それはテーマ情報レコードに格納される。続い て、ブロック１１０において、テーマのパターンルックアップテーブルがロード される。最初に、全てのパターン定義処理リソースがロードされる。そして、標 準パターンルックアップテーブルとパートインデックステーブルリソースがロー ドされる。パターンルックアップテーブルはこれらのリソースの内容から構築さ れる。そして、ブロック１１２によって示されるように、切替リソースによって 用いられるポインタが構築される。このテーブルはテーマ情報レコードに格納さ れる。最後に、新規なテーマのイニシャライズ関数がブロック１１４でコールさ れる。新規なテーマは、メモリを配置でき（アロケート）るか、あるいはそれが アクティブである間に必要とする特別なリソースをロードできる。 図１４は、旧テーマから新規なテーマへ切替を実行する各ステップを示す。ま ず、ブロック１１６において、遷移の影響が提示される。例えば、スクリーンを 黒く消していったり、ダイアログを提示させたり、モーフィングのようにあるも のから他のものへ徐々に合成させながら切り替えていくことを行う。そして、旧 テーマのリソース チェーンはブロック１１８において、スイッチインされる。全ての描画処理は、 配置解除（deallocate）メッセージとともにコールされる。これらのメッセージ １２０は、現在、旧テーマの定義処理の遂行にメッセージを発送している形態マ ネージメントレイヤーの切替定義処理に送られる。これは、テーマの定義関数に それらがアロケートされていたあらゆるグローバルデータを配置解除することを 許可するものである。 形態マネージメントレイヤーは、１２２において、新規なテーマ情報レコード をカレントテーマの情報レコードとして設定する。新規なテーマ情報レコードが 設定されると、形態マネージメントレイヤー内への全ての外部コールが新規なテ ーマに影響する。新規なテーマのリソースチェーンは、ブロック１２４において 切り替えられる。全ての描画処理はイニシャライズメッセージとともにコールさ れる。これらのメッセージは、現在、描画処理の新規なテーマの遂行にメッセー ジを発送している形態マネージメントレイヤーの切替リソースに送られる。これ は、あらゆるテーマの定義関数に、それらが必要とするであろうあらゆるグロー バルデータを配置することを許可するものである。 旧テーマファイルを解放するための各ステップが図１５に示されている。まず 、ブロック１２８において、旧テーマのリソースチェーンがスイッチインされる 。次に、旧テーマの配置解除関数が、１３０においてコールされる。テーマは、 そのイニシャライズメッセージを受けたとき、そのテーマが行ったあらゆるアロ ケーションを破棄する責任を負う。切替定義処理によって用いられた旧ポインタ テーブルはブロック１３２において破棄される。そして、旧テーマのパターンル ックアップテーブルとプロパティリストが、ブロック１３４と１３６によって示 されるように破棄される。旧テーマのリソースチェーン内のファイルは、クロー ズされ、旧テーマのテーマ情報レコードが破棄される前にリソースチェーンが破 棄される。（ブロック１３８、１４０）。 新規なテーマをオープンしたりロードしたりする間に、もしくは旧テーマから 新テーマへ切り替える間にエラーが発生した場合、切替は中止され、テーマ設定 関数はすでに成功的に完了した全ステップを反対方向にたどる。こうして、シス テムは、旧テーマを用いてインタフェースの生成を続行する。切替を中止させた エラーは、この間数によって返され得る。デフォルトのシステムテーマがスイッ チインされることを要 求するために、システムファイルへのFSSpecパラメータ、もしくはＮＩＬのいず れかがテーマファイルパラメータ内をパスする。 どのテーマファイルが現在アクティブであるかということを判断するために、 テーマ獲得関数が、例えば、以下のコマンドによってコールされ得る。 現在アクティブなテーマファイルを参照するFSSpecパラメータ値は、currentT hemeSpceパラメータにおいて返される。カレントテーマがデフォルトのシステム テーマである場合、システムファイルを参照するFSSpecが返される。カレントテ ーマのFSSpecを配置する試みの間にエラーが発生した場合、適切なエラーコード が返され、currentThemeSpceパラメータが変化せずに残る。 通常、カレントテーマのリソースファイルは現在実行中のアプリケーションの リソースチェーンには存在しない。これは、アプリケーション間でリソースの識 別が衝突することを防止するためである。形態マネージメントレイヤーは分離さ れたリソースチェーンを維持する。ここで、このリソースチェーンは、カレント テーマファイル及びカレントテーマがオープンしたあらゆる他のファイル（例え ば、プレファレンスファイル）を含む。形態マネージメントレイヤーがテーマ内 のコードを実行するとき、そのテーマのリソースチェーンが形態マネージメント レイヤーによってセットアップされる。ここで、テーマのリソースチェーンは、 テーマリソースを得るために使用される通常のGetResourceコールを許可する。 アプリケーションがカレントテーマのリソースへのアクセスの獲得を要求する場 合は、幾つかの関数が提供される。例えば、カレントテーマファイルからリソー スを得るために、リソース獲得関数がコールされる。例えば、 GetThemeResourceは、このコマンドがカレントテーマのリソースチェーンから リソースを得ることを除けば、GetResource関数と同じ機能を有する。 カレントテーマファイルからリソースを得る際に、更なる柔軟性が必要な場合 は、低レベルの形態マネージメントレイヤー関数である、GetThemeTopMapHandle が、カレ ントテーマのリソースチェーンの先頭（Top）を得るのに用いられてもよい。 GetThemeTopMapHandle関数は、カレントテーマファイル及び他のあらゆるオー プンされたテーマファイルと、全てのシステムリソースマップを含む先頭マップ ハンドルを含む。ユーティリティ関数を実行するとき、あるいはアプリケーショ ンコードの他の部分へ戻った後に、GetThemeTopMapHandle関数をスイッチインさ れたテーマのリソースチェーンを残すことを避けるために用いた場合は、警告が 発動されるべきである。テーマのリソースチェーンがスイッチインされたとき、 アプリケーションのリソースチェーンは非有効である。尚、テーマが変化したと き、このマップハンドル及び関連するリソースはもはや有効ではなくなる。よっ て、この値はキャッシュされるべきではない。 テーマは、テーマがロードされ始めたり、破棄され始めたときに形態マネージ メントレイヤーがコールする３つのテーマ定義関数を実現する。形態マネージメ ントレイヤーがテーマの切替を開始すると、直ちにテーマのリソースファイルが オープンされ、テーマの関数がコールされる。 あらゆるリソースが形態マネージメントレイヤーによってロードされる前に、 テーマのテスト関数がコールされる。この方法において、テーマはオペレーティ ングシステムの状態をテストする機会を有する（例えば、メモリやグラフィック 能力等）。テスト関数がエラーで返された場合は、形態マネージメントレイヤー はテーマファイルをクローズし、ローディングを続行しない。テスト関数がエラ ー無しで返された場合は、形態マネージメントレイヤーは、上述のようにテーマ のロードを継続する。 上述の典型的なテスト関数によって返されたテーマデータパラメータは、テー マによって、当該テーマがキープしておくべきあらゆるグローバルデータを配置 、格納するのに用いられる。テスト関数へのエントリにおいて、テーマデータパ ラメータはＮＩＬを指し示す。テスト関数（もしくは、あらゆる他のテーマ定義 関数）は、テーマデータによって指し示される値を変更してよい。このテーマデ ータはテーマがロード されて残っている間は一貫している。 形態マネージメントレイヤーが全てのテーマのリソースのローディングと各テ ーマの標準定義処理のローディングを終えたとき、テーマのイニシャライズ関数 がコールされる。例えば、 テーマのイニシャライズ関数は、形態マネージメントレイヤーが完全にテーマ をロードした後に、あらゆる特別な処理を行うために用いられ得る。それは、デ ータ構造を配置したり、付加的なリソースをロードしたり、プレファレンスファ イルをオープンしたり、そのテーマプロパティリストをセットアップしたりする 。テーマデータパラメータは、テーマのグローバルデータへのポインタを格納す るために有用なグローバル格納位置を指し示す。テーマのイニシャライズ関数が エラーを返した場合、形態マネージメントレイヤーはテーマの切替を中止する。 形態マネージメントレイヤーは、すでに決定したあらゆる配置を破棄し、そのテ ーマファイルをクローズする。 形態マネージメントレイヤーがテーマをアンロードするための準備をしている とき、テーマの破棄関数がコールされる。例えば、 破棄関数は、テスト或いはイニシャライズ関数の何れかによってなされたアロ ケーションを破棄する。そして、テーマファイルは、そのプレファレンスファイ ルにおけるあらゆるリソースを格納し、かつ／または、そのテーマプロパティを 設定するための機会を有するようになる。テーマがこの関数から戻った後、形態 マネージメントレイヤーは、形態マネージメントレイヤーのテーマのための全て の格納の配置解除を行い、テーマのファイルをクローズする。 上述した典型的な実施形態はあらゆる点において説明を意図するものであり、 本発明を限定するものではない。よって、本発明は、細部の実施における多くの 変形が可能であり、それらは本願の開示含まれる記述から当業者がなし得るもの である。そのような全ての変形や改造は、以下のクレームによって定義される本 発明の範囲及び精神の範囲内である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ， ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者 コブ， ジェフリー， アール. アメリカ合衆国 カリフォルニア州 94087 サニーベル， ホレンベック ア ベニュー 1475 (72)発明者 ジョンストン， ロバート， ジー． ジ ュニア アメリカ合衆国 カリフォルニア州 94087 サニーベル， イースト エル カミノ リール 870 アパートメント 535 (72)発明者 ウルリッチ， ロバート， アール. アメリカ合衆国 カリフォルニア州 94043 マウンテン ビュー ＃１ サン ルイス アベニュー 1983

Claims (1)

1. 【特許請求の範囲】 １．グラフィカルユーザインタフェースであって、 第１共通テーマが関連し、それぞれの表示形態を有するインタフェースオブジ ェクトの第１のセットと、 前記第１設定のセットにおけるインタフェースオブジェクトに機能が対応し、 前記第１テーマと異なる第２の共通テーマに関連し、それぞれの表示形態を有す るインタフェースオブジェクトの第２のセットと、 前記記第１テーマと前記第２テーマとを選択的に切り替える手段とを備え、 前記第１と第２のセットの１つを用いてインタフェースオブジェクトを表示す る ことを特徴とするグラフィカルユーザインタフェース。 ２．前記インタフェースオブジェクトの前記それぞれの表示形態は、該インタ フェースをオブジェクトを有するオブジェクトパーツの表示形態の属性によって 定義される ことを特徴とする請求項１に記載のグラフィカルユーザインタフェース。 ３．前記表示形態の属性は、サイズ、形、色、配置を含む ことを特徴とする請求項２に記載のグラフィカルユーザインタフェース。 ４．前記オブジェクトパーツは、ズームボックス、クローズボックス、スライ ダー、チェックボックス、ビーベル、セパレーター、グルーピングボックス、デ ィスクロジャートライアングル、ボタン、スクロールバーを含む ことを特徴とする請求項２に記載のグラフィカルユーザインタフェース。 ５．前記第１のセットのインタフェースオブジェクトの１つを備える前記オブ ジェクトパーツの少なくとも１つは、前記オブジェクトパーツの少なくとも１つ に付与する機能とは異なる第１の動作を示す前記インタフェースオブジェクトの １つを有する ことを特徴とする請求項２に記載のグラフィカルユーザインタフェース。 ６．前記オブジェクトパーツの少なくとも１つはクローズボックスであり、前 記第１の動作は影を付けることであり、前記機能はウインドウオブジェクトを閉 じることである ことを特徴とする請求項５に記載のグラフィカルユーザインタフェース。 ７．インタフェースオブジェクトの前記第２のセットにおけるオブジェクトパ ートは、前記少なくとも１つのオブジェクトパートと、前記機能においてユーザ が実行する結果に対応し、前記第１の動作とは異なる第２の動作を示す ことを特徴とする請求項５に記載のグラフィカルユーザインタフェース。 ８．前記第１テーマが前記第２テーマに切り替えられる場合の遷移の結果を生 成するイフェクトジェネレーターを 更に備えることを特徴とする請求項１に記載のグラフィカルユーザインタフェ ース。 ９．前記テーマを選択的に切り替える手段は、ユーザが選択的にテーマを切り 替えることができるコントロールパネルを備える ことを特徴とする請求項１に記載のグラフィカルユーザインタフェース。 １０．前記テーマを選択的に切り替える手段は、前記第１テーマに対応する描 画手順の第１のセットから前記第２テーマに対応する描画手順の第２のセットへ のポインタを切り替える手段を 更に備えることを特徴とする請求項１に記載のグラフィカルユーザインタフェ ース。 １１．前記テーマを選択的に切り替る手段は、前記第２テーマに対応するデー タ構造のセットを変数的な描画手順へ供給する手段を 更に備えることを特徴とする請求項１に記載のグラフカルユーザインタフェー ス。 １２．前記インタフェース自身から前記インタフェースオブジェクトの色とパ ターンの情報を抽出するパターンルックアップテーブルを 更に備えることを特徴とする請求項１に記載のグラフィカルユーザインタフェ ース。 １３．コンピュータシステムのユーザに対するグラフィカルインタフェース方法 であって、 それぞれ第１テーマに関連した表示形態を用いるインタフェースオブジェクト を表示する表示工程と、 選択されたテーマを前記第１テーマから第２テーマへ変更する変更工程と 前記変更工程の後に、それぞれ前記第２テーマに関連した表示形態を前記イン タフェースオブジェクトを使用して表示する工程と を備えることを特徴とするグラフィカルインタフェース方法。 １４．第１共通印象を表現する前記インタフェースオブジェクトのオブジェク トパーツに対する表示形態の属性を選択することによって前記第１テーマを定義 する工程と 第２共通印象を表現する前記インタフェースオブジェクトのオブジェクトパ ーツに対する表示形態の属性を選択することによって前記第２テーマを定義する 工程とを 更に備えることを特徴とする請求項１３に記載のグラフィカルインタフェース 方法。 １５．前記オブジェクトパーツの少なくとも１つとして、ズームボックス、ク ローズボックス、スライダー、チェックボックス、ビーベル、セパレーター、グ ルーピングボックス、ディスクロジャートライアングル、ボタン、スクロールバ ーを提供する工程を 更に備えることを特徴とする請求項１４に記載のグラフィカルインタフェース 方法。 １６．前記第１テーマに関連した前記表示形態を用いた前記インタフェースオ ブジェクトの１つを表示する間に、該インタフェースオブジェクトの１つのオブ ジェクトパートが動作されている場合、第１の動作を示し、その結果として生じ る機能を生成する工程と、 前記第２テーマに関連した前記表示形態を用いた前記インタフェースオブジェ クトの１つを表示する間に、該インタフェースオブジェクトの１つのオブジェク トパートが動作されている場合、第２の動作を示し、その結果として生じる機能 を生成する工程と 更に備えることを特徴とする請求項１４に記載のグラフィカルインタフェース 方法。 １７．前記第１の動作を示し、その結果として生じる機能を生成する工程は、 クローズボックスに影を付け、ウインドウオブジェクトを閉じる工程 を備えることを特徴とする請求項１６に記載のグラフィカルインタフェース方 法。 １８．前記第２の動作を示し、その結果として生じる機能を生成する工程は、 前記クローズボックスから生じる線を描画し、前記ウインドウオブジェクトを閉 じる工程 を備えることを特徴とする請求項１７に記載のグラフィカルインタフェース方 法。 １９．前記選択されたテーマを変更する工程は、テーマを選択する入力のため のコントロールパネルを表示する工程 を備えることを特徴とする請求項１３に記載のグラフィカルインタフェース方 法。 ２０．前記第２テーマに関連した表示形態を用いた前記インタフェースオブジ ェクトを表示する前に、遷移の結果を生成する工程 更に備えることを特徴とする請求項１３に記載のグラフィカルインタフェース 方法。 ２１．前記選択されたテーマを変更する工程は、前記第１テーマに対応する描 画手 ２１．前記選択されたテーマを変更する工程は、前記第１テーマに対応する描 画手順の第１のセットから前記第２テーマに対応する描画手順の第２のセットへ のポインタを切り替える工程を 更に備えることを特徴とする請求項１３に記載のグラフィカルインタフェース 方法。 ２２．前記選択されたテーマを変更する工程は、前記第２テーマに対応するデ ータ構造のセットを変数的な描画手順へ供給する工程を 更に備えることを特徴とする請求項１３に記載のグラフィカルインタフェース 方法。 ２３．ユーザーインタフェースの形態の制御方法であって、 第２のテーマのセットが呼ばれるまで、第１テーマのセットでインタフェース オブジェクトを表示する工程と、 その後、第２テーマのセットの前記インタフェースオブジェクトを表示する工 程と を備えることを特徴とする制御方法。