JP2008542919A - 表示におけるエレメントｚ−順番の精密なグレイン制御 - Google Patents

Abstract

【課題】表示におけるエレメントｚ−順番の精密なグレイン制御。
【解決手段】記載されたものは、表示におけるエレメントｚ−順番の精密なグレイン制御のための様々な方法及び装置である。ユーザ・インターフェース・エレメントを含む構造が規定され、そして順番は、そのようなユーザ・インターフェース・エレメントを描画するために規定される。ある複数のエレメントが規定された順番から外れて描画される必要があり、それゆえ、高いユーザ・インターフェース・エレメントが規定され、１又はそれより多くのユーザ・インターフェース・エレメントが通常の規定された順番から外れて描画されるように規定されることを可能にする。ユーザ・インターフェース・エレメントは、ディスプレイ上に表示されようとしている何かであり、そしてしかも動作を規定するためのプログラム・コードも含むことができる。
【選択図】図８

Description

関連文献

本出願は、米国特許仮出願番号第６０／６８６，３４９号、２００５年５月３１日出願、に優先権を主張し、そしてその全体はこの引用によって本明細書中にここに取り込まれている。

本発明は、一般にユーザ・インターフェースの変数処理に係る。より詳しくは、本発明は、ユーザ・インターフェース・エレメントを描画すること（rendering）を制御することに関する。

階層分類されたデータ言語及びマークアップ言語、ＸＭＬベースの言語を含む、を含むデータ言語において、ディスプレイ上に表示されるユーザ・インターフェース（ＵＩ：user interface）エレメントは、レイアウトのために順番を与えられる。（注：ＵＩエレメントは、スクリーン上に表示されることができるいずれかのものである。例えば、コード・エレメントは、ＸＭＬベースの言語中の１行のコード又は１つのタグであり得る。ＵＩエレメントは、１又はそれより多くのコード・エレメントによって特徴付けられることができる。さらに、コード・エレメントは、表示を記述しないことがある、すなわち、それは動作（behavior）を記述することができる。）
レイアウト順は、一般的に、ＵＩエレメントに関係するコード・エレメントが言語中にどのように宣言されるかによって定義される。ディスプレイ上にこれらのＵＩエレメントを映し出す（すなわち、描画する）ときに、映し出す順序は、レイアウト順にしたがう。

ディスプレイ上で、水平と垂直、長さと幅、等は、一般的に“ｘ−ｙ”座標で参照され、ｘ−ｙ平面におけるそれらの表示を特定する。表示中にてＵＩエレメントを表示するときに、それらの“ｚ−順番”は、それらが互いに関連して置かれる順番を呼ぶ。全てのＵＩエレメントが一般的にｘ−ｙ平面において見られる一方で、表示のｚ−順番は、関心事であり、その理由は、他のものの一番上に描画されるＵＩエレメントが（それらが透明性を持たない限り）その下に描画されるＵＩエレメントを覆うためである。

一例としてＸＭＬを使用して、ＸＭＬ中で指定されるユーザ・インターフェース（ＵＩ）は、ＵＩエレメントがコードにおいて宣言されている順番と同じ暗黙の描画順をＵＩエレメントに対して有する。複雑なＵＩは、見られるＵＩエレメントが（ＸＭＬ系列において後で宣言される）別のＵＩエレメントの上に描かれることを可能にする能力を必要とする。それゆえ、描画のｚ−順番を変更することを可能にする必要性がある。

現在のＵＩデータ言語方式は、この問題に対処していない、又はこの問題に対する不十分な解しか提供していない。具体的に、スカラ・ベクトル・グラフィックス（ＳＶＧ：Scalar Vector Graphics）第２版は、ｚ−順番制御に対処することを既に提案している。この制御を与える機構は、まだ確立されていない、すなわち規定されていない。ある示唆は、インデックを使用できることを示している。ｚ−制御のためのインデックスの使用は、ＵＩにおいて望ましくないクリッピングの影響を受ける。

別の１つの解は、表示されるべきＵＩエレメントを含んでいるページの複数の版を作り出すことを含んでおり、各ページは関係するコード・エレメントのｚ−順番を変化させる。しかしながら、この解は、追加のページの開発を必要とすることにより、複数のページを記憶することにより、そして複数のページ全体にわたるコードへの変更を保存することによる追加のリソースを伴い、そしてｚ−順番の常に変化する制御を扱う力ずくの、すなわち非効率的な、方法である。

発明のサマリー

本発明に整合するシステム及び方法は、ユーザ・インターフェース・エレメントを描画すること及び表示を制御するシステム、方法及び装置を作り出すことによって現在のシステムの欠点を克服する。

本発明の１つの実施形態では、表示の中に描画される第１のエレメントのｚ−順番を制御するための方法は、表示の中のレイアウトの該順番を表しているエレメントの順番に並べられたリストを受け取ること、該順番に並べられたリスト中の該第１のエレメントをライズコンテナ・エレメントに指定すること、ここにおいて、該第１のエレメントは該順番に並べられたリスト中の複数のエレメントの１つであり、該第１のエレメントを除き該順番に並べられたリストのエレメントの該表示を映し出すこと、及び該表示に該第１のエレメントを含んでいる該ライズコンテナを映し出すことを具備する。

