Qtで記述されたデスクトップアプリが増えないのはなぜですか？[閉まっている]

Qtでの経験で私が知っている限り、また理解している限りでは、非常に優れた、簡単に学習できるライブラリです。非常にうまく設計されたAPIを持ち、クロスプラットフォームであり、これらは魅力的な多くの機能のうちの2つにすぎません。Qtを使用しないプログラマが増えている理由を知りたいです。それに反対する欠陥がありますか？Qtよりも他のライブラリの方が優れている機能はどれですか？問題はライセンスに関連していますか？

これをバッシングの答えにするつもりはありませんが、これらが私が個人的にQtを使用しない理由です。それについて多くの良いことを言います-すなわち、APIはほとんどの時間動作し、プラットフォームをシームレスにブリッジします。しかし、私はQtを使用しません。理由は次のとおりです。

1. 場合によっては、ネイティブプログラムのように見えません。すべてのプラットフォーム用に単一のUIを設計することは、さまざまな視覚的スタイリングの理由から、マシンからマシンに移動したときに本質的に正しく見えません。たとえば、Macマシンでは、通常、分割バーは比較的太く、ボタンは小さく、アイコンで丸くなります。Windowsマシンでは、通常、分割バーは狭く、ボタンはよりテキスト形式で、正方形のデザインが多くなっています。プラットフォームごとに1つのUIを記述できるからといって、ほとんどのアプリケーションで必要なわけではありません。
2. QtはC ++ライブラリではありません。別のコンパイル手順が必要です。これにより、他のほとんどのライブラリと比較して、ビルドプロセスがはるかに複雑になります。
3. （2）の結果、C ++ IDEおよびツールはQtの詳細を理解していないため、Qt式にエラーとしてフラグを立てることができます。これは、QtCreatorまたはのようなテキストのみのエディターの使用をほぼ強制しますvim。
4. Qtは大量のソースであり、コンパイルする前に使用するすべてのマシンに存在し、プリインストールされている必要があります。これにより、ビルド環境のセットアップが非常に面倒になります。
5. LGPLでのみ使用できます。これにより、より制限の厳しいライセンスまたはより制限の少ないライセンスでリリースする必要がある場合に、シングルバイナリ展開を使用することが難しくなります。
6. 同様に記述された「プレーンオール」ネイティブアプリケーションと比較した場合、非常に大きなコンパイル済みバイナリを生成します（KDE用に記述されたアプリケーションを除く）。

人々が言うように、各ツールは各問題と状況に適合しています...

しかし、C ++プログラマなら、Qtがフレームワークです。ライバルなし。

複雑な医療用画像の商用アプリケーションを開発しており、Qtは存続しています。

私は人々がそれについて言う「詐欺」が間違っているとは言いませんが、私は彼らが長い間Qtを試していないと感じています（新しいバージョンごとに絶えず改善しています...）そして、ほとんど、あなたが世話をすれば、彼らがコメントするすべての問題は問題ではありません。

UIプラットフォームの不整合：UIウィジェットを「そのまま」使用し、カスタマイズやカスタムアートを使用しない場合のみ。

Qtプリプロセッサのオーバーロード：本当に必要がないときに、シグナルスロットメカニズムまたはQObjectの継承を悪用した場合のみ。

ちなみに、私たちはまだC＃.NETでアプリケーションを作成しており、それを長い間行ってきました。だから、私は心からの視点を持っていると思います。

私が言ったように、各状況の各ツール、

しかし、Qtは間違いなく一貫した有用なフレームワークです。

Qtで気に入らないことの中で、テンプレートでうまく動作しないという事実は、私を最も悩ませます。これはできません：

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

また、プリプロセッサではうまく機能しません。これはできません：

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

それに、シグナルに応答するものはすべてQ_OBJECTでなければならないという事実と相まって、C ++プログラマーにとってQtの作業が困難になります。JavaまたはPythonスタイルのプログラミングに慣れている人は、実際にはかなり良いでしょう。

私は実際に多くの時間と労力を費やして、タイプセーフティを取り戻し、Qtシグナルをファンクタオブジェクトに接続する方法を研究し、考案しました。http：//crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

私がそこでやりたいのは、Qt mocによって不可能に近い基本的な日常的なC ++開発です。

