あまりにも多くのことが書かれているので、ちょっと混乱していますが、もし誤解しない限り、CanonicalはQtを使用してモバイルデバイス向けの次世代Unityを構築しており、近い将来デスクトップもqtに移行します。
この決定を下した技術的および/または政治的理由と、現在存在するUbuntuデスクトップアプリケーションにとってどのような影響があるのかを知りたかっただけです。
回答:
回答は、メーリングリストとMark Shuttleworthのブログで見つけることができます。このブログ投稿はおそらくそれを最もよく答えます：
Natty + 1の計画の一環として、Qtライブラリ用のCD上のスペースを見つける必要があります。また、Qtで開発されたアプリケーションをCDに含めてUbuntuのデフォルトインストールを評価します。
使いやすさと効果的な統合は、ユーザーエクスペリエンスの重要な価値です。私たちが選択するアプリケーションは、互いに、そしてシステム全体と調和するように気を配っています。歴史的には、Gtkを使用して作成されたアプリケーションは、同じ開発者ツールキットを使用することでデフォルトで一定の調和がもたらされるため、非常に強い優先順位を与えてきました。とはいえ、OpenOfficeとFirefoxは最初から存在していたため、Gtkは明らかに絶対的な要件ではありません。私が今主張しているのは、重要なのは価値であり、ツールキットはそのための手段にすぎないということです。開発者が行った技術的な選択に基づいてアプリを害するのではなく、要件をどれだけ満たしているかに基づいてアプリを評価する必要があります。
Ubuntuのデフォルトインストール用のアプリを評価する際には、次の点を確認する必要があります。
- それはフリーソフトウェアですか？
- クラス最高ですか？
- システムの設定や環境設定と統合されますか？
- 他のアプリケーションと統合しますか？
- マウスやキーボードを使用できない人もアクセスできますか？
- それは、システムの残りの部分と一貫性のある外観と感じですか？
もちろん、開発者が選択したQtは最初の2つには影響しません。Qt自体は長い間GPLの下で利用可能でしたが、最近ではLGPLの下でも利用可能になりました。そして、Qtで書かれたクラス最高のソフトウェアがたくさんあります。これは非常に有能なツールキットです。
ただし、システム設定と設定は、QtとGtkの間の摩擦の原因となっています。システムの設定や設定との統合は、システムに「属する」アプリケーションの感覚にとって重要です。他のすべてのアプリケーションを管理するために使用するものと同じツールを使用してそのアプリケーションを管理する機能、およびユーザーがアプリで使用できる各種の設定と設定のエクスペリエンスに影響します。これは、UbuntuのQt / KDEアプリケーションでは伝統的に問題でした。Gtkアプリはすべて一元管理可能な設定ストアを使用し、KDEアプリは異なる方法で動作するためです。
これに対処するために、CanonicalはQtのdconfバインディングの開発を推進しているため、Ubuntuの他のすべてと同じ設定フレームワークを使用するQtアプリを作成できます。Ryan Lortieと契約しました。彼は明らかにdconfを非常によく知っています。彼は、顧客のカスタム開発作業にQtを使用しているCanonicalの人々と協力します。結果はQt開発者にとって自然であり、dconfのセマンティクスとスタイルの完全な表現であると確信しています。
Qtチームは長い間、より広いUbuntuコミュニティでうまく機能していました。6か月ごとにUDSに優れたQtの代表者がいます。 Canonicalを含むUbuntuコミュニティの一部。たとえば、Qtの人々はuTouchの統合に取り組んでいます。
明らかな場所で「Qt」と「KDE」を区別します。KDEアプリはdconfシステム構成について何も知らないため、結果としてUbuntuデスクトップと簡単に統合できません。したがって、Bansheeをすぐに置き換えるAmarokをすぐに提案するつもりはありません！しかし、dconfがQtの優れたバインディングを取得したら、KDEコミュニティによって検討されることは完全にもっともらしいと思います。必要に応じて、その会話をリードしてくれる優れた人々がいるので、ここではその考えをさらに推し進めません。それにもかかわらず、KDEアプリが標準のKDEメカニズムに加えてdconfを話すことを学べば、それは簡単なはずであり、Ubuntuのデフォルトインストールの候補になります。
Qtに対してオープンであるという決定は、決してGNOMEに対する批判ではありません。これは、フリーソフトウェアの多様性と複雑さを称えるものです。使いやすさと統合というこれらの価値は、GNOMEと共通の価値であり、GNOME開発者やプロジェクトメンバーとのコラボレーションの大きな基盤となっています。おそらくGNOME自体がQtを採用するかもしれませんが、そうでない場合は、もしそれが実現すれば、このトレイルを燃やす意欲がリーダーシップに貢献するでしょう。標準的な方法からのある程度の相違を受け入れると、活気のあるエコシステムを作成するのがはるかに簡単になります。つまり、デザインに関する私たちの仕事はGNOMEを中心にしています。
もちろん、これはその関係を楽しくする人にとっては絶好の機会ですが、最も重要なことは、実際にGNOMEバナーの下でアプリケーションを作成する人々との強固な関係です。私たちは、これらのフリーソフトウェア開発者のハードワークを重要にする最も良い方法であり、それが意味することは、それが毎日何百万人もの生活に真の違いをもたらすことを保証する最良の方法であり、それらをつなぐ最良の方法ですユーザー。
Qtを優れたツールキットにしてくれたTrolltech（現在のNokia）に感謝します。Ubuntuを使い、Ubuntuエクスペリエンスの一部になりたい開発者の方へ–ようこそ。
GTK +は解像度の独立性をサポートしていません。最新のモバイルデバイスは非常に高いピクセル密度を持っています。モバイル画面でGTK +アプリケーションを実行すると、すべてのユーザーインターフェイス要素が非常に小さくなり、使用できなくなります。
これは2008年からGTK +のオープンバグであり、2014年に「hi-dpiスケールのサポートがあります。まったく同じではありませんが、このバグを廃止するのに十分近い」というコメントがあります。
GTK + 3がリリースされたとき、プロジェクトには解像度の独立性を追加する絶好の機会がありました。とにかく互換性を壊していたからです。彼らはそうしないことを選択し、今では彼らにとっては遅すぎます。
上のGTK +ロードマップ彼らはその後のメジャーリリースはそれを持っています4.0をリリースしますので、解像度の独立性は、4.0の後にリリースを予定しています。もし彼らがその計画に固執するなら、デスクトップGNU / LinuxでさえGTK +を放棄しなければならないでしょう。なぜなら、高DPIデスクトップモニターとラップトップモニターはすでに利用可能であり、新しい標準になりつつあるからです。
技術的/実用的な理由に関する私の見解：NokiaはTrolltechを購入し、QTに多くの投資をしました。軽量であり、モバイルプラットフォーム向けに何年も最適化されています。Nokiaの現在の意見に関係なく、N900は時代を先取りしていました...そしてdebian / QTベースでした...しかし高価です。しかし、私は決定についての本当の知識を持っていません。
Ubuntu CTO Matt Zimmermanのブログも参考になります。
私が最近Qtについて考えていたのは、この精神です。Ubuntu向けのアプリケーションを迅速かつ簡単に開発できるようにしたいと考えています。Qtは、アプリケーション開発者が検討する価値のあるオプションです。これについて考えると、Qtの長所とUbuntuのいくつかの新しい方向性の間にかなりの共通点があることに気付きました。
- Qtは、組み込みデバイスで人気があるため、ARMとx86で長い間使用されてきました。消費者向け製品は、ARMでQtを使用して10年以上にわたって構築されてきました。Ubuntu製品を2年近くARMで使用できるようにしました。10.10は、Freescale、Marvell、TIのリファレンスボードなど、これまで以上に多くのARMボードをサポートしています。Qtは、ARMv7最適化を追加して、最新のARMチップを活用しています。これは、ソフトウェアの選択を犠牲にすることなく、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用（およびそれ以上）のアプリケーションを開発したい人々に提供できるものがたくさんあると思います。Kubuntuディストリビューション全体は言うまでもなく、VLCのような人気のあるクロスプラットフォームアプリケーションを既に強化しています。昨年これが起こったときに見逃していましたが、QtはLGPL 2.1またはGPL 3.0のいずれかで利用できるようになったため、事実上すべてのUbuntuアプリケーションに適しています。強力な商業的支援と大規模な開発者コミュニティがあります。もちろん、単一のソリューションですべての開発者のニーズを満たすことはできず、Ubuntuはこの理由で複数のツールキットとフレームワークをサポートしますが、Qtは今後の道のツールボックスにある素晴らしいツールのようです。
このブログ投稿を議論するArs Technicaの記事は、いくつかの洞察を提供します。
Qtはサードパーティの開発者をLinuxに持ち込むことができます
Gtk +にはまだ価値があり、ネイティブLinuxソフトウェアの構築にGtk +を使用し続ける多くの理由がありますが、Qtは複数のプラットフォームをターゲットとするISVにとって明らかな選択肢です。Qtを使用すると、基盤となるプラットフォームのネイティブルックアンドフィールに非常に簡単に準拠したり、ターゲットデバイスまたはフォームファクターに最適な完全にカスタムのユーザーインターフェイスを構築したりできます。
NokiaとIntelがMeeGoをさまざまなデバイスに導入すると、主要な商用ソフトウェアベンダーを引き付けることができます。これらのソフトウェア企業は、MeeGoで使用しているのと同じコードを使用して、モバイルQtアプリケーションをLinuxデスクトップに比較的簡単に導入できます。Qtは、それを簡単にするために特別に設計されています。これは、他の方法では利用できないサードパーティ製のアプリケーションをもたらすため、デスクトップLinuxにとって大きな勝利となります。
一部の著名なモバイルソフトウェアベンダーは、ツールキットに対するNokiaのサポートにより、すでにQtを積極的に採用していることに注意してください。たとえば、モバイルビデオストリーミング会社のQikは、MeeGoに導入することを目的として、人気のあるアプリケーションの実験的なQtベースの移植に取り組んでいます。
この記事の著者はGwibber IMアプリの作成者であるため、Linux用のGUIを開発した経験があります。