本発明の別の１つの実施形態では、複数のユーザ・インターフェース・エレメントを描画するための方法は、高いユーザ・インターフェース・エレメントを規定し、該複数のユーザ・インターフェース・エレメントをディスプレイ上に描画し、そして該高いユーザ・インターフェース・エレメントを該ディスプレイ上に描画する、ここにおい、該高いユーザ・インターフェース・エレメントは、該複数のユーザ・インターフェース・エレメントを該描画することの後に描画される。この方法では、該高いユーザ・インターフェース・エレメントは、該複数のユーザ・インターフェース・エレメントのうちの１つであり、そして該複数のユーザ・インターフェース・エレメントを該ディスプレイ上に描画するステップは、該高いユーザ・インターフェース・エレメントを描画しない。該複数のユーザ・インターフェース・エレメントを含む構造は、ツリー構造であり得る。それに加えて、該高いユーザ・インターフェース・エレメントは、該ディスプレイ上に描画されるときに切り詰められないことがある。しかも、該高いユーザ・インターフェース・エレメントは、表示されたユーザ・インターフェース・エレメント上にフォーカスすることによって規定されることができる。

さらに別の１つの実施形態では、表示の中に描画される第１のエレメントのｚ−順番を制御するためのデバイスは、プログラム・コードを記憶するためのメモリ、ここにおいて、該プログラム・コードは、該表示の中のレイアウトの該順番を表しているエレメントの順番に並べられたリストに対する命令を含む、及び
該順番に並べられたリスト中の該第１のエレメントをライズコンテナ・エレメントに指定するために構成されたプロセッサ、を具備し、ここにおいて、該第１のエレメントは該順番に並べられたリスト中の複数のエレメントのうちの１つであり、該第１のエレメントを除き該順番に並べられたリストのエレメントを用いる該表示を映し出し、そして該表示のために該第１のエレメントを含んでいる該ライズコンテナを映し出す。

さらに別の１つの実施形態では、ディスプレイに複数のユーザ・インターフェース・エレメントを描画するためのデバイスは、該複数のユーザ・インターフェース・エレメントを含んでいる構造を規定するためのプログラム・コードを含むメモリ、及び高いユーザ・インターフェース・エレメントを規定するために、該複数のユーザ・インターフェース・エレメントを該ディスプレイ上に描画するために、そして該高いユーザ・インターフェース・エレメントをディスプレイ上に描画するために構成されたプロセッサを具備し、ここにおいて、該高いユーザ・インターフェース・エレメントは、該複数のユーザ・インターフェース・エレメントを描画した後で描画される。

本発明のその他の目的、利点及び特徴は、図面の簡単な説明、本発明の詳細な説明及び特許請求の範囲の記載に鑑みて本明細書を概観した後で明らかになるであろう。

［詳細な説明］
同じ参照符号は、全体を通して同じ要素を表す図面を参照する。

本発明は、クリッピングに関する効率をそしてそれゆえ描画する速度を維持しつつ、ｚ−順番の精密なグレイン（grain）制御を可能にすることによって本分野における問題に対処する。技術は、真の３Ｄ表示（２次元表面上の単なる３Ｄ表示ではない）を開発するために十分な程度に高性能になってきているはずであり、本発明は、そのようなシステムにも同様に適用できるはずである。

さらなる利点は、高いユーザ・インターフェース・エレメントを含み、スクリーンの大きさにクリップされることよりはむしろ指定された制約にクリップされることがある：あるエレメントは、高くされることができるが、まだ他のエレメントの明らかに下方であり、それはｘｍｌベースの解析シーケンスにおいてその前又は後に宣言されることができ；ＵＩの複数のレベル及び／又は入れ子になったレベルは、複数の及び／又は入れ子にされたライズコンテナのユーザにより実現されることができ、そしてそれらのｚ−順番が絶えず変えられることができる。

参照は、添付した図面に図示されるように本発明の現在の具体例の実施形態及び好ましい実施形態に対して詳細にここに行われ、図面では、同じ参照符号は、複数の図面を通して同じ部分又は対応する部分を示す。本発明の本質、目的、及び利点は、図面に関連して以下に述べる詳細な説明を考慮した後で、当業者にとってさらに明確になるであろう。

用語の使用に関して、本明細書では、用語“無線デバイス”、“無線電話機”、及び“移動デバイス”は、互換的に使用される。本明細書中に使用されるように用語“アプリケーション”は、実行可能なそして実行できないソフトウェア・ファイル、生データ、データの集合、パッチ、コンテント、ユーザ・インターフェース及びユーザ・インターフェース・コンポーネント、及び他のコード・セグメントを包含するように意図される。さらに、類似の参照符号は、複数の図面を通して類似の要素を呼び、そして冠詞“ａ”と“ｔｈｅ”は、明細書中に指定されない限り、複数の表示を含む。

