クロスプラットフォームGUIツールキットの傾向はありますか？
cross-platform GUIフレームワークの現在の使用傾向はどのようなものですか？より多くの人々がクロスプラットフォームフレームワーク（GTK +、Qt、wxWidgetsなど）を使い始めていますか、それともより多くのプラットフォーム関連フレームワーク（CocoaやWPFなど）を使う人がいますか？それは多かれ少なかれ停滞していますか？それはジェットコースターのようなものですか？ 5年後のトレンドはどうなると思いますか？
Windowsを使用する人が少なくなるにつれて、OSの状況は変化しています（個人的な観察）。これにより、クロスプラットフォームツールキットの需要が増えるはずです。
編集：また、成長している（クロスプラットフォームの）ツールキットはどれですか？
クロスプラットフォームキットに対する傾向があるようです。人々が一度書いてどこでも走ろうとするなら、彼らはHTMLを使う傾向がある-ウェブサイトを作る。たとえば、iPhoneなど、ネイティブのルックアンドフィールが強く求められる場合にのみ、プラットフォームツールキットを使用します。したがって、Web以外のアプリに悩むすべての理由がネイティブのルックアンドフィールを取得することである場合、クロスプラットフォームキットを使用してもそれほど意味がありません。
クロスプラットフォームツールキットがこれほどうまく機能したことはありません。デスクトッププラットフォームはそれほど類似していないため、それらを本当に抽象化することは困難です。ミックスに電話とタブレットを追加すると、さらに難しくなります。あなたは非常に漏れやすい抽象化に終わります（ http://www.joelonsoftware.com/articles/LeakyAbstractions.html を参照してください）。多くの場合、「エンジン」をUIから適切に分離し、プラットフォームごとに個別にUIを記述する方が簡単です。
Macの人気が高まる傾向により、クロスプラットフォームキットの人気が高まるのではなく、低くなる可能性があります。多くの場合、すべてのプラットフォームで本当に良い結果を得るよりも、理論的にはクロスプラットフォームチェックボックスをチェックするためにクロスプラットフォームキットを使用した方が多いと思います。実際に複数のプラットフォームを気にしたら、クロスプラットフォームキットの欠点を確認し始めます。
これらの欠点に関するAlex Payneのブログ投稿は次のとおりです。 http://al3x.net/2011/01/15/user-hostile-platforms.html
大規模で人気のあるクロスプラットフォームアプリの多くがownクロスプラットフォームアプローチ（Firefox、Chrome、Eclipse、OpenOffice.org）を発明していることを示していると思います頭に浮かぶ例です）。フレームワークを所有することで、必要に応じて抽象化をパンチダウンできます。また、これらのアプリはすべて、すべてのプラットフォームで同じように見える（特にネイティブではない）傾向があります。
このすべてが言った、私は実際の統計や何かを持っていません。しかし、私はGTK +で多くの作業を行い、Firefox、Chrome、Eclipseを含むコードベースにある程度精通しています。だから私はここで直接技術的な課題を見てきました。
実際、近年、クロスプラットフォームのUIツールキットに向かう傾向があります。そのツールキットはHTML/CSS/JavaScriptです。
一度開発すると、どこでもほぼ同じように実行できるので、非常に簡単です。
そしてはい、開発はデスクトップからWebに大規模に移行しています。あなた自身でそれを見る。
私はクロスプラットフォームツールキットを使用する傾向があります。それは、私がクロスプラットフォームになりたいからではなく、デザインが優れているからです。たとえば、Windowsプラットフォームのみを対象とするC++で書かれたプロジェクトに取り組んでいます。 win32またはMFCを使用しますか？ネイティブツールキットで使用できるオプションはほとんどありますか？
なんてこった！彼らは私が今まで見た中でスパゲッティのゴミのほとんど最悪の山です！イベントシステムと基盤となるOSの「メッセージ」システムを直接結合することは、信じられないほど直感的ではなく、UIプログラムを迅速に作成するために必要な表現力に欠けています。より高いレベルの抽象化は、現在クロスプラットフォームのツールキットによってのみ提供されており、タスクに絶対不可欠です。
これも一例です。クロスプラットフォームのツールキットを使用するほうがよいことのリストに、私はがらがらとなるかもしれません。実際のところ、グラフィカルインターフェイスは、明確なものというよりも、互いに類似しています。たとえば、Windows上のウィンドウプログラムとLinux上のウィンドウプログラムの違いはほとんどありません。 UIプログラムを作成するときに行うことの種類は、対象とするOSに関係なくほぼ同じです...そして電話/ Palmとデスクトップのようなアーキテクチャ間のわずかな違いのみです。この分野は、a）多くの人にとって必要であり、b）すべて同じであるので、単にクロスプラットフォームの方法論に焦点を合わせてきました。
クロスプラットフォームフレームワークを作成することに対する1つの議論は、フレームワークのクライアントは常に最低限の共通点をターゲットとすることです-フレームワークのクライアントは1回だけコードを記述し、サポートされている「どこでも」実行する必要があるということです。したがって、プラットフォーム固有の機能を利用できないため、1つの素晴らしいハードウェアプラットフォームは、そのフレームワークを実行する他のプラットフォームと同じように見えます。
時間が経つにつれ、残念ながら最も人気のあるプラットフォームに傾いたフレームワークになり、他のプラットフォームのサポートをハッキングしたり、予算や人気がなくなったときにそれらを取り除いたりしてしまいます。
プラットフォーム固有の機能を利用する1つの方法は、#if PLATFORM_FEATURE_Xすべての特定のコードまたは同等のランタイムチェックの周りに構成し、コードの膨張を引き起こします。同じプラットフォームのバリアントには特定の処理が必要になるため、これは非常に手間がかかります。たとえば、一部のXBox v1にはハードドライブがなかったため、クロスプラットフォームツールを使用するゲームは、ハードドライブを保証できるPCバージョンと比較して、キャッシュにそれを使用できませんでした。
デスクトップ/生産性アプリケーションでは、プラットフォームのルックアンドフィールが重要であるように見えますが、多くのアプリケーションには独自のスタイルがあるため、すべてのプラットフォームで同じに見えることは問題ありません。 AIRで構築されたアプリ。
Apple、Sony、Nintendo、Toshibaなどのハードウェアベンダーは、自社製品が競合他社との差別化を図ることを望んでいます。タッチ、加速度計/グライオスコープ、ブルーレイ、3Dディスプレイ。 （コストと複雑さのために）すべての競合他社のすべての機能が1つに統合されたプラットフォームが存在する可能性は低いため、1つが勝つでしょう。