CanonicalがUnityの次世代製品としてGTKよりもQTを選択しているのはなぜですか？
あまりにも多くのことが書かれているので、ちょっと混乱していますが、Canonicalはモバイルデバイス向けに次世代のUnityをQtで構築しており、近い将来デスクトップも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の代表を務め、KubuntuチームはQtのパッケージングとメンテナンスに深い経験と関心を持っています。 Canonicalを含むUbuntuコミュニティの一部。たとえば、Qtの人々はuTouchの統合に取り組んでいます。
明らかな場所で「Qt」と「KDE」を区別します。 KDEアプリはdconfシステム構成について何も知らないため、結果としてUbuntuデスクトップと簡単に統合できません。だから、私たちはすぐにバンシーを置き換えるためにアマロックを提案するつもりはありません！しかし、dconfがQtの優れたバインディングを取得したら、KDEコミュニティによって検討されることは完全に妥当だと思います。必要に応じて、その会話をリードしてくれる優れた人々がいるので、ここでアイデアをさらに進めません。それにもかかわらず、KDEアプリが標準のKDEメカニズムに加えてdconfを話すことを学べば、それは簡単なはずで、Ubuntuのデフォルトインストールの候補になります。
Qtに対してオープンであるという決定は、決してGNOMEに対する批判ではありません。フリーソフトウェアの多様性と複雑さを称えるものです。使いやすさと統合というこれらの価値は、GNOMEと共通の価値であり、GNOME開発者やプロジェクトメンバーとのコラボレーションの大きな基盤となっています。おそらくGNOME自体はQtを採用するかもしれませんが、そうでない場合は、もしそれが実現すれば、このトレイルを燃やす意欲がリーダーシップに貢献するでしょう。標準的な方法からのある程度の相違を受け入れると、活気のあるエコシステムを作成するのがはるかに簡単になります。つまり、デザインに関する作業はGNOMEを中心にしています。
もちろん、これはその関係を楽しくする人にとっては絶好の機会ですが、私の考えでは、最も重要なことは、実際にGNOMEバナーの下でアプリケーションを作成する人々との強固な関係です。私たちは、これらのフリーソフトウェア開発者matterのハードワークを行うための最良の方法になりたい、つまり、毎日数百万人の生活の本当の違い、そしてそれらをユーザーに接続する最良の方法。
Qtを優れたツールキットにしてくれたTrolltech（現在のNokia）の皆さん、ありがとうございました。 Ubuntuを使い、Ubuntuエクスペリエンスの一部になりたい開発者の方へ–ようこそ。
GTK +は解像度の独立性をサポートしていません。最新のモバイルデバイスは非常に高いピクセル密度を持っています。モバイル画面でGTK +アプリケーションを実行すると、すべてのユーザーインターフェイス要素が非常に小さくなり、使用できなくなります。
これは GTK +の未解決のバグ 2008年から2014年にクローズされるまでです。 「コメント。
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は、最新のARMチップを活用するためにARMv7最適化を追加しています。これは、ソフトウェアの選択を犠牲にすることなく、OEMにハードウェアの選択肢を提供するためです。 Qtは、アプリケーション開発者にとってこれと同じ選択を保持します。
- Qtはcross-platformアプリケーションフレームワークであり、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を開発した経験があります。