ＴｒｉｇＭＬは、ユーザ・インターフェースを開発する際に有用なデータ言語である。ＴｒｉｇＭＬは、ＱＵＡＬＣＯＭ（クァルコム）社により所有される製品である。ＸＭＬの下で定義されるデータ言語のように、ＴｒｉｇＭＬコードは、タグの使用を含む。複数の実施形態が無線デバイス上のユーザ・インターフェースに関するＴｒｉｇＭＬの関係で説明されるが、それが説明の目的だけのためであり、そして本発明についての限定ではないことが理解される。本明細書中に記載される装置及び方法は、同様に、非ユーザ・インターフェース環境においても、そして上記のように、異なるデータ言語を使用する環境を使用するものにおいても利用可能である。

図１は、その環境においてデバイスが本発明の１実施形態で動作することができる通信環境１００の機能図である。この例では、通信環境１００は、無線ネットワーク１２２を含む。無線ネットワーク１２２は、無線サービス・プロバイダによって操業されている通信ネットワークであり得て、移動デバイスへのデータ接続性又は電気通信接続性を提供する。さらに、無線ネットワーク１２２は、有線ネットワーク、インターネット、ワイド・エリア・ネットワーク、公衆交換電話ネットワーク（ＰＳＴＮ：Public Switch Telephone Network）、及び他の公開ネットワーク及び／又は非公開ネットワークを同様に含むことができ、その結果、デバイスは、これらのネットワークからネットワークへと接続されている他のデバイスを使用して直接的に又は間接的に通信することができる。

１つの例では、無線ネットワーク１２２は、セルラ電話ネットワークを含むことができる。例えば、セルラ電話機１１２、ラップトップ・コンピュータ１１６、ＰＤＡ１１８、及び移動メッセージ通信デバイス１２０の様な、複数の移動デバイスが、無線ネットワーク１２２と通信している。これらのデバイスは、無線ネットワーク１２２を経由して通信することができる多くの型のデバイスの例示として示されているだけである。

図１に図示されているものは、アプリケーション・サーバ１２４及びユーザ・インターフェース・サーバ１２６である。ユーザ・インターフェース・サーバ１２６は、ユーザ・インターフェース・コンポーネント１３０（下記にさらに詳細に説明される）を取り扱う計算デバイスである。これらのユーザ・インターフェース・コンポーネント１３０は、無線ネットワーク１２２に接続された他のデバイスにダウンロードされることができる。ユーザ・インターフェース・コンポーネントは、ユーザ・インターフェース（例えば、機能コール、メニュー、コンテント・コールにためのコード、スキン、等）を与える（render）ためのコード及び／又はデータを含む。コンテント・サーバを含む複数の他のサーバが、ネットワークに接続するために使用されることができ、情報を配信することができることに、注意する。利用可能にされ得る情報の型は、制限がなく、そして非常に多くの異なる例が、当業者に明らかであろう。ユーザ・インターフェース・サーバ１２６は、サーバ・ソフトウェアを含み、それは無線ネットワーク１２２を経由して要請しているデバイスにユーザ・インターフェース・コンポーネント１３０を提供するように構成される。

アプリケーション・サーバ１２４は、無線ネットワーク１２２に接続された計算デバイス又は計算システムであり、それはソフトウェア・アプリケーション１２８が移動デバイスによってダウンロードされることを可能にする。一般的に述べると、アプリケーション１２８は、無線ネットワーク１２２に接続されたデバイス、例えば、セルラ電話機１１２、上で実行するためにそれらのデバイスによってダウンロードされることができる。この特定の実施において、アプリケーション・ダウンロード・サーバ１２４によって取り扱われるアプリケーション１２８のうちの少なくとも１つは、少なくとも１つの移動デバイス上での実行のために構成されたコンテント・ベースのアプリケーションである。コンテント・ベースのアプリケーション（クライアント）は、移動デバイスによる表示のためにユーザ・インターフェースを介してコンテント・サーバ（図示されず）からコンテントを検索するように構成される。

図２は、本発明の１実施形態において、１つのサンプルの移動デバイス２０１の構成要素を一般的に説明する機能ブロック図である。移動デバイス２０１は、計算機能を有する任意のデバイスであることができ、例えば、セルラ電話機、個人ディジタル補助装置、手持ち“パームトップ”デバイス、ラップトップ・コンピュータ、携帯型音楽プレーヤ、全地球位置決定衛星（ＧＰＳ：global positioning satellite）デバイス、又はその他である。

移動デバイス２０１は、コンピュータ・プラットフォーム２５０を有し、それはソフトウェア・アプリケーションを受信しそして実行することができ、データを表示することができる。コンピュータ・プラットフォーム２５０は、プロセッサ２５２を含み、例えば、用途特定集積回路“ＡＳＩＣ（application specific integrated circuit）”、ディジタル信号プロセッサ（“ＤＳＰ（digital signal processor）”）、マイクロプロセッサ、マイクロコントローラ、論理回路、ステート・マシーン、又は他のデータ処理デバイスである。プロセッサ２５２は、アプリケーション・プログラミング・インターフェース（“ＡＰＩ（application programming interface）”）層２５４を実行し、それは移動デバイスのメモリ２５６中の任意の常駐プログラムをインターフェースする。メモリ２５６は、ランダム・アクセス・メモリ又は読み取り専用メモリ（ＲＡＭ又はＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、又はコンピュータ・プラットフォームに一般的ないずれかのメモリを含むことができる。コンピュータ・プラットフォーム２５０は、しかもローカル記憶装置２５８を含み、それはメモリ２５６中でアクティブに使用されないソフトウェア・アプリケーション、ファイル、又はデータ、例えば、ユーザ・インターフェース・サーバ１２６（図１）からダウンロードされたソフトウェア・アプリケーション又はユーザ・インターフェース・コンポーネント、を保持することができる。ローカル記憶装置２５８は、一般的に１又はそれより多くのフラッシュ・メモリ・セルを備えるが、本分野において公知のいずれかの２次記憶デバイス又は３次記憶デバイスであり得て、例えば、磁気媒体、ＥＰＲＯＭ、ＥＥＰＲＯＭ、光学的媒体、テープ、若しくはソフト・ディスク又はハード・ディスクであり得る。