率直に言って、自動UIテストを実行したい場合、QtはMFC以外の町でほとんど唯一のゲームであるため... 1980年です（このたわごとでの作業は本当に大変です）。WXと言う人もいるかもしれませんが、さらに深刻な問題があります。GTKmmは私の最初の選択肢でしたが、それはすべて所有者であり、アクセシビリティを実行しないためです...業界標準のテストソフトウェアによって駆動することはできません。その点でQtは十分に困難です（アクセシビリティプラグインを変更してもほとんど機能しません）。

Qtを使用しない理由の1つは、Windowsなどの1つのアーキテクチャのみを作成する場合、C＃/。NET（またはMacのCocoa）を使用すると、常に最新の機能を利用できるためです。 -OSのホイッスル。

クロスプラットフォームアプリを作成している場合は、Javaなどの別のテクノロジーに既に大きな関心を持っている可能性があります（つまり、「Javaショップ」で働いています）。テクノロジーの選択は、言語固有のAPIなど、開発しているエコシステムによって決定される場合があります。このような場合、テクノロジーの数を最小限に抑えることが有益な場合があります。

私が考えることができる3番目の理由は、QtがC ++に基づいており、C ++はプログラミングが比較的困難/危険な言語であるということです。私はそれが専門家向けの言語だと思います。最高のパフォーマンスを発揮する必要があり、細心の注意を払うことができる場合、C ++はおそらく街で最高のゲームです。実際、Qtは、スコープから外れるように設定した場合、多くのメモリ管理の問題を改善します。また、Qt自体は、ユーザーを多くの厄介なC ++の問題から隔離するのに適しています。すべての言語とフレームワークには長所と短所があります。これは非常に複雑な問題であり、通常、ダイナーでよく見られる速度、品質、価格で要約できます（ただし、選択できるのは2つだけです）。

ルールは質問への回答に集中し続けるべきだと言っていますが、私はビリー・オニールによって提起されたいくつかの問題に反論したいと思います。

1. Qtは確かにC ++ライブラリ/フレームワーク/ヘッダーファイルです。それは、拡張します他の多くのものの中で、信号とスロットを有効にするマクロプロセッサ（moc）によって。追加のマクロコマンド（Q_OBJECTなど）を変換して、クラスにイントロスペクションと、Objective-C機能をC ++に追加すると考えられるその他のあらゆる種類の機能を追加します。C ++について十分な知識があり、この純粋さの欠如に悩まされている場合、つまりあなたがプロである場合、1）Q_OBJECTとその同類を使用しないか、2）これを行うことに感謝し、非常に限られたコーナーケースでプログラムするこれが問題を引き起こす場所。「信号とスロットにBoostを使用する」と言う人向け ある「問題」を別の「問題」と交換していると反論します。Boostは巨大であり、ドキュメントの質の低さ、恐ろしいAPI、クロスプラットフォームの恐怖（gcc 3などの古いコンパイラを考えてください）など、よく引用される独自の問題があります。

2. エディターのサポートについては、これも1に準拠していますが、私も多少同意します。実際、Qt Creatorは、Qtを使用しなくても、最高のグラフィカルC ++エディターであるピリオドです。多くのプロのプログラマーはemacsとvimを使用します。また、Eclipseは追加の構文を処理すると思います。したがって、Qtマクロ（Q_OBJECT）またはシグナル/スロットの追加に問題はありません。これらのマクロはおそらくVisual Studioにはないでしょう。なぜなら、それらはC ++に追加されているからです（私は認めています）。しかし、概して、C＃/。NETの人々は独自の技術でカバーされた多くの機能を持っているという事実のために、とにかくQtを使用するつもりはありません。

3. Qtソースのサイズについては、一晩コンパイルする限り、誰が気にしますか？Qt 4をデュアルコアMacbookで「一晩未満」でコンパイルしました。確かに、これが特定の技術を使用するかどうかを決定する原動力ではないことを願っています。これが本当に問題であれば、Mac、Linux、Windows用のプリコンパイルされたSDKをQt Webサイトからダウンロードできます。

4. ライセンスは次の3つの選択肢から選択できます。1）Qt ITSELFを変更して共有しない、またはQtを使用していて帰属表示を望まないという事実を隠したい場合の独自ライセンス（ブランドとイメージにとって非常に重要です！）2 ）GPLおよび3）LGPL。はい、静的リンクには問題があります（Qtのすべてをバイナリにローリングします）。Digiaからプロプライエタリライセンスを購入しようとしましたが、彼らは「あなたがしていることのために、あなたは本当にそれを必要としない」と私に言った。ワオ。ライセンスを販売するビジネスをしているビジネスから。

