Qt 5に関する考え

Qt 4.0は、ほぼ6年前の2005年6月にリリースされました。ソフトウェア業界では、長年にわたって多くのことが変わりました。その後、アプリケーションの開発は主にデスクトップシステムで行われ、現在ではネットワークに接続されたモバイルデバイスの人気が高まっています。 UIテクノロジーは、静的ウィジェットからスムーズタッチウィジェットに移行しました。 Qt 4.0から、Qtの7つのマイナーバージョンをリリースしました。QtQuickの開発など、開発者とユーザーのニーズに対応しています。 Qtユーザーベースの成長に伴い、組み込みのモバイルアプリケーションおよびUI開発者の必要性が高まっています。

さらに、将来、いくつかの業界の開発者向けの主要なフレームワークになるためには、Qtを絶えず更新および開発する必要があります。 Qt 4は進化したので、技術的な観点からQtの次のバージョンはどのようになるのかと思いました。近年、次のメジャーバージョンの基盤を作成するために取り組んでいます。 Qt Quick、QML Scenegraph、およびLighhouseプロジェクトに加えて、Qtの新しいメジャーリリースに移行するために使用する予定の基盤としてQt Webkitに重点を置いています。

Qtはオープンに管理されているので、Qt 5の技術アーキテクチャに関する議論を始めるために、Qtコミュニティと私の考えを共有したいと思います。

Qtの次のメジャーバージョン（Qt 5）の目標

GPUの使用を改善し、限られたリソースでもスムーズな（加速された）グラフィックを作成できるようにします。
（QMLとJavaScriptを使用して）最新のアプリケーションとユーザーインターフェイスを簡単かつ迅速に作成します。
Web接続アプリケーションをより強力で優れたものにします。つまり、QtアプリケーションにWebコンテンツとWebサービスを簡単に組み込むことができます。
ポートの保守と実装に必要なコードの複雑さと量を減らします。

Qt 4.7には、次世代のアプリケーションとユーザーインターフェイスを作成するためにQtを改善するためのレガシーコードが少し含まれています。開発者にとって大きな部分は依然として非常に重要ですが、一部の部分はその後の開発を妨げます。

Qt 4からQt 5への移行を簡単に

Qt 5では、APIにいくつかの変更を加え、将来の改善のために過去の制限を残す予定です。 Qt 3からQt 4への移行中に一緒にいた人たちのために、Qt 5への移行の同様の困難を繰り返すつもりはありません。ほとんどの場合、互換性を維持できると信じていますが、バイナリ互換性の損失は避けられません。基盤を壊さないように最善を尽くし、ほとんどのアプリケーションでQt 4からQt 5への移行を非常に簡単にします。

Qt 5は、少数のオペレーティングシステム/プラットフォーム（つまり、Linux、Mac、およびWindows上のWaylandおよびX11プラットフォーム）に焦点を当てます。プラットフォームの総数は、Qtに投資したオープンコミュニティの努力に依存します。 Qt 4で現在サポートされている他のオペレーティングシステム（特に商用UNIXシステム）は、ノキアにとって注目の対象ではありません。 Qt 5プロジェクトの目標は、すべてのプラットフォームで最高の機能を提供することです。つまり、Qtはさまざまなオペレーティングシステムでより差別化された機能を提供し始めると同時に、さまざまなプラットフォームでほとんどのコードを効果的に再利用します。

ノキアの強力なサポートによるあなたとのオープンソース開発

Qt 5のもう1つの大きな変更は、開発モデルです。 Qt 4は主にTrolltechとNokiaによって開発され、その後開発者コミュニティに公開されました。 Qt 5は、最初はオープンソースコードのプロジェクトとして、オープンに開発する予定です。 Nokiaと他の貢献者のために働いている開発者の間に違いはありません。

あなたまたはあなたの会社がQt 5の開発に参加したい場合は、6月16日から18日までベルリンで開催されるQt開発者サミットに参加してください。これは、Qt 5.0および5.1の計画とアイデアについて議論したい主な場所です。今週のUbuntu開発者サミットと今月末のMeeGoカンファレンスにも参加します。

復習

Qt 5は、アプリケーションを開発する新しい方法の基礎となるはずです。 Qtのネイティブ性のすべての能力はC ++の使用にありますが、C ++が主にQt Quickのモジュラー機能バックエンドの実装に使用されるモデルへの移行に焦点を合わせることが提案されています。

Qt 5では、Qt 4用に開発された既存のコードに壊滅的な影響を与えることなく、Qt QuickをQtの中心に配置する必要があります。

従来のQt / C ++アプリケーションは引き続きQt 5で動作しますが、HOWアプリケーションにいくつかの根本的な変更が加えられる予定です。