コンピュータ・プラットフォーム２５０は、しかもディスプレイ２６０も含み、それはユーザ・インターフェース（図示されず）を使用してデータを表示するためにソフトウェア・アプリケーションによって使用されることができる。

図２に示される構成要素は、多くの型の移動デバイスで一般的であるが、他の構成要素が移動デバイス２０１に追加されることができ、そしてあるケースでは、図２に示されたある構成要素は、移動デバイス２０１から省略されることがある。

図３は、本発明の１実施形態において、１つのサンプルの計算デバイス３０１の核となる構成要素を一般的に説明する機能ブロック図である。計算デバイス３０１は、任意の固定計算デバイス、例えば、デスクトップ・コンピュータ又はサーバであり得る。

この例では、計算デバイス３０１は、プロセッサ・ユニット３０４、メモリ３０６、記憶媒体３１３、及びオーディオ・ユニット３３１を含む。プロセッサ・ユニット３０４は、好都合なことにマイクロプロセッサ又はディジタル信号プロセッサのような特殊用途プロセッサを含むが、代わりにいずれかの従来形式のプロセッサ、コントローラ、マイクロコントローラ、又はステート・マシーンであり得る。プロセッサ・ユニット３０４は、メモリ３０６に接続され、それはプロセッサ・ユニット３０４によって実行されるソフトウェア命令を保有しているＲＡＭメモリとして都合の良いことに実装される。代案の実施形態では、メモリ３０６は、ファームウェア又はフラッシュ・メモリにより構成されることができる。この実施形態では、メモリ３０６中に記憶されたソフトウェア命令は、オペレーティング・システム３１０及び１又はそれより多くの別のアプリケーション３１２、例えば、ユーザ・インターフェースを使用するアプリケーション（図示されず）、を含む。

移動デバイス３０１は、しかも通信モジュール３２１を含み、それは計算デバイス３０１と１又はそれより多くの別の計算デバイス、例えば、移動デバイスとの間の双方向通信を可能にする。通信モジュール３２１は、ＲＦ無線通信又は他の無線通信を可能にする構成要素、例えば、セルラ電話ネットワーク、ブルートース接続、無線ローカル・エリア・ネットワーク、又はおそらく無線ワイド・エリア・ネットワーク、を含むことができる。あるいは、通信モジュール３２１は、地上回線すなわち配線接続されたネットワーク通信、例えば、イサーネット（登録商標）接続、ＲＪ−１１接続、ユニバーサル・シリアル・バス接続、ＩＥＥＥ１３９４（ファイアワイア）接続、又はその他、を可能にする構成要素を含むことができる。これらは非網羅的なリストとして意図されており、そして多くの他の代案が可能である。オーディオ・ユニット３３１は、移動デバイス３０１の構成要素であり、アナログ・フォーマットとディジタル・フォーマットとの間で信号を変換するために構成される。オーディオ・ユニット３３１は、移動デバイス３０１によって使用され、スピーカ３３２を使用して音を出力しそしてマイクロフォン３３３からの入力信号を受け取る。

図３は、多くの従来型の計算デバイスにおいて一般的に見られるある種の構成要素だけを図示する。非常に多くの他の構成要素が、同様に特定の装置においてごく普通に見られ、そしてある種のケースでは、図３に示されたある構成要素が省略されることができる。しかしながら、図３に示された計算デバイス３０１は、今日一般的に見られる計算デバイスの典型である。

図４は、本発明の１実施形態における１つのデバイスのアプリケーション・アーキテクチャを図示する。本デバイスは、“コンピュータ・プラットフォーム”を含む。コンピュータ・プラットフォームは、ハードウェア、ソフトウェア、又は両方を含むデバイスの構成要素を呼ぶことができる。例えば、それはオペレーティング・システム、基盤となるハードウェア構成要素を含むことができ、そのハードウェア構成要素は、チップ、ユーザ・インターフェース・ハードウェア（例えば、ディスプレイ、入力デバイスと出力デバイス）、ライブラリ、サポーティングＡＰＩ、オペレーティング・システムへの追加の拡張、等を含む。

１つの実施形態では、無線デバイスのアプリケーション・アーキテクチャ４００は、Ｄｅｖｉｃｅ ＡＰＩ４０５、ＢＲＥＷ ＡＰＩ４１０、ＢＲＥＷ Ｅｘｔｅｎｓｉｏｎ４１５、Ｔｒｉｇｐｌａｙｅｒ４２０、Ａｃｔｏｒ４２５、及びＴｒｉｇ４３０を含む。Ｄｅｖｉｃｅ ＡＰＩ４０５は、そのデバイスに明確に関係付けられた機能に対処するためのソフトウェア・プラットフォームによって使用されるそれらのＡＰＩを含むことができ、例えば、特定のプロセッサ又はＡＳＩＣ機能、特定のデバイス・ハードウェア機能、等である。