5. バイナリ/バンドルのサイズは、Qtを持たない人に配布する必要があるためです。Windowsにはすでにありますか？Visual Studioのものか、ランタイムをインストールする必要があります。Macにはすでに膨大なCocoaが付属しており、動的にリンクできます。あまり配布していませんが、〜50メガバイトの静的ファイルの配布に大きな問題はありません（UPXのようなバイナリストリッパー/圧縮ユーティリティでさらに小さくすることができます）。これをやる気にならないだけですが、帯域幅が問題になる場合は、ビルドスクリプトにUPXステップを追加します。

6. 「ネイティブルックアンドフィール」の定義は何ですか？「ほとんど」は、Macが統一されたルックアンドフィールに最も近いことに同意すると思います。しかし、ここで私は座って、Safari、iTunes、Aperture、Final Cut Pro、Pagesなどを見て、OSベンダーによって作られているという事実にもかかわらず、何も似ていません。ウィジェットのスタイリング、応答性など、「感触」の側面のほうが関連性が高いと思います。応答性に関心がある場合は、Javaや他の非常に動的な言語ではなく、C ++を使用するのが適切な理由です。（目的Cも揺れ動きますが、Qtについての神話を払拭しようとしています）

要約すると、それは複雑な問題です。しかし、神話や10年前の情報に基づいて考えると、「Qtを使用しない」理由は少ないと思います。

その一部はライセンスです。ライセンス履歴の一部については、https：//en.wikipedia.org/wiki/Qt_（software）#Licensingを参照してください。2000年まで、オープンソースを強く気にかけていた人々はQtを使用しませんでした。期間。（実際、これはGnomeの開発の元々の動機でした。）2005年まで、Windows用のフリーソフトウェアをリリースできるようにしたい人はQtを使用しませんでした。その日付の後でも、GPL以外の何かの下でフリーソフトウェアを望んでいた人々は、Qtを使用するという選択肢を持っていませんでした。したがって、これらの日付より古いフリーソフトウェアプロジェクトはQtを使用できませんでした。そしてもちろん、プロプライエタリなコードを書く人々は特権の代価を払わなければなりませんでした。

さらに、他のオプションが不足しているようではありません。たとえば、WxWidgets、GTK +、およびTkはすべてオープンソースのクロスプラットフォームツールキットです。

さらに、長い間、Windowsはデスクトップ上で非常に支配的であったため、多くのソフトウェアがWindows上でのみ実行されるコンテンツでした。Microsoftのツールチェーンをインストールする場合、他のことを心配するよりも、Microsoftの専有のものを使用する方が簡単です。多くのプログラマーがそれを行いました。

上記のほぼすべての理由に同意しますが、ここにいる多くの人々は、Qtがもたらす余分なオーバーヘッドのためにQtを使用しないと言っています。今日、最も一般的な言語（Java、C＃、Python）はすべて、かなりのオーバーヘッドを伴うため、私はこれに同意しません。

第二に、QtはC ++を使用したプログラミングを非常に簡単かつ簡単にするため、使用する余分なリソースを補います。標準のC ++ではなくQtで記述されたコンソールアプリケーションを簡単に作成できるため、かなりの数のコンソールアプリケーションに出会いました。

Qtの生産性はC / C ++の生産性よりも高いが、Pythonのような言語よりは低いと言えます。

これは純粋に炎戦争を開始する試みではなく、いくつかのポイントに対処したかっただけです。

おそらくQtがそれほど広く使用されていない本当の理由は、C ++であり、デスクトップアプリにc ++を使用する人が少ないことです。

QtはC ++ライブラリではありません。別のコンパイル手順が必要です。これにより、他のほとんどのライブラリと比較して、ビルドプロセスがはるかに複雑になります。

Visual Studioのvs-addinは、Qt独自のコマンドライン作成プロセスと同様に、これを自動的に行います。MFCのダイアログを構築するために使用されるリソースコンパイラも別の手順ですが、それはまだc ++です。

Qtは大量のソースであり、コンパイルする前に使用するすべてのマシンに存在し、プリインストールされている必要があります。これにより、ビルド環境のセットアップが非常に面倒になります。

Visual Studioの各バージョンのバイナリダウンロードがあり、ソースからのビルドは単一のコマンドです。最近、SDKのソースサイズはそれほど大きな問題ではないと思います。Visual Studioは、選択して選択するのではなく、すべてのC ++ライブラリをインストールするようになりました。その結果、コンパイラのインストールサイズは1Gbを超えています。

LGPLでのみ使用できます。これにより、より制限の厳しいライセンスまたはより制限の少ないライセンスでリリースする必要がある場合に、シングルバイナリ展開を使用することが難しくなります。

