KDE 4で劇的に変わるデスクトップ（3/3 ページ）

[Tom-Chance，japan.linux.com]

サードパーティ開発者にも開かれたKDE開発

　KDEプロジェクトにとって、デスクトップをより魅力的で使いやすいものにすることは言うまでもなく最優先の課題だが、開発プラットフォームを提供することも同様に重要だ。KDE-Apps.orgにはサードパーティの開発者によって作られたアプリケーションが数多くあり、その中には、科学者、企業、デザイナーなどが使用する専門ツールもあるが、独立系ソフトウェアベンダーによる取り組みはまだ比較的少ない。

　独立系ソフトウェアベンダーの関与を増やす方法のひとつは、トレーニングの機会を提供することだ。10月にサンディエゴで開かれるOpen Source Development WorkshopsはKDEプラットフォームでの開発を考えている開発者向けのトレーニングである。しかし、多くの企業はKDEの強力なフレームワークを使わずに純粋なQtアプリケーションを開発しようとしているため、トレーニングだけでは問題は解決しないと考えるKDE開発者もいる。

　近年KolabやKontactを開発したことで有名なMartin Konold氏は、RuDI（KDEとQtの間の互換層であり、純粋にQtで書かれたアプリケーションでもKDEの強力な機能を使うことができる）という大胆な解決方法を提案している。こうしたアプリケーションをKDEで実行すると、RuDIがTenorやネットワーク透過ファイルダイアログなどKDEの機能を使えるようにしてくれる。KDEを使っていないマシンで実行しても、RuDIは問題なくQtの機能だけを使うようにしてくれる。

　KonoldのアイディアはQtとKDEだけにとどまらない。RuDIはGtkとGNOMEの開発者にとっても役に立つもので、GNOMEアプリケーションをKDEで実行した場合や、その逆の場合に表示がおかしくなる問題を解決することができる。またアプリケーションがどのプログラミング言語で書かれていても、使用しているデスクトップ環境での動作に従わせることができる。

　RuDIは、独立系ソフトウェアベンダーがKDEの機能を使ってアプリケーションの開発をしたがらない原因になっている、いくつかの問題を解決することができる。まず、過去9年間に互換性のない変更を3度行ったKDEのAPIとは違って、Qtにリンク可能なより安定したAPIを提供することができる。また、独立系ソフトウェアベンダーがKDEのライブラリに対して静的リンクを行って、後に互換性や統一性の問題を起こすという可能性を減らすことができる。

　さらには、開発者がQtだけを使って実際にはKDEデスクトップになじまないアプリケーションを作成して、KDEの機能が使われないという可能性を減らすことができる。もしこれが完成すれば、魅力的だが複雑なKDEのアーキテクチャを開発者が余計な心配をせずに使えるようになるだろう。

結論

　KDEコミュニティーから生み出される成果は素晴らしいが、KDE 4が最終的にリリースされたときにどの機能が採用されているかは誰にも分からない。Tenorはまだ漠然としたアイディアであり、書かれたコードも少ない。Plasmaフォーラムで議論されたアイディアは面白いが、まだアイディアに過ぎず、評価を行い、ユーザビリティテストを行い、実際のコードを書くところまで進展させなければならない。

　Appealは、デスクトップをより使いやすく、美しく、統合されたものにする可能性を持っている。Qtを開発しているTrolltech社はRuDIに興味を示しているが、それを実現するには多くの作業や協力が必要になるだろう。

　こうした革新的な試みが実を結べば、KDEはさらに優れたデスクトップ環境となるだろう。来年のaKademyが開催されたときに、どういった進展があったのかを見るのが楽しみである。

原文へのリンク