ＢＲＥＷ ＡＰＩ４１０は、ＱＵＡＬＣＯＭ株式会社によって開発されたソフトウェア・プラットフォームである。ＢＲＥＷ ＡＰＩ４１０は、そのデバイスに対して特別に書き込まれることを必要とせずにＤｅｖｉｃｅ ＡＰＩ４０５及びその他の機能を呼び出すためのアプリケーションに対する能力を提供する。言い換えると、アプリケーションからハードウェアの特定の側面を取り出し、それによってそのデバイス上でアプリケーションを実行する各特定のデバイスに対して、合わせる必要なく又はわずかに合わせることを必要とするだけで、アプリケーションが複数のデバイスに対して書き込まれることを可能にする。

ＢＲＥＷ Ｅｘｔｅｎｓｉｏｎ４１５は、ＢＲＥＷプラットフォームに追加の能力、例えば、ＭＰ３プレーヤ、Ｊａｖａ（登録商標） Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ（ジャヴァ仮想マシーン）、等、を追加する能力を提供する。

Ｔｒｉｇｐｌａｙｅｒ４２０、Ｔｒｉｇ４３０及びＡｃｔｏｒ４２５は、ＱＵＡＬＣＯＭ株式会社によって開発されたｕｉＯｎｅ（登録商標）アーキテクチャのコンポーネントである。これらのコンポーネントは、一般的にデバイス４００のユーザ・インターフェースの側面を呼ぶ。１つの実施形態では、Ｔｒｉｇ４３０は、コンパイルされたＴｒｉｇＭＬ（登録商標）コード、及びデバイス４００上にユーザ・インターフェースを与えるためのアプリケーションによって使用される他のリソース（それはメタデータ、テキスト・ファイル、及び画像を含むことができる）である。複数のＴｒｉｇ４３０及びＴｒｉｇへの最新版、Ｔｒｉｇｌｅｔ（図示されず）と呼ばれる、は、ユーザ・インターフェースに対して使用されることができる。

ＴｒｉｇＭＬコード、ＱＵＡＬＣＯＭ株式会社によって所有される、は、ＸＭＬに基づくデータ言語であり、そしてＴｒｉｇ４３０を書き表すためのユーザ・インターフェース表示言語として使用されることができ、そして移動体に的を絞った機能性、双方向ユーザ・インターフェース・イベント・モデルの利点を含み、そしてその他の利点の中でピクセル位置決定の利点を含む。

Ａｃｔｏｒ４２５は、基盤となるＣコードを含み、Ｔｒｉｇを基盤となるＤｅｖｉｃｅ ＡＰＩ４０５及び／又はＢＲＥＷ ＡＰＩ４１０に結びつける。Ａｃｔｏｒ４２５は、しかも入力／出力のための実行可能なもの（executables）として機能することができる。そして複数のアクタが基盤となるＤｅｖｉｃｅ ＡＰＩ及びＢＲＥＷ ＡＰＩを結び付けるので、それらはコンピュータ・プラットフォーム機能へのアクセスを有する。

たとえ、Ｔｒｉｇｐｌａｙｅｒ４２０が図４では分離されているとしても、Ｔｒｉｇｐｌａｙｅｒ４２０は、ＢＲＥＷ Ｅｘｔｅｎｓｉｏｎ４１５として与えられることができる。Ｔｒｉｇｐｌａｙｅｒは、Ｔｒｉｇ及びＡｃｔｏｒを使用してユーザ・インターフェースを与えるために使用される。

図４の考察は、ＱＵＡＬＣＯＭ株式会社のｕｉＯｎｅアーキテクチャ（コンパイルされたＴｒｉｇＭＬ、Ｔｒｉｇｐｌｙｅｒ、ＢＲＥＷ ＡＰＩ、等を含む）に関してであるが、これは説明の目的のためであり、そして本発明が他のデータ言語、コンピュータ・プラットフォームとソフトウェア・プラットフォーム並びにデバイス・アーキテクチャを含むことが、理解されるであろう。

図５は、本発明の１実施形態におけるユーザ・インターフェースを更新するシステム及びＴｒｉｇｐｌａｙｅｒ４２０、Ａｃｔｏｒ４２５及びＴｒｉｇ４３０を図示するアーキテクチャを説明するブロック図である。デバイス５００は、Ｔｒｉｇｐｌａｙｅｒ４２０、Ａｃｔｏｒ４２５及びＴｒｉｇ４３０を含む。Ｔｒｉｇは、ＴｒｉｇＭＬコード５０５、テキスト・ストリング５１０、画像５１５、及び更新チャネル５２０（更新チャネルは、ＵＲＬを規定しそしてＴｒｉｇｌｅｔ５３０を引き出すタイミング方式を規定することができる）を含むことができる。Ｔｒｉｇは、無線を介して更新されることができ、それによってデバイスが製造者をとっくに離れてしまった後で、ユーザ・インターフェースが更新されることを可能にする。サーバ５２５は、新たなＴｒｉｇ及び又はＴｒｉｇの更新されたコンポーネント（例えば、Ｔｒｉｇｌｅｔ５３０）をダウンロードするために使用されることができ、それゆえデバイスのためのユーザ・インターフェースがカスタム化されることを可能にする。

