KDE (K Desktop Environment) とは、すべてのLinux配布版で利用可能な、使いやすいオープン・ソースのLinux/UNIX用グラフィック環境のことです。KDEは、グラフィック・アプリケーション向けの、Qtツールキットをベースにした、強力なC++開発プラットフォームです。Qtは、ウィジェット、数多くのユーティリティ・クラス、それにコア・オブジェクト・モデルを提供します。KDEでは、統合化されたネットワークの透明性、プロセス間通信、完全なHTMLブラウザー、それに、本稿で紹介するKParts、すなわちグラフィック・コンポーネントのアーキテクチャーが提供されます。今日のソフトウェア設計においては、コンポーネントという概念が基本的な考え方となっています。KPartsを利用すれば、グラフィカル・コンポーネントをアプリケーションのウィンドウに組み込むことで、同じ機能を必要とするアプリケーション同士が、その機能のためのコンポーネントを共有できるようになります。

本稿は、KPartsがどんなものであり、どんなものでないのか、なぜ必要なのか、さらには、どのように機能するのか、について紹介します。また、KPartsと他のコンポーネント・モデル(とくに、out-of-processコンポーネント・モデル) と比較しつつ、アクション、プラグイン、PartManager、GUIのマージなど、KPartsで採用されている基本的な考え方について説明します。そして最後に、KPartsコンポーネント・モデルがKDE全体にわたって、とくにKonquerorとKOfficeで、使用されている様子を紹介します。

KPartsのコンポーネント: ビューアーとエディター

KPartsは、どんな種類のデータを扱うものであれ、ビューアーやエディターなどのグラフィック・コンポーネントに、特に適用されます。「読み取り専用部品(read-only parts)」と呼ばれることもあるビューアーには、たとえば、Konquerorのディレクトリ・ビュー、HTMLブラウザー・ウィジェット、画像ビューアー、DVIビューアー、PS/PDFビューアー、テキスト・ビューアーなどがあります。一方「読み書き型部品(read-write parts)」であるエディターは、テキスト・エディターやKOfficeアプリケーションなど、データを変更することのできるコンポーネントです。

コンポーネントのもっとも重要な部分は、そのインターフェースにあります。たとえば、KDEのファイル・マネージャーであるKonqueror(下の図1参照) の場合、すべてのビューアーが同じインターフェースを備えていますので、どんな種類のビューアーでも組み込むことができ、したがって、どんな種類のファイルをも扱うことができます。

グラフィック・コンポーネントは、Qtが用意しているような単なるウィジェットとは異なります。ウィジェットとコンポーネントの主な違いは、コンポーネントの場合には、メニュー項目やツールバー・ボタンなど、ホスト・アプリケーションが自身のユーザー・インターフェースに追加して組み込むことのできるようなユーザー・インターフェース項目を備えているという点です。

理解しておくべきことは、KPartsは汎用的なオブジェクト・モデルではないということです。KDEは、QtやKDEの中のすべてのオブジェクトのベース・クラスとしてQObjectを使用します。QObjectは、すべてのオブジェクトに共通する機能を提供します。名前付け、親子の関係、シグナルやスロット、イベント・モデル、プロパティーといった機能です。

上に戻る

なぜコンポーネントを使うのか

コンポーネントを作成する主な目的は、同じような機能を必要とするアプリケーション間で同じコンポーネントを使用できるようにすることにあります。しかし、あるコンポーネントが1個のアプリケーションでのみ使用される場合であっても、コンポーネント・アーキテクチャーによって高度なモジュール化が実現されるようになっているため、(従来のモデルよりも)簡単に並行動作させることができ、また、新しい機能を導入しても性能の低下を招くこと(たとえば、新しい機能が従来の機能を中断する、など) がありません。たとえば、Konquerorは、ConcurrentVersion System (CVS) サーバーに関係するファイルの管理用として、Konqueror自体のコードには1行も手を加えることなく、ツールバー・ボタンやメニュー項目を追加して、まったく新しいディレクトリ・ビューを獲得しています。

上に戻る

