『はじめに』の章で既に説明されているように、Kトレーダはレジストリへのアクセス権を付与します。"レジストリって何?"と思うかも知れません。このドキュメントが単に kded/libkdedのためのものなら、こう答えるしかなかったでしょう。"詳しくはlibkioのドキュメントをご覧ください" :-} レジストリについてはただ一つ、Kトレーダは完全な、肥大したレジストリをロードします。libkioのおかげで、ロード済みのレジストリは"本当の"レジストリである以下の標準的なディレクトリ内の .desktopファイルとともに sync に常駐しています。
applnk
mimelnk
services
servicetypes
Kトレーダ とそのAPI についてですが、Kdedインスタンスと同様にインスタンスがたった一つだけ存在します。違いはそのインスタンスを割り当てる心配をしなくても良く、単にKdedインスタンスのktrader()メソッドをコールすることで Kトレーダ の効果を得られます。そして返って来たリファレンスの削除について考える必要すらないのです。簡単に使えて幸せになれるのです:-)。(kded は使いやすいように設計されています。)
Kトレーダ API は二つのメソッドしか含んでいないきわめてシンプルなものです;-)。しかしこれらのメソッドについて説明する前に、Kトレーダ 戻り値データについて知る必要があります。簡単にいえば、Kサービスオブジェクトのリストを常に受け取ることになるでしょう。詳しくいうと、返されるリストはQValueListで、エントリはKサービスオブジェクトへのKSharedPtrのエントリです( FIXME: KSharedPtr は Qt.... AFAIK の一部になるので、間もなく QSharedPtr に名前が変わります)。これらの二つのクラスについては Qt に関係しているドキュメントをご覧ください。この二つのテンプレートクラスを使う最大のメリットは、あらゆることが簡単になり、メモリ消費量が最小限に押えられるということです。Kサービスオブジェクトを保持するためのKTrader::ServicePtr変数を使う限り、そしてプログラム中のリストを無視するKTrader::OfferListを使う限り、ポインタやそのポインタを開放したりリストを削除する心配する必要はありません。ですから Kトレーダを使用する場合は、常にこれら二つのタイプを使うことを念頭においてください。
二つのメソッドについて
KTrader::listServices()は KDE 全体で利用可能なサービスのリストを返します(これ以上の説明は不要だと思うのですが・・・)。
KTrader::query()はキーとなるメソッドです。これは得ようとしている情報を与えつつレジストリデータベース内の検索を実行します。最初の引数は、履行すべきサービスを返すサービスタイプの名称です。"サービスタイプ"という言葉がよく分からない場合は、"マインタイプ"に置き換えてみてください。全てではありませんが、大抵の場合はそれで分かるはずです。
二番目の引数はサービスが履行しなければならない追加制約です。
三番目の引数はリターンサービスをソート後の設定表現です。表現の値は数字でな ければなりません。
これら二つの表現の文法は標準的な CORBAトレーダ 言語と同じです(これは構文解析コードが MICO の COS トレーダからきているからです)。この言語はあまり難しいものではなく、私としてはその説明のためにこのドキュメントを大きくしたくありません。詳しくは CORBA の文献を参照してください。知っておかなければならないことはただ一つ: Kサービスオブジェクトのプロパティとの比較は常に行われているということです。このプロパティは標準的なエントリ(ネーム, サービスタイプ, RepoId...)に加え、サービスタイプの宣言で明記され Kサービスに読込まれるエントリのことです。
説明はそれくらいにして、実際的なサンプルコードを見てみることにしましょう。
1 ... 2 //get a reference to the KTrader 3 KTrader *trader = KdedInstance::self()->ktrader(); 4 5 ... 6 //will return a list of all services which implement the servicetype 7 //named "text/plain" 8 KTrader::OfferList offers = trader->query( "text/plain" ); 9 10 11 ... 12 //will return a list of all services which implement the servicetype 13 //named "image/gif" and which have the AllowAsDefault property set true 14 KTrader::OfferList offers = trader->query( "image/gif", "AllowAsDefault == TRUE" ); 15 16 ... 17 //will return KSpread ;-) 18 KTrader::OfferList offers = trader->query( "KOfficeDocument", "(Exec == 'kspread') and (Path != '/opt/gnome/bin')" ); 19 20 ... 21 //will return a list of all services which implement the servicetype 22 //named "BlahFoo" and which will be sorted (from lowest to highest) by 23 //the value of the property "Price" , declared in the servicetype 24 //declaration of BlahFoo. 25 KTrader::OfferList offers = trader->query( "BlahFoo", QString::null, "min Price" ); |
Kトレーダは、サービスに対してlibkioをとうため、常に特定のサービスタイプにあわせて、ユーザーの好みによってソートされたサービスを返すということを覚えておいてください。これらの設定は"profilerc"ファイルに明記することができます。
この節はlibkioに精通している必要があります。 これはアプリケーションに Kランを使おうとしている人全員に対していえることです。
Kランは、マインタイプ <->アプリケーションバインドを決定するために、完全にロードされたレジストリを要求します。完全にロードされたレジストリとは、KServiceTypeFactoryと Kサービスファクトリを要するということです。この二つは両方とも適正なKServiceTypeKサービスオブジェクトをロードします。Kサービスタイプ情報は多くのメモリを必要としませんが、Kサービスオブジェクトは大量のメモリを要します。これが kdedで既に行われているなら、この情報をロードするのはばかげているとは思わないでしょ? 全くその通りですよね;-)。
私達が必要としていることは、Kサービスプロファイルを直接使用する代わりに、Kサービスデータに対して Kランに Kトレーダについて問わせることです。幸運にも Kランはこれを行える程柔軟なので、krun.hに定義され、Kランに用いられる Kサービスプロバイダを再実行するだけです。Kトレーダがこれを行ってくれます :-)。だからktrader.hの最後を見てみましょう。
つまり次の行は、アプリケーション内で Kランにkdedを呼び出させるのです:
1 ... 2 //place this somewhere BEFORE the first usage of KRun, preferable somewhere 3 //in main() 4 KTraderServiceProvider serviceProvider; 5 ... |