ユーザ・インターフェース・エレメントの精密なグレインのｚ−順番制御のより詳細な態様に対処するために、１つの実施形態では、描画ツリーは、ＵＩエレメント・ツリーの親を先頭にした下り順により通常は処理される。ＵＩエレメント・ツリーは、ＵＩエレメントに関係付けられるコード・エレメントがＴｒｉｇリソース・ファイルにおいてどのようにして宣言されたかに基づいて作り出された。親は、自身を映し出し、そして次にその複数の子を順番に映し出すようにその子のそれぞれに要求する。Ｔｒｉｇリソース・ファイル。親は、しかも自分自身の範囲に自分の子のそれぞれを切り詰める。ライズ属性（raise attribute）の導入で、それによってＵＩエレメントは、通常の描画が終わる後まで自身を描画することを遅らせることができる−すなわち、全ての高くしないＵＩエレメントが描画されるはずであり、その後、全ての高くしたＵＩエレメントが描画されるはずである。例えば、ＵＩエレメントが制御フォーカスを有するときに、ＵＩエレメントは高くされるはずである。（１つの実施形態では、“フォーカス”は、注意がそこに与えられる表示の一部を呼び、例えば、強調すること又は拡大することの選択であり、カーソルは、もし選択されるならば、どのオプションが選択されるかをユーザに示すためのものである。）高くしたＵＩエレメントは、その親のフレームによっては切り詰められない、その理由は、それが描画の通常のサイクルの範囲外であり、そのため自身の通常の限界の外側に描画できるためである。

この描画属性を使用するプログラム・コードの一例は、ＴｒｉｇＭＬを使用して：
<trigml>
<group w=”20” h=”20”>
<group bgcolor=”red” w=3-“h=”30”raise=”false”>
<att when=”focus” name=”raise” value=”true”/>
</group>
<group bgcolor=”blue”/>
</group>
</trigml>
図６に示されるように、このＴｒｉｇＭＬプログラム・コードの部分が描画されるとき、赤のグループは、ディスプレイ２６０上に２０×２０の赤の四角６０５として表示される（それは自身の親のグループにより切り詰められる、クリッピングは図示されない）。青のグループは、次にその上に描画され、そのためユーザによって見られるように最終的に描画されるページは、青の２０×２０の四角６１０だけから構成される。

図７に示されるように、フォーカスが次に赤のグループに移る場合、<att>コード・エレメントは、その赤のグループのライズ特性を変更し、値を真に設定する。ページが描画されるときに、赤のグループは、（それが高くされているために）スキップされ、そして次に青のグループが２０×２０の青の四角７０５として描かれる。最後に高くされた赤のグループが描画され（それが高くされているために、切り詰められない）そしてユーザによって見られるように最終的に描画されるページは、３０×３０の赤の四角７１０から構成される。

１つの実施形態は、全体の先送り描画リストの暗黙の存在をあてにしており、そして描画することを先送りする任意のＵＩエレメントが、この全体リストに追加される。これは、従来技術の解に対する改善である。

別の実施形態は、ＵＩエレメントを全体レベルまで高くしない、その結果、それらは全ての高くしないＵＩエレメントの後で映し出される。<raisecontainer（ライズコンテナ）>エレメントの追加は、高くしたＵＩエレメントを“取り込む（catch）”。これは、例えば、高められるべきＵＩエレメントが恒久的な最高レベルのアクティビティを認められることを可能にすることができる、しかし他の（高くされない）ＵＩエレメントはそれにしたがって描画され続ける。ＴｒｉｇＭＬプログラム・コードを使用するこの一例は、下記によって説明される：
<trigml>
<group w=”20” h=”20” bgcolor=”red” raise=”false”>
<att when=”focus” name=”raise” value=”highplace”/>
</group>
<group w=”20” h=”20” bgcolor=”blue”>
<raisecounter id=”highplace”/>
<group bgcolor=”green” w=”10” h=”10”/>
</trigml>
ツリーは、ＵＩエレメントがその中で宣言された順番を使用して上に説明されたように作り出される。ここでの通常の描画する順番は、赤、青、緑であり、そしてユーザは、２０×２０の青の四角の上にかぶせられた１０×１０の緑の四角を見る。通常の描画において、ライズコンテナは空であり、そのためそれが評価されるときには何も描画されるものがない。

しかしながら、赤のグループが高められると、ｚ−順番は変更され、その結果、上に示されたように、ライズコンテナを使用することによって赤のグループが映し出される。描画は、したがって、青、赤、緑であり、結果として、２０×２０の赤の四角の上にかぶせられた１０×１０の緑の四角をもたらす。これは、ＵＩエレメントを高めることを実現することができ、しかもかぶせた緑の四角を維持するように管理するという利点を有する。ＵＩエレメントを高くするレベルに対するこの特別な制御は、かぶせることを保護するための方法を提供する。典型的な使用ケースは、ポップ・アップ・メニューであり、それは、それ自身が既に高められているいずれかの現在フォーカスされているＵＩエレメントを含む他の全てのものの上に映し出されるはずである。

