Qt 5 に関する構想

この記事は Qt Blog の "Thoughts about Qt 5” を翻訳したものです。
執筆: Lars Knoll 2011年5月9日

Qt 4.0 は約6年前の2005年の6月にリリースされました。この6年でソフトウェア業界には様々な変化がありました。以前はほとんどのアプリケーション開発がデスクトップシステムに対して行われていましたが、今では Web に繋がるモバイルデバイスが大幅に増えました。ユーザーインターフェースのテクノロジーはウィジェットによる静的なものから、タッチインターフェースベースの動的なものへと変化しています。Qt 4.0 のリリース以後、開発のニーズを満たすために7つの Qt のマイナーバージョンをリリースしてきました。その一例が Qt Quick のリリースです。Qt ユーザー層の拡大に伴って、組み込みおよびモバイルアプリと UI の開発者から強力な支持と新たなニーズを抱くこととなりました。

また、将来的に複数の産業に渡り Qt が業界をリードする最先端の開発フレームワークとして幅広く利用されるようになるには、 Qt 自身をリフレッシュし続けることが必要です。Qt 4 は進化してきました。その上で、技術的な観点から将来のバージョンの Qt がどのようにあるべきかを考えています。この数年の間に、次のメジャーリリースに向けた基礎を築き続けてきました。Qt Quick、QML Scenegraph や Lighthouse プロジェクトがあり、またより注目が増してきた Qt WebKit を組み合わせて、それらを基礎とした計画の元に Qt の新たなメジャーリリースへと動き始めます。

今後の数ヶ月で Qt はオープンガバナンスへと移行します。そこで議論の基点として、私の考える Qt 5 の技術的なアーキテクチャを Qt のコミュニティと共有したいと思います。

Qt の次のメジャーバージョン(Qt 5)の目標

• GPU をより活用すること。限定されたリソースでも、スムーズな(アクセラレーションされた)グラフィックパフォーマンスを可能にすること。
• 進歩したアプリケーションと UI を(QML と Javascript で)より簡単により短期間で作成できること。
• アプリケーションを Web と連携して可能な限り強力にできること。たとえば、Web のコンテンツやサービスを Qt アプリケーションに組み込んでパワーアップさせたり。そして、
• 保守や移植の際に必要となるコードの量や複雑性を削減すること。

Qt 4.7 には、Qt を次世代のアプリケーションと UI の作成を可能にするのを妨げる古いコードが含まれています。そのほとんどは Qt 開発の基礎に密接に関連している部分であり、いくつかは 4.x という縛りによって残っている部分です。

Qt 4 から Qt 5 へのアプリケーションの移行を簡単に

Qt 5 では最善の未来のために変更が必要な API を厳選し、残りの API は今と同じにするつもりです。Qt 3 から Qt 4 への移行したときのような困難を Qt 5 で繰り返すつもりはありません。具体的に言えば、多くのケースでソースコンパチビリティを確保できると信じています。しかし、バイナリコンパチビリティが崩れることは避けられないでしょう。基本的な部分のコンパチビリティを維持するために全力を尽くし、Qt 4 から Qt 5 へ大多数のアプリケーションが簡単かつそのまま移行できるようにするつもりです。

初期段階では Qt 5 は少数のオペレーティングシステムおよびプラットフォーム(たとえば、Wayland, Linux の X11, Mac と Windows プラットフォーム)にフォーカスするつもりです。プラットフォームの総数は Qt がオープンガバナンスへと移行したときに取り込まれるコミュニティの成果に依存するでしょう。上記以外の Qt 4 では現在サポートされているオペレーティングシステム(特に商用 UNIX システム)に対しては Nokia は注力しません。Qt 5 プロジェクトのゴールは各プラットフォームで可能な限り最善の機能性を提供することです。これは様々なプラットフォームにおける絶対的多数のコードを効率よく再利用しつつも、いくつかの OS においてさらに Qt を差別化する機能の提供を意味します。

オープンな開発を、みなさんと共に、Nokia からの強力な支援で

もう一つの Qt 5 での大きな変化はその開発モデルにあります。Qt 4 は主に Trolltech と Nokia の内部で開発し、その成果を開発コミュニティに公開していました。Qt 5 では、初期段階からオープンソースプロジェクトとしてのオープンな開発を計画しています。すなわち Nokia 内部の Qt 開発者と外部の貢献者の違いは全くなくなります。

みなさん、もしくはみなさんの会社が Qt 5 の開発への参加を希望される場合は、6月16日から18日に書けてベルリンで開催される Qt contributor summit に参加してください。そこが Qt 5.0 と 5.1 に関してその計画やアイデアを議論する主要な場となります。今週の Ubuntu developer summit と今月末の MeeGo conference にも Qt チームのメンバーが出席する予定です。

展望

Qt 5 はアプリケーション開発の新しい手法の礎となるべきものです。C++ を用いたネイティブの Qt の全てのパワーの焦点をモデルに移すべきです。すなわち、C++ は主に Qt Quick 用モジュールのバックエンド機能の実装に使われるべきなのです。

Qt 5 では、Qt 4 で開発された既存のコードを破壊することなしに、Qt アプリケーションの開発の中心に Qt Quick を据えるつもりです。この再構築により、将来的なアプリケーション開発手法の変化にも柔軟に対応できるでしょう。