適当なKPartsコンポーネントの見つけ方

アプリケーション間で何かを共有するときの従来のやり方は、共有ライブラリにコードを入れておき、アプリケーションのバイナリからそれをリンクする、というものでした。この手法だと、共有コードへのアクセスが簡単です。しかしながら、この手法では、アプリケーションのインストール後にコンポーネントをインストールできないため、自由度が高くありません。コンポーネントへの実行時アクセスを行うためには、アプリケーションは、そのコンポーネントの入っている共有ライブラリを動的に探し出し、オープンする必要があります。

アプリケーションが、ある種類のデータに対するビューアーやエディターを内蔵していない場合、コンポーネントの機能に基づいてオープンすべきコンポーネントを見つけ出す必要があります。各コンポーネントは、それぞれのコンポーネントが実装しているサービスの種類(たとえば「ビューアー」) を、「サービス」ファイルに公開 (publish) します。その際、ファイルの種類(たとえば「画像」) や、KDEが特定のコンポーネントを収めているライブラリを探し出してオープンできるようにするための各種の詳細情報も添えられます。KDEのライブラリに用意されている機能の1つであるKDEトレーダー(KDE Trader) を利用することで、インストール済みのサービス・ファイルに問い合わせを行い、どのサービスがアプリケーションから指定された条件に合致するのかを調べることができます。

たとえば、KOfficeアプリケーションで印刷プリビュー (Print Preview) ボタンがクリックされると、KOfficeは、「ポストスクリプト」というファイル・タイプに関連付けられているビューアーを実装しているサービスがないか、トレーダーに問い合わせを行います。そのようなコンポーネントが存在すれば(KGhostViewに用意されている)、印刷プリビュー・ウィンドウは、そのコンポーネントの組み込みを行います。そのようなコンポーネントが存在しなければ、代替システム(fallback) として独自の (stand-alone) PostScriptビューアーを起動します。

上に戻る

KPartsの4つの概念

KPartsは、QWidgetやKMainWindowなどの標準的なKDE/QtオブジェクトをベースとするKDE部品のフレームワークです。KPartsは、Part、Plug-in、MainWindow、およびPartManagerからなる非常に単純なクラス集合を定義します。

• Part は、KDEグラフィック・コンポーネントの名前です。Partでは、もちろん、ウィジェットが提供されるわけですが、Partの機能にアクセスするためのアクションや、ユーザー・インターフェースにおけるそれらのアクションのレイアウトを記述したXMLファイルも提供されます。
• プラグイン は、組み込まれているウィジェットには実装されていないちょっとした機能で、アプリケーションのユーザー・インターフェースにマージされるいくつかのアクションを定義します。KSpread(KOfficeのスプレッドシート・プログラム) 用のCalculator Plug-in (電卓プラグイン)がその例です。プラグインは、ダイアログボックスや別個にポップアップするウィンドウのように、グラフィックなものであることもあれば、ワード・プロセッサーのスペル・チェッカーのように、アプリケーションに対応して、そのアプリケーションの上で動作するものであることもあります。
• MainWindow は、Partを組み込むための補助的な機能、すなわちMainWindowのプラグインのサポートとか、Partがウィンドウ見出しやステータス・バーにアクセスできるようにする機能を備えた特別なKDEメイン・ウィンドウです。KDEの標準的なメイン・ウィンドウは、あるいはダイアログの場合も、これらの補助的な機能を備えていなくても、部品の組み込みを行うことができます。
• Part Manager は、Partを有効にしたり無効にしたりする処理を行う、もっと抽象的なオブジェクトです。もちろん、これは、Konqueror(個々のビューがPart) やKOfficeのドキュメント (メイン・ドキュメントおよび組み込みドキュメントがKPartsのコンポーネント)のように、1個以上のPartを組み込むMainWindowsに対してのみ意味をもちます。組み込むのが独自の部品だけの単独動作の(stand-alone) ビューアーの場合、Part Managerは必要ありません。

上に戻る

KPartsモデルvs.COM/CORBAモデル