ライズコンテナは、入れ子にすることができ、そしてライズコンテナそれ自身が、高められることができ、ＵＩのレイヤ又は下位レイヤに対してそれが以前に可能であったものよりもはるかに多くの制御を与える。要するに、ライズコンテナは、１つのレイヤであるが、そのレイヤは、そのｚ−順番を変更できそして必ずしもスクリーン全面である必要はない。そのように、ｚ−順番に関しての精密なグレイン制御を、すなわち、ＵＩエレメントを複数のレイヤの最上部まで押し上げること又は最下部まで押し下げることだけに対してレイヤ内部でのｚ−順番を制御することを、実現する。

それに加えて、高くしたＵＩエレメントは、ライズコンテナによって既に映し出されてきており、そしてそのためライズコンテナのフレームによって切り詰められ、高くしたＵＩエレメントを変更することは、スクリーン全体のリフレッシュをもはやトリガする必要がないことを意味する。これは、さらに複雑なＵＩが処理能力の増加を必要とせずに実行されることを可能にする。

図８は、本発明の１つの実施形態において高いエレメントを描画するプロセス図示するフローチャートである。最初に、１つの構造がユーザ・インターフェース・エレメントを含むように規定される（ステップ８０５）。この構造は、上記で定義されたような又は別のファイルのツリー構造、若しくはユーザ・インターフェース・エレメントが描画されることを追跡することが可能なデータ構造であり得る。次に、高いＵＩエレメントが規定される（ステップ８１０）。高いＵＩエレメントは、他のエレメントの後に描画されるように望まれるエレメントである。高いエレメントは、一般的にステップ８０５に関連して構造によって規定される順番で描画されるように規定されることができる、しかしながら、この高いエレメントを通常の順番でなく描画することが望まれる。

ユーザ・インターフェース・エレメントは、次にディスプレイ上に描画される（ステップ８１５）。この描画することは、ステップ８０５において規定された構造を通して段階的に行われる。描画することが単に表示のためだけではなく、動作を規定するプログラム・コードであることに、注意する。このステップにおいて高いユーザ・インターフェース・エレメントを描画しないことが好ましく、その理由は、それが再び描画されるためであり（下記のステップ８２０において規定される）、そのようにしてその高いユーザ・インターフェース・エレメントが２回描画されることを防止する。

そして最後に、高いユーザ・インターフェース・エレメントが表示される（ステップ８２０）。説明がたった１つの高いユーザ・インターフェース・エレメントを規定するとはいえ、複数のユーザ・インターフェース・エレメントが“高くされる”ように規定されることができ、そしてそれゆえ複数のユーザ・インターフェース・エレメントが通常のユーザ・インターフェース・エレメント構造の順番から外れて描画されることができる。

上の方法及びソフトウェア設計の説明は、同様に装置に実装されることができ、ＲＡＭ中に又は他のメモリ記憶デバイス中に命令として記憶されることができる。

上の方法及びソフトウェア設計の説明は、同様に装置に実装されることができ、ＲＡＭ中に又は他のメモリ記憶デバイス中に命令として記憶されることができる。本明細書中に示されたプロセスが特定の順番で連続的に例示されそして説明されてきているとはいえ、他の実施形態では、プロセスのステップは、別の順番で、複数回、及び／又は並行に実行されることができる。さらに、ある複数の実施形態では、複数のプロセスにおいて記載された１又はそれより多くのステップは、別々のステップとして実行されることができ、より少ない数のステップへと統合されることができる、又はおそらく完全に省略されることができる。

これまでの開示が本発明の例示的な実施形態を示している一方で、様々な変更及び変形が添えられた特許請求の範囲によって規定されるように本発明の精神及び範囲から逸脱することなく記載された実施形態に行われることができることに、注意すべきである。さらに本発明の要素が、単数形で記載される又は特許請求されることがあるが、複数形は、単数形への限定が明確に述べられない限り予期される。

図１は、その環境においてデバイスが本発明の１実施形態で動作することができる通信環境の機能図である。 図２は、本発明の１実施形態における１つのサンプルの移動デバイスの構成要素を一般的に説明する機能ブロック図である。 図３は、本発明の１実施形態における１つのサンプルの計算デバイスの構成要素を一般的に説明する機能ブロック図である。 図４は、本発明の１実施形態におけるコンピュータ・プラットフォームの１つのアプリケーション・アーキテクチャを説明するブロック図である。 図５は、本発明の１実施形態におけるユーザ・インターフェース・コンポーネントを更新するシステム及びトリグプレーヤ、アクタ及びトリグを図示するアーキテクチャを説明するブロック図である。 図６は、本発明の１つの実施形態においてユーザ・インターフェース・エレメントを高くすることなくユーザ・インターフェース・エレメントを描画することを説明するブロック図である。 図７は、本発明の１つの実施形態において高いユーザ・インターフェース・エレメントを使用してユーザ・インターフェース・エレメントを描画することを説明するブロック図である。 図８は、本発明の１つの実施形態において高いエレメントを描画するプロセス図示するフローチャートである。

符号の説明

