Qt 5 に関する回答

この記事は Qt Blog の "Responses to Qt 5" を翻訳したものです。
執筆: Lars Knoll 2011年5月11日

うれしいことに、先日の Qt 5 のブログ記事 (日本語訳) に対して本当に多くのフィードバックを頂きました。 全てのコメントを読んで対応してきましたが、疑問や質問に回答するにはコメントに返答していくのではなく記事の形でフォローした方が良いと思います。

Qt 5 について議論する メーリングリスト を作成しました。興味がある方は購読をご検討ください。ブログ記事に返答するよりも Qt 5 に関するより良い、より構造化された議論ができると思います。

コメントで見られた関心のほとんどはいくつかのカテゴリーにグループ化できると思います。それらに対して、私の視点から回答します。

QML/JavaScript vs C++

アプリケーション開発の主流を JavaScript にしたいという点に関して、数多くの反応がありました。ここで述べていることは新たなオプションの追加についてであり、C++ の削除ではありません。Qt は C++ フレークワークを核にしており、それが変わることはありません。むしろ、C++ は非常に重要な役割を果たし続けます。ネイティブコードを書く必要のあるユースケースはたくさんあります。

そこで、ネイティブフレームワークに期待される全てのパワーとオプションを提供するために、新しい C++ API の追加や既存の C++ API の改善を続けていきます。グラフィック関連以外では(たとえば、QtCore, Network, Database 等)、特に何も変わりません。そして、グラフィック関連においてはもう一つのオプションを追加するだけなのです。

おわかりのように、我々は Qt Quick がユーザーインターフェースを作成するためのより良い技術であると強く信じています。現状ではまだ、開発者に必要なものが(特にデスクトップにおいて)不足しています。しかし、たとえば Jens がプロトタイプを作成したデスクトップコンポーネント と ListView を組み合わせることで、多くのデスクトップにおけるユースケースを上手くカバーすることができます。それでもまだ、ゴールへ向けて時間をかけて改良していく必要があることは明らかです。そうすることで皆さんが、魅力のある現代的な見た目のアプリケーションをより簡単に作成できると信じています。

QML は JavaScript の文法を拡張したものであるので、JavaScript はこの目的へ自然に適合します。アプリケーションのロジックをスクリプト言語を使ったプロトタイプとして書けるようになることで、開発が容易になります。Qt が提案したいのは選択肢であり、必要条件ではないことに注意してください。

その他のスクリプト言語に関する質問について: 答えは「いいえ」です。その他のスクリプト言語を Qt や QML に統合する予定はありません。その理由は多々ありますが、単純に Qt Quick のアーキテクチャが複雑になり、開発が遅くなるかもしれないのというのがその一つです。長い目で見れば、複数の言語をサポートするよりも一つの言語に制限をする方が管理がしやすいのです。開発者に一つの言語のみを提案するのもまた非常に重要です。複数のスクリプト言語は混乱させるだけかもしれません。JavaScript が選ばれたのは、本当にパフォーマンスの高いエンジンがあるからですし、また Qt の開発者のベースである C++ とよく似ている言語であるからでもあります。また、全てのスクリプト言語の中で最も広く使われている言語でもあります。

QWidget と QGraphicsView

QWidget ベースのクラスが突然使えなくなることはないでしょう。また、突然開発が止まることもないでしょう。それらを別のモジュールに移動させるのは、Qt Quick/QML がそれらのクラスから確実に影響を受けないようにするためです。私たち自身も Qt Creator やその他の将来作成するであろうアプリケーションで C++ の利用を継続するつもりです。

また、Qt のグラフィックスタックのアーキテクチャを再設計することによって、パフォーマンスに大きな問題が発生するとは思っていません。プラットフォームによっては若干速くなることもあるでしょう(その内容だけで記事にできるでしょう)。X11 のリモート接続はそれに当てはまりうる例です。しかし、業界のトレンドは X11 ではなく、その他への移行です。そのユースケースのサポートに強い興味のある人々のグループがあれば、NX のようなテクノロジーと統合するための開発が行われるかもしれません。Lighthouse アーキテクチャによって、これはただ一つのプラグインだけで可能でしょう。

アプリケーションの UI を Qt Quick を使って書き換えなければならないかもと心配している方もいらっしゃるかもしれませんが、その必要はありません。しかし、QWidget に比べると長期的にはより良い、より簡単な手法になると強く信じていることを再び言及します。

OpenGL の必要性

前の記事で述べたように Qt 5 は OpenGL 2.0 (デスクトップ GL もしくは GL ES) のサポートが必要になるでしょう。その理由は単純で、アプリケーション開発者の共通基盤としてはるかに良いものであるからです。また、これにより内部アーキテクチャを非常にシンプルにすることもできます。

その要求に対して、ブログ記事への反応にあったような懸念事項の全ては、Qt の内部でも話し合われていました。最終的にはそれが前進するための最善の道筋であり、ほとんどのユーザにとって実際には問題にならないであろうと結論づけました。

Mac と Windows では現実には問題にはならないはずです。Mac OS X は全てのデバイスで優良な OpenGL をサポートしています。Windows においては ANGLE ライブラリで OpenGL ES を DirectX に翻訳することができますし、それをオフにすればネイティブの GL で動かすこともできます。

Linux デスクトップではいくつかのドライバの品質によって問題が再発します。その解決は残念ながら Qt が対応できる範囲外です。しかし、現在の Qt のソフトウェア描画エンジンと同等(あるいはより良い)の別のエンジンがコミュニティで開発されています(Mesa with llvmpipe)。Linux で一貫して GL を利用できるようになれば、Linux スタック全体における素晴らしい改良となるでしょう。

最後のプラットフォームは GPU を持たないローエンドのハードウェアや組み込みシステムです。それらのシステムは急速に減って行き、GPU の有無による SoC の価格差が非常に小さくなってきています。GPU によるユーザー体験の達成という大きな利点と、前述のソフトウェア GL 利用のオプションを考慮すると、OpenGL に賭ける方が良いと信じています。

その他

質問されたその他の機能(C++11 サポートの改善など)についても検討しています。ただ、Qt 5.0 は開発の終わりではありません。さらに多くの改良がなされる 5.x もリリースしていきます。

5.0 に向けて行うべき内容の範囲は、慎重に制限しなくてはなりません。壊れてはいけないものは壊さないようにするための激務をこなすでしょう。また、タイミング良く 5.0 をリリース出来るようにするつもりです。