KDE 2.0の開発を始めるに当たって、KDEチームは、分散型オブジェクト通信用のミドルウェア・フレームワークであるCORBAを使用することを念頭に置いていました。ところが、開発を進めていくうちに、CORBAは、きれいに設計されたアーキテクチャーで、大規模で待ち時間の長い(high-latency) アプリケーション (データベース・アプリケーションなど) には有用だが、ユーザー・インターフェースのような、迅速な応答が求められるタスクには不向きだということが判明しました。CORBAは、本来が分散型であり、分散型オブジェクトが必要な場合には良いが、分散型オブジェクトが必要でない場合、あるいは分散型オブジェクトを使ってコンポーネントを組み込む必要がなくなった場合には、重荷となります。

CORBAは、グラフィック・コンポーネントの組み込みおよびプロセス間通信 (IPC)という2つの異なる用途に使用されていました。今ではKPartsが前者の機能を果たし、デスクトップ通信プロトコル(Desktop Communications Protocol: DCOP) が後者の機能を果たしています。デスクトップは、当然ながら、プロセス間通信を必要とするわけですが(たとえば、アプリケーション間でデータや設定値の同期をとるため)、プロセス間通信は、コンポーネントの組み込みとは独立な機能です。

CORBAに比べてKPARTSの優れている点

• KPartsのコンポーネントは、開発や利用が容易なように設計されている。それに対して、CORBAは、学習曲線が非常に急峻であり、新たな言語(IDL) や新しいデータ型を習得する必要がある。
• KPartsのアーキテクチャーは、CORBAに比べ「軽量」であり、1個のコンポーネントに1個のプロセスが対応するのではなく、1個のプロセスがアプリケーションと複数のコンポーネントを保有するようになっている。
• KPartsには、ドキュメント管理機能が用意されている (変更ステータス情報の保持、読み込みや保存のサポート、ネットワーク透過性の組込み)。
• KPartsは、機能を密接に統合している (ユーザー・インターフェースのマージや一貫したルック・アンド・フィール)。
• すべてのウィジェットがネイティブのツールキットを使用する、呼び出しが同期化されている、といった点で、プロセス内コンポーネントの統合がより簡単化されている。
• 分散型オブジェクト・アーキテクチャーには、グラフィック・オブジェクトのAPIを完全に再定義しているものもある(KDEの以前のCORBAベースのアーキテクチャーなど)。たとえば、コンポーネントからメニュー項目を作成するやり方が、ネイティブ・ツールキットを使ってメニュー項目を作成するときのやり方と同じでない、など。これに対して、KPartsでは、既存のコンポーネントの書き換えを行うことなく、KPartsアーキテクチャー経由でそれらのコンポーネントにアクセスできるようにしている。

CORBAに比べてKPARTSの劣っている点

• KPartsのコンポーネントは、CORBA/COMアプリケーションと通信できない。
• KPartsは、KDE固有のもので、C++ にのみ対応している。
• 1個のコンポーネントがアプリケーション全体をダウンさせうる。
• ライブラリのロード、アンロードには、静的オブジェクトの管理をする必要があるなど、いくつか問題がある。

KPartsの大きな制約事項は、他の言語で記述されたコンポーネントあるいは他のツールキットで作成されたコンポーネントを使用できない、という点です。ただし、この点を解消するために、KParts用のプロセス外コンポーネント・モデル(XPartsと呼ばれる) も開発されています。これは、アプリケーションからは (同じプロセスの中の)通常のKPartsコンポーネントを扱っているように見えて、実際にコンポーネントの本当の在処(ありか) である別のプロセスと (DCOPを使って) 通信を行っているのは、プロキシなのです。この技術は、viをベースにしたテキスト・エディター・コンポーネントの開発に使用されています(まだ開発中の話ですが)。

上に戻る

KPartsのフレームワーク

グラフィック・コンポーネントの中心的な概念は「アクション」です。あるアプリケーションで、編集メニューに「コピー」のメニュー項目を、ツールバーに「コピー」ボタンを設ける必要があった場合、その両方を独立に作成し、両方が同時に有効または無効にされるようにプログラムするというのが従来の方法でした。