時間が経つにつれて、すべてのインターフェイスがQMLで記述されることが予想されます。 JavaScriptはQtコミュニティの中核であり、アプリケーションロジックのほとんど、さらにはアプリケーション全体がC ++ではなくJavaScriptで記述されることを期待する必要があります。多くのアプリケーション開発者はすでにQMLとJavaScriptを使い始め、必要な場合にのみC ++関数を実装することが期待されています。場合によっては、Qtが提供するC ++ APIのフルパワーを使用して、タイムクリティカルで複雑な機能アプリケーションを実装できます。

QWidgetベースのプログラミングモデルと互換性のためのAPIのセットをサポートしていますが、長期的にはデスクトップユーザーインターフェイスの将来としてQMLも見ています。ここでのソリューションは、デスクトッププラットフォームのネイティブスタイリングAPIと統合するQMLベースのコンポーネントセットです。

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

グラフィックスタックの再構築
Qt QuickとQML Scenegraphを新しいグラフィックアーキテクチャの中心に置きます。 QPainterは引き続きアクセス可能であり、多くのことに非常に役立ちますが、メインユーザーインターフェイスには使用されません。 Qtを使用するには、OpenGL（ES）2.0が必要です。 QWidgetsはシーングラフの最上位の階層になります（Qt4で現在行われているように、QWidgetsの最上位のシーングラフではありません）。
すべてのQtポートは灯台ベースになります
Lighthouseプロジェクトは、現在使用しているよりも優れたウィンドウシステムを抽象的に統合する方法を提供することを目標に立ち上げられました。現在、Qt 4.8で成熟期に達しており、Qt 5.0のすべてのQtポートにLighthouseを使用する予定です。
モジュラーリポジトリ構造
ここ数週間で多くの作業が行われ、新しいQtモジュラーリポジトリで結果を確認できます。モジュール化により、Qtの共同開発が促進され、加速されます。
すべてのQWidget関連機能を個別のライブラリーに分離する
これまでのところ、QWidgetベースのクラスは既存のアプリケーションにとって非常に重要ですが、時間の経過とともに、すべてのインターフェイスがQMLで作成されるモデルに近づきます。 QWidget関連の機能を別のライブラリに割り当てることは、長期的にクリーンなQt 5アーキテクチャを実現するための良い手段です。

前の投稿からおわかりのように、最初の3つのポイントはかなり長い間開発されており、すでに後者の作業を開始しています。これらの変更のほとんどは、8月までに行われる予定です。

QtコンポーネントとQt Mobilityは、特別なステータスのモジュールではなく、Qtプラットフォームの不可欠な部分になります。

ベータ版は2011年末までに利用可能になります。 2012年の最終リリース

Qtの基本をあまり変更したくないという事実と、既存のアプリケーションのQt 5への移行を簡単にしたいという事実により、変更の数と既存のコードベースに注意することができます。既にほとんどの変更を提案しており、コードベースを新しいモジュール構造に再構築する作業も開始しています。各動的ライブラリは独自のリポジトリに配置されています。互換性のために保存されている非常にまれに使用されるAPIを削除する必要がありますが、それ以上の開発は停止すると考えています。また、年末までにベータ版が利用可能になり、Qt 5.0の最終リリースが2012年にリリースされると考えています。

先週、Qt SDKがリリースされ、Nokia SymbianおよびMeeGoを搭載したターゲットデバイス用に来年中に使用される予定のアップデートがあります。 Qt 5.0は次世代のアプリケーションとユーザーインターフェイスを中心にしていますが、このバージョンへの移行に深刻な問題はないはずです。

開発のスピードアップにご協力ください

詳細に興味のある方のために、ここにいくつかのアイデアをより詳細に説明する公式文書へのリンクがあります。このドキュメントはいずれも完成していませんが、現在の方向性と考えを反映しています。

Qtリポジトリで作業をフォローできます。少なくともWaylandとX11（xcb lighthouseプラグイン）を搭載したLinuxでは、masterブランチをいつでも使用できるようにするつもりです。

一部の機能はQt 5.0で完全に利用できず、将来のバージョンでしか表示されない可能性がありますが、Qt 4.8の機能が大幅に低下しないことを願っています（はい、Qt 4シリーズの別の中間バージョンをリリースする予定です）今後数か月で.x！）。 Qt 5を開発するときは、Qt 4との互換性を維持するために全力を尽くして、Qt 5へのアプリケーションの移植をできるだけ簡単にする必要があります。 Qt 5の開発を支援または参加したい場合、今年6月にベルリンで開催されるQt開発者サミットでお待ちしています。