Qtで書かれたデスクトップアプリが増えないのはなぜですか？
私の知る限り、Qtでの経験で理解している限り、ライブラリは非常によく、簡単に学ぶことができます。非常によく設計されたAPIを備え、クロスプラットフォームであり、これらは魅力的にする多くの機能のうちの2つにすぎません。なぜより多くのプログラマーがQtを使わないのか知りたいです。それに対して反対する欠陥はありますか？ Qtよりも他のライブラリの優れている機能はどれですか。問題はライセンスに関連していますか？
私はこれをバッシング答えにするつもりはありませんが、これらは私が個人的にQtを使用しない理由です。それについて言うべきたくさんの良いことがあります-つまり、APIはほとんどの時間機能し、プラットフォームをシームレスにブリッジします。しかし、私はQtを使用しません。
- 場合によっては、ネイティブプログラムのようには見えません。すべてのプラットフォームで単一のUIを設計することは、さまざまな視覚的スタイルの理由により、マシン間で移動したときに本質的に正しく見えません。たとえば、Macマシンでは、分割バーは通常比較的太く、ボタンは小さく、アイコンで丸められます。 Windowsマシンでは、通常、分割バーは細く、ボタンはよりテキストであり、より正方形のデザインになっています。すべてのプラットフォームに1つのUIを記述できるからといって、ほとんどのアプリケーションに必要なわけではありません。
- QtはC++ライブラリではありません。別のコンパイル手順が必要になるため、他のほとんどのライブラリと比較すると、ビルドプロセスがはるかに複雑になります。
- （2）の結果として、C++ IDEおよびツールはQtの詳細を理解しないため、Qt式にエラーのフラグを付けることができます。これはQtCreatorまたは
vimのようなテキストのみのエディターの使用をほぼ強制します。 - Qtは大量のソースであり、コンパイルする前に、使用するすべてのマシンに存在し、プレインストールされている必要があります。これにより、ビルド環境の設定が非常に面倒になる可能性があります。
- これはLGPLでのみ利用可能であり、より制限の厳しい、またはより制限の少ないライセンスでリリースする必要がある場合に、単一バイナリデプロイメントを使用することが困難になります。
- 同様に書かれた「プレーンオール」ネイティブアプリケーション（もちろん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に及ばない町で唯一のゲームであるので、私はそれにこだわっています。 WXと言う人もいますが、さらに深刻な問題があります。 GTKmmは私の最初の選択でしたが、すべて所有者であり、アクセシビリティを行わないため、業界標準のテストソフトウェアで駆動することはできません。 Qtはその点で十分に困難です（barelyアクセシビリティプラグインを変更すると機能します）。
Qtを使用しない理由の1つは、Windowsなどの1つのアーキテクチャのみを記述する場合、C＃/。NET（またはMacのCocoa）を使用することです。なぜなら、それらは常に最新のベルを利用できるためです。 -OSのホイッスル。
クロスプラットフォームアプリを作成している場合は、すでにJava（つまり、「Javaショップ」で働いている）などの別のテクノロジーにすでに重くのしかかっている可能性があります。テクノロジーの選択によっては、言語固有のAPIなど、開発中のエコシステムによって、このような場合、テクノロジーの数を最小限に抑えることが有益な場合があります。
QtはC++をベースにしており、C++はプログラムするのが比較的難しい/危険な言語であることを私が考えることができる3つ目の理由です。これは専門家向けの言語だと思います。最高のパフォーマンスを必要とし、細心の注意を払う必要がある場合、C++はおそらく町で最高のゲームです。実際、スコープから外れるように設定すると、Qtは多くのメモリ管理問題を改善します。また、Qt自体は、ユーザーをC++の厄介な問題の多くから隔離するのに役立ちます。すべての言語とフレームワークには長所と短所があります。これは非常に非常に複雑な問題であり、通常、ダイナーでよく見られる速度、速度、品質、価格によって要約できます（ただし、2つしか選択できません）。
ルールは私が質問への回答に集中する必要があることを示していますが、ビリー・オニールによって提起された問題のいくつかに反論したいと思います。
Qtは確かにC++ライブラリ/フレームワーク/ヘッダーファイルです。これは、信号やスロットなどを有効にするマクロプロセッサ（moc）によるaugmentedです。追加のマクロコマンド（Q_OBJECTなど）を変換して、クラスがイントロスペクションや、Objective-Cの機能をC++に追加すると考えられる他のあらゆる種類の機能を持つようにします。この純粋さが欠けていることに腹を立てるのに十分なC++を知っている場合、つまりプロである場合、1）Q_OBJECTとそのilkを使用しないか、2）これを行うことに感謝し、非常に限られたコーナーケースを中心にプログラミングします。これが問題を引き起こす場所。 「信号とスロットにBoostを使用してください！」と言う人向け。次に、ある「問題」を別の「問題」と交換していることを伝えます。 Boostは巨大であり、貧弱なドキュメント、恐ろしいAPI、クロスプラットフォームのホラー（gcc 3.3のような古いコンパイラーやAIXのような大きな鉄のコンパイラーなど）のような、よく引用される独自の問題があります。
エディターのサポートについては、これも1から続いています。実際、Qt Creatorは、たとえQtのものを使用しなくても、IMHOで最高のグラフィカルC++エディター、ピリオドです。多くのプロのプログラマーがemacsとvimを使用しています。また、Eclipseは追加の構文を処理すると思います。したがって、Qtマクロ（Q_OBJECT）またはシグナル/スロットの追加に問題はありません。これらのマクロはC++への追加機能であるため（おそらく認めます）、Visual Studioでは見つかりません。しかし、概して、C＃/。NETの人々は、独自の独自の技術でカバーされている多くの機能を持っているという事実により、とにかくQtを使用することはありません。
Qtソースのサイズについて、それが一晩でコンパイルされる限り、誰が気にしますか？デュアルコアMacbookでQt 4を「一晩未満」でコンパイルしました。これが、特定のテクノロジーを使用するか使用しないかの決定を後押しするものではないことを私は確信しています。これが本当に問題である場合は、Qt WebサイトからMac、Linux、およびWindows用にプリコンパイルされたSDKをダウンロードできます。
ライセンスは3つの選択肢で利用できます：1）Qtを変更したい場合の所有権ライセンス[〜＃〜] itself [〜＃〜]共有せず、またはQtを使用していることを非表示にし、アトリビューションを与えたくない（ブランディングとイメージにとって非常に重要である可能性がある！）2）GPLおよび3）LGPL。はい、静的リンク（Qtのすべてをバイナリにローリングする）には問題があります-しかし、内部を覗いてQt（属性！） Digiaからプロプライエタリライセンスを購入しようとすると、彼らは「あなたがしていることのために、あなたは本当にそれを必要としない」と私に言った。ワオ。ライセンスを販売するビジネスに従事しているビジネスから。
バイナリ/バンドルのサイズは、Qtを持っていない人に配布する必要があるためです。Windowsにはすでにありますか？ Visual Studioのものか、ランタイムをインストールする必要があります。 Macにはすでに巨大なCocoaが付属しており、動的にリンクできます。私は多くの配布を行っていませんが、50メガバイトまでの静的ファイル（UPXなどのバイナリストリッパー/圧縮ユーティリティのいくつかでさらに小さくすることができます）の配布にそれほど問題はありませんでした。私はこれを行うには十分気にしませんが、帯域幅が問題になる場合は、ビルドスクリプトにUPXステップを追加します。
「ネイティブルックアンドフィール」の定義とは「ほとんど」はMacが統一されたルックアンドフィールに最も近くなることに同意するだろう。しかし、ここに座って、Safari、iTunes、Aperture、Final Cut Pro、Pagesなどを見てみます。OSベンダーによって作成されているにもかかわらず、それらは同じように見えません。ウィジェットのスタイル、応答性など、「感触」の側面の方が関連性が高いと思います。応答性を重視する場合は、Javaまたはその他の非常に動的な言語ではなくC++を使用することをお勧めします。 （目的Cも揺るぎませんが、Qtに関する神話を払拭しようとしています）
要約すると、それは複雑な問題です。しかし、神話や時代遅れの情報に基づいて考えるのと同じように、「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）のすべてがかなりのオーバーヘッドを抱えているため、私はそれに同意しません。
第2に、QtはC++を使用したプログラミングを非常に簡単で簡単にするので、使用する追加のリソースを補います。標準のC++ではなくQtで記述されたコンソールアプリケーションをかなり多く見つけました。それらは簡単に記述できるためです。
Qtの生産性はC/C++の生産性よりは優れていますが、Pythonのような言語よりは低いと言えます。
これは本当に炎上戦争を開始するための試みではありません。私はいくつかのポイントに触れたかっただけです。
おそらく、Qtがあまり広く使用されていない本当の理由は、それがC++であり、デスクトップアプリでc ++を使用する人が少ないためです。
QtはC++ライブラリではありません。別のコンパイル手順が必要になるため、他のほとんどのライブラリと比較すると、ビルドプロセスがはるかに複雑になります。
Visual Studioのvs-addinは、Qt独自のコマンドラインmakeプロセスと同様に、これを自動的に行います。 MFCのダイアログを構築するために使用されるリソースコンパイラも別の手順ですが、それはまだc ++です。
Qtは大量のソースであり、コンパイルする前に、使用するすべてのマシンに存在し、プレインストールされている必要があります。これにより、ビルド環境の設定が非常に面倒になる可能性があります。
Visual Studioのバージョンごとにバイナリダウンロードがあり、ソースからのビルドは単一のコマンドです。最近、SDKのソースサイズがあまり重要視されていないようです。 Visual Studioは、ユーザーが選択できるようにするのではなく、すべてのC++ライブラリをインストールするようになりました。その結果、コンパイラーのインストールサイズは> 1Gbです。
これはLGPLでのみ利用可能であり、より制限の厳しい、またはより制限の少ないライセンスでリリースする必要がある場合に、単一バイナリデプロイメントを使用することが困難になります。
LGPLはlibにのみ適用され、コードには影響しません。はい、それはあなたが単一のバイナリではなくDLLを出荷する必要があることを意味します（あなたが支払う場合を除きます）、しかしJavaランタイムまたは。他のQtアプリがライブラリを共有できるように、単一のABIを備えたプラットフォームでは問題も少ないです。
場合によっては、ネイティブプログラムのようには見えません。すべてのプラットフォームで単一のUIを設計することは、さまざまな視覚的スタイルの理由により、マシン間で移動したときに本質的に正しく見えません。
ネイティブのウィジェットとテーマを使用することになっています。私はユーザーがスタイルにあまり関心がないように、主に技術的なアプリをしていることを認めなければなりません。特にWindowsでは、すべてをスマホウィジェットとしてスタイル設定するための新しい方法は、とにかく標準が少なくなっていることを意味します。
その理由は単純です。すべての主流言語への適切なバインディングがなく、魔法のようにalwaysが目前の仕事に適しているわけではないためです。
ジョブに適したツールを使用します。単純なコマンドラインアプリケーションを作成している場合、Qtを使用してそれを膨らませるのはなぜですか？
より一般的な答え（私はここに関係があるので私が与えることができます）として、一部のプログラマーは単にそれを試してみて、それを使用することに決めたことはありません。場合によっては、プログラマーがその必要性を見つけて調べていないこと以外に特別な理由はありません。
Qtのようなフレームワークは、すべてのプラットフォームでの製品の外観同じよりも、すべてのプラットフォームでの製品の外観rightに関心がある場合に適しています。最近では、これらの種類のアプリケーションがWebベースのテクノロジーに移行することが多くなっています。
Qtは素晴らしいフレームワークであることに同意します。それでも、私にはいくつかの問題があります。
- それはC++で書かれています。これは本当に低レベルの言語です。 C++であるという事実だけでも、他の言語で記述されたフレームワークと比較して、すべてのQtプログラマーの生産性が大幅に低下します。 GUI開発言語としてのC++の私の主な牛肉は、自動メモリ管理の概念がほとんどないため、開発プロセスでエラーが発生しやすくなることです。これは内省的ではないため、デバッグがはるかに困難になります。他の主要なGUIツールキットのほとんどには、自動メモリ管理とイントロスペクションの概念があります。
- すべてのクロスプラットフォームツールキットには、サポートされているすべてのプラットフォームの最小公分母しか実装できないという問題があります。それと、さまざまなプラットフォームでのさまざまなUIガイドラインは、全体としてクロスプラットフォームGUIの望ましさに疑問を投げかけています。
- Qtは、すべてのUIのコーディングに非常に集中しています。 QtDesignerを使用してUIの一部を構築できる場合でも、たとえば、（Cocoa/Obj-C）インターフェイスと比較すると、それは非常に不足していますビルダーまたは.Netツール。
- Qtには多くの低レベルのアプリケーション機能が含まれていますが、特定のプラットフォーム用に手動で調整されたフレームワークを持つことと比較することはできません。 WindowsとOSXの両方のネイティブオペレーティングシステムライブラリは、Qtの実装よりもはるかに強力です。 （オーディオフレームワーク、低レベルのファイルシステムアクセスなどを考えてください）
とはいえ、私はPyQtを使用してラピッドアプリケーションプロトタイピングや社内アプリケーションを作成するのが大好きです。 Pythonを使用してすべてのコーディングを行うと、C++に関する懸念が軽減され、Qtは非常に快適な場所になります。
いくつかのコメントに応じて編集：
QtがC++で記述されていることについて書いたとき、Qt自体についてはそれほど不満を言っていませんでした。Qtが住んでいる環境についての詳細です。 not-QtコードもC++で作成する必要があります。そこにも、Qtは多くの素晴らしいツールを提供しますが、最終的には、そのレベルでC++を扱う必要があります。 QtはC++を耐えられるようにしますが、それでもC++です。
イントロスペクションに関して言えば、私が意味することは、デバッグするのが最も難しいケースは、あなたが思っているように動作しないオブジェクトへのポインターがある場合です。 C++を使用すると、デバッガーはそのオブジェクトの内部を少し見ることができる場合があります（thwtポイントに型情報がある場合）が、それでも常に機能するとは限りません。一方、同じ状況のココアを取ってください。 Cocoa/Obj-Cでは、デバッガー内のオブジェクトにメッセージ（「関数の呼び出し」）を送信できます。オブジェクトの状態を変更したり、属性を照会したり、タイプや関数名を要求したりできます。これにより、デバッグがさらに便利になります。 Qt/C++はそれに近いものすらありません。
私の意見では、C++プログラミングの学習は、複雑さを隠す他の言語に陥るよりも簡単であり、プログラマーはバックグラウンドで実際に何が起こるかを知りません。一方、QtはC++に比べていくつかの利点を追加し、ネイティブC++よりも高いレベルにします。したがって、Qt C++は、同じ方法で低レベルのタスクまたは高レベルのタスクを開発したい人にとって優れたフレームワークです。 C++は（いくつかの慣例により）複雑で単純な言語です。挑戦したくない人にとっては複雑で、好きな人にとっては単純です。複雑さを忘れないでください。
最も重要だが言及されていないもの。大きなプロジェクトでは、1つのことが非常に多くの問題と不要なコードを引き起こします。 Qtのシグナルスロットメカニズムは非効率的です。 Qtウィジェットは、イベントシンプルウィジェットに必要なシグナルを提供しません。たとえば、onHover、onMouseEnter、onMouseLeave、onKeyReleased、onLostFocus、onGainFocusなどの信号を設定することはできません。QTreeWidgetなどの最も複雑なウィジェットでも、1つまたは2つの非常に単純な役に立たない信号を提供します。
はい、イベントを使用できますが!!!カスタムイベントを使用して、ウィジェットごとに新しいクラスを作成します。これは大きな効率の損失です。
- カスタマイズされた各ウィジェットオブジェクトイベントを書き換えましたが、小さな変更があります。
- Qt Designerのものがすべて失われます。カスタムイベントですべてのウィジェットを宣伝する必要があります。
- プロジェクトが大きくなり、維持が困難になった。
- このためqtが嫌いになりました。そして、.netがデリゲートを提供する方法、それがシグナルスロットよりもはるかに優れている方法、.netコンポーネント（ウィジェット）が一般に想像できるすべてのイベントを提供する方法について話し始めます。や。。など。
私の大学の1つは、シグナル以外のイベントを使用する必要があったため、コンボボックスウィジェットごとに新しいコンボボックスクラスを作成しました。実話...
ただし、Qtはこれまでのところ最高と最高のC++ UIフレームワークです。
私はQtが本当に好きですが、多くのアプリケーションにとっては少し重いです。時には、あなたはそのレベルの複雑さを必要としません。 Qtのオーバーヘッドのないシンプルなものが必要な場合もあります。すべてのアプリケーションがイベント駆動型である必要はなく、C++は適切なテンプレートのセットを提供します。 Boostは別の非常に優れたセットを提供し、QTが行う多くの低レベルの機能（ファイル、ソケット、マネージポインターなど）を含みます。
他のアプリケーションには、GPL、LGPL、またはQtの商用ライセンスでは適切に機能しないライセンス要件があります。 GPLは商用ソフトウェアには不適切です。 LGPLは静的にリンクされたソフトウェアには不適切であり、商用ライセンスには費用がかかります。
Qtのような複雑なライブラリを許可しないセキュリティまたは安定性の考慮事項があるものもあります。
ソースを前処理するにはmocを実行する必要があります。これは大きな問題ではありませんが、新しいユーザーにとっては困難な場合があります。多くのプログラマーは、Qtでqmakeを使用するためにneedだと思っていますが、それは誤称です。 Qtを他のビルドシステムに簡単にプラグインすることができます。
一部のターゲットは、非常にメモリまたはCPUに制約があります。
そこにはいくつかのプラットフォーム固有の落とし穴があります。それらの落とし穴のほとんどは文書化されていません。十分に大きなアプリケーションを構築すると、それらに遭遇して何が起こっているのか疑問に思います（免責事項、私が怒りの中で最後にQtを使用したのは18か月以上前だったため、改善された可能性があります）。
C++のみです。他の言語バインディングも存在しますが、Qtに必要な多くの機能を非表示にするか、ほとんど公開しない傾向があります。
Qtを使用しない理由はたくさんあります。そのため、代替手段があります。あなたが持っているすべてがハンマーであるならば、すべての問題は釘のように見えます。
実際の理由は技術的なものではありません。
人はたまたま違う。彼らの選択もそうです。均一性は人間の特徴ではありません。