KOMをベースにした OpenParts テクノロジの目標は次のものです:
グラフィカルに他のアプリケーションの"ウィジェット"を組込むことを容易にする方法の供給
共有GUI要素を管理するより良い方法を導き、その CORBA/KOM インタフェース/実装の提供
ドキュメントビュモデルに対する基本サポートの実装
OpenParts の理解を早めるために、ちょっとした例を載せておくことにします:
ワードプロセッサと数式エディタがあり、2つは別々のアプリケーションと仮定します。 数式エディタを用いて、数式をワードプロセッサーのドキュメントに入力するとしたら、 いくつか問題が生じます: もちろん、XReparentWindow やそれに類するもの、もしくは更に簡単な QXEmbed を使って数式エディタのメインウィジェットウィンドウをはめ込むことはできます。 しかしその際、エディタのメニューバーやツールバーにアクセスせずにどうやって数式を編集するのでしょうか? これが数式ウインドウの一つなら、どう見てもこれはみっともないでしょう。 ワードプロセッサアプリケーションのメニュやツールバーが、一般的なメニュやツールバーアイテムを除いて数式エディタアプリケーションで置き換えられたなら、なかなか恰好良いと思いませんか?更に、テキストドキュメントに戻ったときには、古いメニュやツールバーが再現します。
これが OpenParts の素晴らしいところです :-) 。
OpenParts は、ビジュアルコンポーネントといった新しいシステム、メニュやツールバーのような共有 GUI 要素の新規作成法を導入することで、上述の問題を解決します。それらは随時動的です。
OpenParts の実装に際しては、全ての要素はたいてい2つのクラスからなっています。 そのインタフェース実装で、クラスネームが"If"で終わっているものと、Qt/KDEオブジェクトです。 例えば OpenParts ステータスバー要素は、次の2つのクラスで表されます: OPStatusBarは、KStatusBarから派生して、Qt/KDE特定の拡張を処理を行います。OPStatusBarIfは、実際のOpenPartsUI::StatusBar インタフェースを Qt/KDE 関数コールにインタフェース機能を"渡す"ことで、その実装を供給する役割を果たします。
OpenParts のどの Qt/KDE オブジェクトも、上記のようによくインタフェースに結びつけられるので、たいてい要素の OpenParts インタフェースにリファレンスを返す interface() 関数が存在します。 上記の例では、OPStatusBar::interface()は、直接このOPStatusBarオブジェクトに結びつけられるOPStatusBarIfオブジェクトにリファレンスを返します。