これら2つの項目は、コピーという同じアクションについてのものですので、アクションという考え方に従えば、1つのアクションを作成すれば、アプリケーションは1つの項目を扱うだけでよい、ということになります。アクションをメニューに「差し込む(plug)」とメニュー項目が1個作成され、ツールバーに差し込むとボタンが1個作成される、というわけです。この手法の場合、GUIのレイアウトをアプリケーションのコードとは別個のXMLファイルに記述して、ユーザー・インターフェース全体を変更可能なものにすることもできます。たとえば、KDEのツールバー・エディターは、どんなアクションをツールバーにどんな順序で配置するかということを定義したXMLファイルの修正版を保存するだけです。この技術は、XML-GUIと呼ばれるものです。

上に戻る

GUIのマージ

アプリケーションは、Partを組み込むとき、そのPartのユーザー・インターフェースを自分自身にマージします。Linux以外の世界では、これの例として、MicrosoftOfficeがドキュメントを別のドキュメントに埋め込むときに行っているメニュー・マージがよく知られています。

KDEでは、メニューのマージに上述のXML-GUI技術が使用されます。すべてのアプリケーションおよびすべてのコンポーネントが、それぞれのユーザー・インターフェースをXMLファイルで定義します。Partをアプリケーションに組み込む場合、あるいはPartにプラグインを組み込む場合、ホスト側のアプリケーションでオプションとして予め定義しておいたマージ・ポイントを使用しながら、2つのXMLツリーがマージされます。

アクションやGUIのマージという概念は、KDE全体にまで拡張されてきており、KPartsとは無関係なアプリケーションにまで適用されてきています。標準的なGUIのレイアウトが、アプリケーションで定義されるものとマージされますので、ファイル(File) メニューに新規 (New)、オープン (Open)、保存 (Save)、閉じる (Close)などを含め、編集 (Edit) メニューにコピー (Copy)、カット (Cut)、ペースト(Paste) などを含めることを指定する必要はありません。アプリケーションで単にカット(Cut) のアクションを作成した場合、XMLファイルでメニューの標準的なレイアウトを無視するように指定していないかぎり、それは自動的に編集(Edit) メニューに配置されます。したがって、グラフィカルなKDEアプリケーションの開発は、非常に簡単なものになります。

上に戻る

KonquerorおよびKOfficeで使用されるKParts拡張機能

KDEには、HTMLビューアー、テキスト・エディター、画像ビューアー、Konquerorのディレクトリ・ビューなど、数多くのKPartsコンポーネントが用意されています。Konquerorそのものは、基本的に、すべての読み取り専用部品の汎用的なホストとなっています。KPartsは、できるだけ単純なものとなるよう設計されました。ただの「読み取り専用部品」の場合、アプリケーションが渡してきたURLの内容(contents) を表示するだけの部品です。これが、すべてのビューアーの基本的機能であり、画像やポストスクリプト・ファイルなどを表示するアプリケーションが必要とするのは、これだけです。ただし、たとえばブラウザーに、HTMLPartを完璧に組み込むには、これだけでは不充分です。

ブラウザーにもっと完全な機能統合を行うには、BrowserExtension と呼ばれる付加的なインターフェースをKPartsで定義し、各種のコンポーネントで実装する必要があります。ユーザーがブラウザーで前に戻る(Back) ボタンや次に進む (Forward) ボタンをクリックしたときにコンポーネントがその状態を保存したり復旧できるようにするのは拡張機能(extension) であり、(たとえばリンクをクリックしたとき) オープンすべきURLを部品が要求できるようにするのも拡張機能です。

これは、オブジェクトをサブクラス化するのではなく、オブジェクトを集合して(ReadOnlyPartにBrowserExtensionを付加して) 機能を拡張する実際的な例です。集合することで、拡張機能をいくらでも付加することができます。この場合、サブクラスの組み合わせのすべての可能性を定義する必要はありません。