LGPLはlibにのみ適用され、コードには影響しません。はい、単一のバイナリではなくDLLを出荷する必要があります（支払いがない限り）が、Javaランタイムまたは小さなutilの.Net更新をダウンロードする必要がある世界では、これはそれほど大したことではありません。また、他のQtアプリがライブラリを共有できるように、単一のABIを備えたプラットフォームでは問題が少なくなります。

場合によっては、ネイティブプログラムのように見えません。すべてのプラットフォーム用に単一のUIを設計することは、さまざまな視覚的スタイリングの理由から、マシンからマシンに移動したときに本質的に正しく見えません。

ネイティブのウィジェットとテーマを使用することになっています。ユーザーがスタイルについてあまり気にしないように、ほとんど技術的なアプリを使用することを認めなければなりません。特にWindowsでは、すべてがスマートフォンウィジェットとしてスタイル付けされるという新しいファッションは、とにかく標準が少なくなることを意味します。

その理由は単純です。すべての主流言語に適切にバインドされておらず、手元の仕事に魔法のように常に適切であるとは限りません。

ジョブに適したツールを使用します。単純なコマンドラインアプリケーションを作成しているのに、なぜQtでそれを肥大化させるのですか？

より一般的な答えとして（ここでは関連しているので、私はそれを与えることができます）、一部のプログラマーは単純にそれを一度も試したことがなく、それを使用することに決めました。場合によっては、プログラマーがその必要性を見つけてそれを調査したことがない以外に特別な理由はありません。

Qtのようなフレームワークは、製品がすべてのプラットフォームで正しく見えるよりも、すべてのプラットフォームで同じように見えることに関心がある場合に適しています。最近では、こうした種類のアプリケーションがWebベースのテクノロジーに移行することが増えています。

私はQtが素晴らしいフレームワークであることに同意します。それでも、私はそれに関していくつかの問題があります：

1. C ++で書かれていますが、これは非常に低レベルの言語です。C ++であるという事実だけでも、他の言語で記述されたフレームワークと比較して、すべてのQtプログラマの生産性が大幅に低下します。GUI開発言語としてのC ++の主な利点は、自動メモリ管理の概念がほとんどないことです。これにより、開発プロセスでエラーが発生しやすくなります。内省的ではないため、デバッグがはるかに困難になります。他の主要なGUIツールキットのほとんどには、自動メモリ管理とイントロスペクションの概念があります。
2. すべてのクロスプラットフォームツールキットは、サポートされているすべてのプラットフォームの最小公分母のみを実装できるという問題に悩まされています。それと、さまざまなプラットフォームでのさまざまなUIガイドラインは、クロスプラットフォームGUI全体の望ましさを非常に疑問視しています。
3. Qtは、すべてのUIのコーディングを中心にしています。QtDesignerを使用してUIの一部を構築できますが、たとえば（Cocoa / Obj-C）Interface Builderや.Netツールと比較すると、大幅に不足しています。
4. Qtには多くの低レベルアプリケーション機能が含まれていますが、特定のプラットフォーム用に手作業で調整されたフレームワークを持つこととは比較できません。WindowsとOSXの両方のネイティブオペレーティングシステムライブラリは、Qtの実装よりもはるかに強力です。（オーディオフレームワーク、低レベルのファイルシステムアクセスなど）

とは言うものの、私はPyQtを使用して、迅速なアプリケーションプロトタイピングや社内アプリケーションを行うことが大好きです。Pythonを使用してすべてのコーディングを行うと、C ++に関する懸念が軽減され、実際にQtは非常に快適な場所になります。

いくつかのコメントに応じて編集します。

QtがC ++で記述されていることについて書いたとき、Qt自体について不満を言うことはあまりありませんでしたが、Qtが住んでいる環境についてはもっと不平を言っていました。 not-QtコードもC ++で作成する必要があります。そこでも、Qtは多くの優れたツールを提供しますが、最終的には、そのレベルでC ++を処理する必要があります。QtはC ++を耐えやすくしますが、それでもC ++です。

イントロスペクションに関して、私が意味するのはこれです：デバッグするのが最も難しいケースは、あなたが思っているように振る舞わないオブジェクトへのポインタがあるときです。C ++を使用すると、デバッガーはそのオブジェクトの中を少し見ることができます（たまたま型情報がある場合）が、それでも常に機能するとは限りません。一方、同じ状況でCocoaを使用してください。Cocoa / Obj-Cでは、デバッガー内でオブジェクトにメッセージ（「呼び出し関数」）を直接送信できます。オブジェクトの状態を変更したり、属性を照会したり、タイプや関数名を要求したりできます。これにより、デバッグが非常に便利になります。Qt / C ++にはこれに近いものすらありません。

