あまりにも多くのことが書かれていて、少し混乱していますが、私の記憶が正しければ、Canonical は Qt を使用してモバイル デバイス向けの次世代 Unity を構築しており、近い将来にはデスクトップも Qt に移行される予定です。
私は、この決定の背後にある技術的および/または政治的な理由と、それが現在存在する Ubuntu デスクトップ アプリケーションにどのような影響を与えるかを知りたいだけです。
答え1
答えはメーリングリストとマーク・シャトルワースのブログこのブログ投稿がおそらく最もよく答えています:
Natty+1 の計画の一環として、CD 上に Qt ライブラリ用のスペースを確保する必要があり、CD と Ubuntu のデフォルト インストールに含めるために Qt で開発されたアプリケーションを評価する予定です。
使いやすさと効果的な統合は、ユーザー エクスペリエンスの重要な価値です。私たちは、選択したアプリケーションが互いに、そしてシステム全体と調和していることを重視しています。歴史的に、これは、同じ開発者ツールキットを使用することで、ある程度の調和がデフォルトで得られるため、Gtk を使用して作成されたアプリケーションを非常に優先してきたことを意味しています。とはいえ、OpenOffice と Firefox は最初から存在していたため、Gtk が絶対的な要件ではないことは明らかです。私が今主張しているのは、重要なのは価値であり、ツールキットはその目的を達成するための手段にすぎないということです。私たちは、開発者が行った技術的な選択に基づいて偏見を持つのではなく、要件をどの程度満たしているかに基づいてアプリケーションを評価する必要があります。
Ubuntu のデフォルトインストール用のアプリを評価する際には、次の点を質問する必要があります。
- それはフリーソフトウェアですか？
- それはクラス最高ですか?
- システム設定や環境設定と統合されますか?
- 他のアプリケーションと統合できますか?
- マウスやキーボードを使用できない人でもアクセスできますか?
- 見た目や感覚はシステムの他の部分と一致していますか?
もちろん、開発者が Qt を選択したことは、最初の 2 つには影響しません。Qt 自体は長い間 GPL で利用可能でしたが、最近では LGPL で利用可能になりました。また、Qt で書かれたクラス最高のソフトウェアは数多くあり、非常に有能なツールキットです。
しかし、システム設定と環境設定は、長い間 Qt と Gtk の間の摩擦の原因となってきました。システム設定と環境設定の統合は、アプリケーションがシステムに「属している」という感覚にとって重要です。これは、他のすべてのアプリケーションを管理するのに使用するのと同じツールを使用してそのアプリケーションを管理する機能と、ユーザーがそのアプリケーションで使用できる設定と環境設定の種類に影響します。これは、Ubuntu 上の Qt / KDE アプリケーションで従来から問題となっていました。Gtk アプリケーションはすべて集中管理可能な環境設定ストアを使用し、KDE アプリケーションは異なる方法で処理するためです。
これに対処するため、Canonical は Qt 用の dconf バインディングの開発を推進しており、Ubuntu の他のすべてと同じ設定フレームワークを使用する Qt アプリを作成できるようになります。私たちは dconf を熟知している Ryan Lortie と契約しており、彼は顧客向けのカスタム開発作業に Qt を使用している Canonical のスタッフと協力する予定です。その結果は Qt 開発者にとって自然で、dconf のセマンティクスとスタイルを完全に表現したものになると確信しています。
Qt チームは、Ubuntu コミュニティの幅広い分野で長年にわたり活躍してきました。半年ごとに開催される UDS には、素晴らしい Qt 代表者が参加しています。Kubuntu チームは、Qt のパッケージングとメンテナンスに深い経験と関心を持っています。また、Qt のアップストリームと、Canonical を含む Ubuntu コミュニティのさまざまな部分との間で、多くの優れた技術交流が行われています。たとえば、Qt の人々は uTouch の統合に取り組んでいます。
私は、明らかなところでは「Qt」と「KDE」を区別したいと思います。KDE アプリは dconf システム構成について何も知らず、その結果、Ubuntu デスクトップと簡単に統合できません。そのため、私たちはすぐに Amarok を Banshee の代わりとして提案するつもりはありません。しかし、dconf が優れた Qt バインディングを持つようになったら、KDE コミュニティで検討される可能性は十分にあると思います。その会話をリードできるより優れた人々がいるため、ここではこれ以上この考えを推し進めません。それでも、KDE アプリが、標準的な KDE メカニズム (これは簡単なはずです) に加えて dconf を扱えるようになれば、Ubuntu のデフォルト インストールの候補になるでしょう。
Qt にオープンにするという決定は、決して GNOME に対する批判ではありません。これは、フリー ソフトウェアの多様性と複雑性を祝うものです。使いやすさと統合性という価値は、GNOME と共通の価値であり、GNOME 開発者やプロジェクト メンバーとのコラボレーションの優れた基盤となっています。GNOME 自体が Qt を採用するかどうかはわかりませんが、採用された場合、この道を切り開くという私たちの意欲は、リーダーシップへの貢献となるでしょう。いわば、標準的な方法からある程度の逸脱を受け入れれば、活気のあるエコシステムを作るのがはるかに簡単になります。私たちの設計作業は GNOME を中心に行われ、GNOME 3.0 と gtk3 に移行するにつれて、設定と環境設定が現在の焦点となっています。
もちろん、この関係をからかう人にとっては、これはそうする絶好の機会ですが、私の考えでは、最も重要なのは、GNOMEの旗の下で実際にアプリケーションを作成する人々との強固な関係です。私たちは、フリーソフトウェア開発者の苦労を最も効果的に実現するための最良の方法になりたいと考えています。案件つまり、毎日何百万人もの人々の生活に本当の変化をもたらすための最善の方法であり、それらをユーザーと結びつける最善の方法です。
Qt を素晴らしいツールキットにしてくれた Trolltech (現在は Nokia) の優秀なスタッフに感謝します。Qt を使い、Ubuntu エクスペリエンスに参加したい開発者の皆さん、ようこそ。
答え2
GTK+ は解像度の独立性をサポートしていません。最新のモバイル デバイスはピクセル密度が非常に高くなっています。GTK+ アプリケーションをモバイル画面で実行すると、すべてのユーザー インターフェイス要素が小さすぎて使用できなくなります。
これはGTK+ の未解決バグ2008 年から 2014 年まで、「Hi-DPI スケールのサポートが追加されました。まったく同じではありませんが、このバグを解消するには十分です」というコメントとともに終了しました。
GTK+3 がリリースされたとき、互換性が失われていたため、プロジェクトには解像度の独立性を追加する絶好の機会がありました。しかし、彼らはそうしないことを選択し、今では本当に手遅れになっています。
上のGTK+ ロードマップ解像度非依存は 4.0 以降のリリースで計画されているため、4.0 がリリースされ、その後のメジャー リリースでそれが実現されることになります。その計画が維持されれば、デスクトップ GNU/Linux でも GTK+ を放棄しなければならなくなります。なぜなら、高 DPI のデスクトップ モニターやラップトップ モニターがすでに利用可能になっており、それが新たな標準になりつつあるからです。
答え3
Ubuntu CTOマット・ジマーマンのブログこれも参考になります:
最近、私が Qt について考えているのも、この精神のためです。私たちは、Ubuntu 用のアプリケーションを迅速かつ簡単に、そして苦労なく開発できるようにしたいと考えています。そして、Qt はアプリケーション開発者にとって検討する価値のある選択肢です。このことを考えてみると、Qt の強みと Ubuntu の新しい方向性のいくつかの間には、かなりの共通点があることに気づきました。
- Qtは長い歴史を持ち、ARMとx86組み込みデバイスで人気があるため、Qt は広く普及しています。消費者向け製品は 10 年以上にわたって ARM 上で Qt を使用して構築されてきました。Ubuntu 製品を ARM 向けに提供してから約 2 年が経ち、10.10 では Freescale、Marvell、TI のリファレンス ボードなど、これまで以上に多くの ARM ボードがサポートされています。Qt は最新の ARM チップのメリットを生かすために ARMv7 の最適化を追加しています。これは、ソフトウェアの選択肢を犠牲にすることなく、OEM にハードウェアの選択肢を提供するためです。Qt はアプリケーション開発者にも同じ選択肢を提供します。
- Qtはクロスプラットフォームアプリケーション フレームワークで、Windows、MacOS などへの公式ポートと、Android、iPhone、WebOS への実験的なコミュニティ ポートがあります。強力なクロスプラットフォーム サポートは Qt の元々の原則の 1 つであり、公式ポートの成熟度にそれが表れています。Ubuntu Light が Windows コンピューターにインストールされ、Ubuntu One が Android と iPhone に搭載されるようになったため、他のプラットフォームとの相互運用性が必要になります。また、Windows をターゲットにする方法をすでに知っている開発者も多数存在し、Qt を選択することで Ubuntu ユーザーにもリーチできます。
- Qtはかなり成熟しており、タッチ入力このシステムは現在、マルチタッチとジェスチャー（QML を含む）をサポートしていますが、Windows 7 と Mac OS X 10.6 でのみ完全にサポートされています。一方、Canonical はコミュニティと協力して、Qt やその他のツールキットのメリットを考えて、Linux と X11 用の低レベルのマルチタッチ フレームワークを開発しています。これらの取り組みは、最終的に中間点で融合することになります。
全体的に、Qt は、特に今、Ubuntu 用 (および Ubuntu 上) のアプリケーションを開発したい人にとって、多くのメリットがあると思います。Qt は、Kubuntu ディストリビューション全体はもちろんのこと、VLC などの人気のクロスプラットフォーム アプリケーションにもすでに採用されています。昨年のリリース時には見逃していましたが、Qt は現在 LGPL 2.1 または GPL 3.0 で利用できるため、実質的にあらゆる Ubuntu アプリケーションに適しています。強力な商業的支援と大規模な開発者コミュニティがあります。もちろん、単一のソリューションですべての開発者のニーズを満たすことはできません。Ubuntu では、この理由から複数のツールキットとフレームワークをサポートしていますが、Qt は、今後の道のりに備えてツールボックスに備えておきたい優れたツールのように思えます。
アンArs Technicaの記事このブログ投稿について議論すると、いくつかの洞察が得られます。
Qtはサードパーティの開発者をLinuxに呼び込むことができる
Gtk+ には依然として価値があり、ネイティブ Linux ソフトウェアの構築に引き続き使用する理由は数多くありますが、複数のプラットフォームをターゲットとする ISV にとって、Qt は今や当然の選択です。Qt を使用すると、基盤となるプラットフォームのネイティブな外観と操作性に準拠したり、ターゲット デバイスやフォーム ファクターに最適な完全にカスタマイズされたユーザー インターフェイスを構築したりすることが非常に簡単になります。
Nokia と Intel が MeeGo を幅広いデバイスに導入するにつれ、大手商用ソフトウェア ベンダーの関心も高まるでしょう。これらのソフトウェア会社にとって、MeeGo で使用しているのと同じコードを使用して、モバイル Qt アプリケーションを Linux デスクトップに導入するのは比較的簡単です。Qt は、特にそれを簡単に行えるように設計されています。これにより、他の方法では利用できないサードパーティ アプリケーションが利用できるようになるため、デスクトップ Linux にとって大きな勝利となります。
注目すべきは、Nokia が Qt ツールキットをサポートしているため、いくつかの著名なモバイル ソフトウェア ベンダーがすでに Qt を積極的に採用していることです。たとえば、モバイル ビデオ ストリーミング会社 Qik は、人気の高いアプリケーションを MeeGo に移植することを目指して、実験的に Qt ベースの移植作業を行っています。
この記事の著者は Gwibber IM アプリの作成者なので、Linux 用の GUI を開発した経験があります。
答え4
技術的/実用的な理由についての私の見解: Nokia は Trolltech を買収し、QT に多額の投資をしました。QT は軽量で、モバイル プラットフォーム向けに何年も最適化されています。Nokia に対する現在の意見に関係なく、N900 は時代を何年も先取りしていました...そして、Debian/QT ベースでしたが...高価でした。ただし、私はその決定について実際のところは知りません。