KPartsは、TextEditorインターフェースなど、もっと高度なインターフェースにも使用されます。前者は、テキスト・エディターのAPIをモデル化する完全なインターフェースであり、アプリケーションからすれば、このインターフェースを備えているものならどんなテキスト・エディターでも互換性のあるエディターとして利用できるようになります。viユーザーなら、KMailで、viテキスト・エディター・コンポーネントを使ってメールの文字入力を行いたいと思うようになるでしょう(そうしたコンポーネントが現在開発中です)。一般的なImageViewerのインターフェースも現在開発中です。

といっても、KPartsを利用した最大のソフトウェア・プロジェクトは、やはりKOfficeです。KPartsは、KOfficeで、KSpreadのスプレッドシート・オブジェクトをKWord (ワード・プロセッサー)のドキュメントに埋め込むなど、ドキュメントを別のドキュメントに埋め込むために使用される新しいオブジェクト・フレームワークなのです。KOfficeのドキュメントはKPartsのコンポーネントですが、KPartsでは一つのPartに一つのウィジェットが対応するのに対して、KOfficeのアーキテクチャでは一つのドキュメントに複数のビューが許されます。KOfficeのドキュメント・モデルのベースにKPartsを採用するようにすると、KOfficeのドキュメントは単なる読み取り専用部品として表示できるようになり、KOfficeの読み取り専用ドキュメントをKonquerorに埋め込んで表示することができるようになります。KPartsのコンポーネントは、プロセス内コンポーネントですので、コンテナー部品(上の例ではワード・プロセッサー) 上で動作させた場合と、埋め込み部品 (上の例ではスプレッドシート)上で動作させた場合とで、速度に差が出ることはありません。

KPartsは、KDEにさまざまな機能統合を行えるようにするためのコンポーネント・モデルであり、既存のコンポーネントを簡単に再利用できるようにし、どんな種類のデータであっても表示や編集を可能にするものです。どんな種類のファイルでも表示することのできる「汎用的なビューアー」ウィンドウも、たった5行の簡単なコードで、アプリケーションの中に設けることができます。KPartsを利用することで、KDEアプリケーションは、KDEが提供する数々のコンポーネントにアクセスできるようになります。また、たとえば、固有のデータ・フォーマットを使用する会社独自のファイルのような新しい種類のファイルを表示するためなどに、KonquerorなどKPartsベースのアプリケーションで利用できるコンポーネントを誰でも開発することができます。

上に戻る

次なる段階

われわれの今後のKPartsのチュートリアルにもご期待ください。KPartsコンポーネントの作成方法や使い方を紹介していく予定です。また、以下の参考文献にも目を通し、KDEやKPartsについて知識を深めてください。

参考文献

• KDEの全般的な概要については、KDE入門 (developerWorks, 2001年5月) をご覧ください。
  
  
• KDEのすべてのことについては、メインのKDE Webサイトにアクセスしてください。
  
  
• KDEのファイル・マネージャーであり、Webブラウザーであり、汎用的なビューアーであるKonquerorについてもっと詳しく知りたい方は、Konqueror Webサイトにアクセスしてください。
  
  
• KDE開発のすべてについて知りたい方は、KDE Developer Webサイトにアクセスしてください。
  
  
• KPartsの詳細については、本稿の執筆者でもあるDavid Faure氏の著作、KDE 2.0Development のChapter 12, Creating and Using Components (KParts) を参照してください。
  
  
• KDEの統合開発環境 (IDE) であるKDevelopをダウンロードするには、KDevelop Webサイトにアクセスしてください。
  
  
• developerWorks に掲載されているその他のLinux参考文献もご覧ください。
  
  
• developerWorks に掲載されているその他のOpen source参考文献もご覧ください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• KPartsのコンポーネント: ビューアーとエディター
• なぜコンポーネントを使うのか
• 適当なKPartsコンポーネントの見つけ方
• KPartsの4つの概念
• KPartsモデルvs.COM/CORBAモデル
• KPartsのフレームワーク
• GUIのマージ
• KonquerorおよびKOfficeで使用されるKParts拡張機能
• 次なる段階
• 参考文献
• 著者について
• コメント