伝統的な Qt/C++ アプリケーションは Qt 5 でも動き続けるでしょう。しかし、アプリケーションの作成方法の根本的な変化もあるでしょう。

将来的には、全ての UI が QML で書かれるようになることを期待しています。JavaScript が Qt コミュニティの主流になり、多くのアプリケーションのロジックが、場合によってはアプリケーションの全てが C++ ではなく JavaScript で書かれるようになると考えています。多くのアプリケーション開発者が実際に QML と JavaScript で開発を始めて、C++ は必要とされたときにその機能を実装するだけに使われるようになることを想定しています。そのようなユースケースでは、Qt の C++ API はアプリケーションの特に速度的に厳しい複雑な機能の実装でその力を発揮することになります。

QWidget ベースのプログラミングモデルと API は互換性のために維持するつもりですが、長期的にはデスクトップでも QML が将来のユーザーインターフェースに使われるでしょう。そのソリューションは、各デスクトッププラットフォームのネイティブのスタイル API と統合された QML ベースのコンポーネントでしょう。

四つの大きなアーキテクチャ変更

• グラフィックスタックの新アーキテクチャ
  新しいグラフィックアーキテクチャの中心には Qt Quick と QML Scenegraph を据える予定です。QPainter は依然として利用可能でしょうし、多くの場面でとても有用ですが、メインのユーザーインターフェースには使われないでしょう。Qt の動作には OpenGL (ES) 2.0 が必要となるでしょう。QWidget はシーングラフ上で動作するでしょう(現在の Qt 4 で行っているような QWidget 上でシーングラフを動かす形ではありません)。
• 全プラットフォームで Qt は Lighthouse ベースに
  Lighthouse プロジェクトは、今までよりも抽象的なウィンドウシステムへの統合方法の提供を目的として始まりました。そのプロジェクトも Qt 4.8 で成熟し、Qt 5.0 では全てのプラットフォームで Lighthouse のみを利用するつもりです。
• モジュール化したリポジトリ構造
  モジュール化に対する膨大な作業もようやくほぼ全てが完了しました。その結果は新しい モジュール化された Qt リポジトリ で確認できます。Qt のモジュール化により貢献を受け入れを促進し、加速することができます。
• 全ての QWidget 関連機能を別ライブラリへ
  既存のアプリケーションにとっては QWidget ベースのクラス群は非常に重要なものですが、時間の経過と共に全ての UI が QML で書かれたモデルへと移行していきます。QWidget ベースの機能を別ライブラリへ分割することは、Qt 5 のアーキテクチャを長期的に分かりやすくする良い指標です。

以前のブログの記事にあるように、最初の三点はこれまで行ってきたことです。そして、最後の一点に関してはちょうど今開始しているところです。これらの変更のほとんどは7月中には終わらせたいと思います。

Qt Components と Qt Mobility は Qt プラットフォームの一部としてさらに取り込まれていくでしょう。現在のように特別なステータスを持つモジュールとはしないつもりです。

2011年の末にベータクオリティのコード、2012年に正式リリース

Qt の変更すべき基礎部分はそれほど多くないと思っています。そして、既存のアプリケーションを簡単に Qt 5 へ移行させたいという事実から、既存のコードに対する変更量には注意する必要があります。提案しているあるいは始めている変更の多くは、コードを新しいモジュール構造へ変更し、全ての共有ライブラリを各モジュールのリポジトリへ移動させることです。将来にわたって互換性を維持するのを妨げるごく少数のほとんど使われない API は削除するべきでしょう。ベータクオリティのコードは今年の年末までには利用可能になり、2012年には Qt 5.0 の正式リリースを行えると考えています。

先週リリースした Qt SDK のアップデートは、これからの一年間 Nokia の Symbian および MeeGo デバイス向けに計画されています。Qt 5.0 は次世代のアプリケーションと UI の開発にフォーカスされ、Qt SDK で開発されたアプリケーションは簡単に Qt 5 へと移行できるでしょう。

開発を加速するために協力を

詳細に興味がある方は、whitepaper にアイデアがより詳しく書かれていますので参照してください。そのどれも確定はしてはいませんが、現在の我々の考えを反映してあります。

モジュール化された Qt のリポジトリ で開発を追っていくこともできます。その master ブランチは、少なくとも Linux の Wayland と X11(xcb lighthouse プラグイン)の双方で動くように維持していくつもりです。Mac や Windows で動くようにするための開発も始まりましたが、それらへの移植が再び動くようになるにはもう少しかかるでしょう。

我々は皆、この Qt のリニューアルを皆さんと共に行えることに非常に興奮しています。おそらくいくつかの機能は Qt 5.0 では完全に実装されずに、その後のリリースで完成するでしょう。しかし、Qt 4.8 から著しくデグレードされる機能を持つことはないでしょう(ええ、数ヶ月後に Qt 4.x シリーズのマイナーバージョンをあと一つリリースするつもりです!)。Qt 5 の開発に際して、Qt 4 とのソースコンパチビリティの維持にベストを尽くさなくてはなりません。そうすることでアプリケーションを Qt 5 へ可能な限り簡単に移行できるようになります。Qt 5 の開発に協力したい、または参加したいと思う方は、是非6月にベルリンで開催される Qt Contributors Summit へ参加しましょう。