１００…通信環境，２５０…コンピュータ・プラットフォーム，４００…アプリケーション・アーキテクチャ，５０５…ＴｒｉｇＭＬコード，５１０…テキスト・ストリング，５１５…画像，５２０…更新チャネル，５３０…ＵＲＬ及びＴｒｉｇｌｅｔ。

Claims (12)

1. 表示の中に描画される高くされるエレメントのｚ−順番を制御するための方法であって、
   該表示の中のレイアウトの該順番を表しているエレメントの順番に並べられた構造を規定すること；
   該順番に並べられた構造中の該高くされるエレメントをライズコンテナ・エレメントに指定すること、該高くされるエレメントは順番に並べられたリスト中にあり、該ライズコンテナ・エレメントは該順番に並べられたリスト中にある；及び
   複数のエレメントの該順番に並べられた構造の該表示を描画すること、を具備し、該高くされるエレメントは該ライズコンテナ・エレメントが描画されるときに該表示中に描画され、さらに該高くされるエレメントは該ライズコンテナ・エレメントによって制御される描画属性の集合に基づいて描画され、該描画属性の集合はｚ−順番属性を含む
   ことを特徴とする方法。
2. 該ライズコンテナ・エレメントが描画されるときにだけ該高くされるエレメントを描画することをさらに具備する、請求項１の方法。
3. 該エレメントを含んでいる該構造をツリー構造として規定することをさらに具備する、請求項１の方法。
4. 該描画属性の集合をクリッピング属性を含むように規定することをさらに具備する、請求項１の方法。
5. 表示されたユーザ・インターフェース・エレメント上にフォーカスすることによって該高くされるエレメントを規定することをさらに具備する、請求項１の方法。
6. 表示の中に描画される高くされるエレメントのｚ−順番を制御するためのデバイスであって、
   プログラム・コードを記憶するためのメモリ（２５６，３０６）、ここにおいて、該プログラム・コードは、該表示の中のレイアウトの該順番を表しているエレメントの順番に並べられた構造に関する命令を含む；及び
   該順番に並べられた構造中の該高くされるエレメントをライズコンテナ・エレメントに指定するために構成されたプロセッサ（２５２，３０４）、を具備し、ここにおいて、該高くされるエレメントは該順番に並べられた構造中にあり、ここにおいて、該ライズコンテナ・エレメントは複数のエレメントの該順番に並べられた構造を用いて該表示を描画するために該順番に並べられた構造中にあり、ここにおいて、該高くされるエレメントは該ライズコンテナ・エレメントが描画されるときに該表示中に描画され、ここにおいて、該高くされるエレメントは該ライズコンテナ・エレメントによって制御される描画属性の集合に基づいて描画され、ここにおいて、該描画属性の集合はｚ−順番属性を含む
   ことを特徴とするデバイス。
7. 該高くされるエレメントは、該ライズコンテナ・エレメントが描画されるときにだけ描画される、請求項６のデバイス。
8. 該エレメントを含んでいる該構造はツリー構造である、請求項６のデバイス。
9. 該描画属性の集合はクリッピング属性を含む、請求項６のデバイス。
10. 該高くされるエレメントは、表示されたユーザ・インターフェース・エレメント上にフォーカスすることによって規定される、請求項６のデバイス。
11. 表示の中に描画される高くされるエレメントのｚ−順番を制御するためのデバイスであって、
    該表示の中のレイアウトの該順番を表しているエレメントの順番に並べられた構造を規定するための手段；
    該順番に並べられた構造中の該高くされるエレメントをライズコンテナ・エレメントに指定するための手段、ここにおいて、該高くされるエレメントは順番に並べられた構造中にあり、ここにおいて、該ライズコンテナ・エレメントは該順番に並べられた構造中にある；及び
    複数のエレメントの該順番に並べられた構造の該表示を描画するための手段、を具備し、ここにおいて、該高くされるエレメントは該ライズコンテナ・エレメントが描画されるときに該表示中に描画され、さらに該高くされるエレメントは該ライズコンテナ・エレメントによって制御される描画属性の集合に基づいて描画され、ここにおいて、該描画属性の集合はｚ−順番属性を含む
    ことを特徴とするデバイス。
12. 実行するときに下記の方法を行い表示の中に描画される高くされるエレメントのｚ−順番を制御するためのコンピュータに実装される命令を含んでいるコンピュータ読み取り可能な媒体であって、
    該表示の中のレイアウトの該順番を表しているエレメントの順番に並べられた構造を規定するための少なくとも１つの命令；
    該順番に並べられた構造中の該高くされるエレメントをライズコンテナ・エレメントに指定するための少なくとも１つの命令、該高くされるエレメントは順番に並べられたリスト中にあり、該ライズコンテナ・エレメントは該順番に並べられたリスト中にある；及び
    複数のエレメントの該順番に並べられた構造の該表示を描画するための少なくとも１つの命令、を具備し、該高くされるエレメントは該ライズコンテナ・エレメントが描画されるときに該表示中に描画され、さらに該高くされるエレメントは該ライズコンテナ・エレメントによって制御される描画属性の集合に基づいて描画され、該描画属性の集合はｚ−順番属性を含む
    ことを特徴とするコンピュータ読み取り可能な媒体。

Images