私はQtが本当に好きですが、多くのアプリケーションにとって少し重いです。そのレベルの複雑さを必要としない場合もあります。Qtのすべてのオーバーヘッドを伴わない単純なものが必要な場合があります。すべてのアプリケーションがイベント駆動型である必要はなく、C ++は妥当なテンプレートセットを提供します。Boostは別の非常に優れたセットを提供し、QTが提供する多くの低レベル機能（ファイル、ソケット、マネージポインターなど）を含みます。

他のアプリケーションには、GPL、LGPL、またはQtの商用ライセンスではうまく機能しないライセンス要件があります。GPLは商用ソフトウェアには不適切です。LGPLは静的にリンクされたソフトウェアには不適切であり、商用ライセンスには費用がかかります。多くの人が支払いたくないものです。

Qtのような複雑なライブラリを許可しないセキュリティまたは安定性の考慮事項があるものもあります。

mocを実行してソースを前処理する必要があります。これは大きな問題ではありませんが、新しいユーザーにとっては困難な場合があります。多くのプログラマーは、Qmakeでqmakeを使用する必要があると考えていますが、これは誤った呼び名です。Qtを他のビルドシステムに簡単にプラグインすることができます。

一部のターゲットは、非常にメモリまたはCPUの制約を受けています。

プラットフォーム固有の落とし穴がいくつかあります。これらの落とし穴のほとんどは文書化されていません。十分に大きなアプリケーションをビルドすると、それらに遭遇し、何が起こっているのか不思議に思うでしょう（免責事項、怒りでQtを最後に使用したのは18か月前だったので、改善されたかもしれません）。

C ++のみです。他の言語バインディングも存在しますが、Qtに必要な多くの機能を隠したり、ほとんど公開しない傾向があります。

Qtを使用しない理由はたくさんあります。それが代替手段がある理由です。あなたが持っているすべてがハンマーであれば、すべての問題は釘のように見えます。

最も重要だが言及されていないもの。大きなプロジェクトでは、1つのことが非常に多くの問題と不要なコードを引き起こします。Qtのシグナルスロットメカニズムは非効率的です。Qtウィジェットは、イベントシンプルウィジェットに必要なシグナルを提供しません。たとえば、onHover、onMouseEnter、onMouseLeave、onKeyReleased、onLostFocus、onGainFocusなどの信号を設定することはできません。QTreeWidgetなどの最も複雑なウィジェットでも、1つまたは2つの非常に単純な役に立たない信号を提供します。

はい、イベントを使用できますが、!!! カスタムイベントを使用して、ウィジェットごとに新しいクラスを作成しました。これは大きな効率の損失です。

• カスタマイズされた各ウィジェットオブジェクトイベントを書き換えて、小さな変更を加えました。
• Qt Designerのものはすべて失われます。カスタムイベントですべてのウィジェットを宣伝する必要があります。
• プロジェクトは大きくなり、保守が難しくなりました。
• あなたはこのためにqtを嫌い始めました。そして、.netがデリゲートを提供する方法、シグナルスロットよりもはるかに優れている方法、.netコンポーネント（ウィジェット）が一般的に想像できるすべてのイベントを提供する方法について話し始めています。や。。など。

私の大学の1つは、コンボボックスウィジェットごとに新しいコンボボックスクラスを作成しました。彼は、非シグナルイベントを使用する必要があったためです。実話...

ただし、これまでのところ、Qtは最高のC ++ UIフレームワークです。

私自身の意見では、C ++プログラミングの学習は、複雑さを隠す他の言語に落ちるよりも簡単であり、プログラマーはバックグラウンドで実際に何が起こるかわかりません。一方、QtはC ++よりもいくつかの利点を追加し、ネイティブC ++よりも高いレベルにします。したがって、Qt C ++は、低レベルのタスク、または高レベルのタスクを同じ方法で開発したい人にとって素晴らしいフレームワークです。C ++は（いくつかの慣例により）複雑で単純な言語です。それに挑戦したくない人にとっては複雑で、好きな人にとっては簡単です。複雑さのために放置しないでください！

実際の理由は技術的なものではありません。

人々はたまたま違う。彼らの選択も同様です。均一性は人間の特徴ではありません。