12

重複の可能性:
Gui ツールキット、どちらを使用すればよいですか?

私はかなりの C/C++ の経験を持っています - 主に Windows/Linux 用のコンソール アプリケーションを書くためのもので、C# の経験もかなりあります - 通常は WinForms アプリケーションなどを書くためのものです。

たとえば、次のような単純なものなど、.netでウィンドウを簡単に作成できることに非常に感銘を受けました

Form form = new Form();
form.ShowDialog();

画面に空白のフォームを表示するには十分です。実際には、

new Form().ShowDialog();

フォームが閉じられた後にフォームへの参照が失われることを気にしない限り、技術的には十分です。

を使用して C++ でいくつかの Windows ベースの GUI を記述しようとしましたwindows.hが、学習曲線が少し急勾配に見えるだけでなく、構文が非常に冗長です。上記の単一行の .net 実装のような単純なウィンドウを作成すると、.net を使用して簡単に 20 行を超えることができますwindows.h。

それだけでなく、アプリケーションを Linux/Max に移植する場合 (mono などのハックを除いて、.net ではほとんどできないことです)、アプリケーションの 95% を書き直す必要があります。 GUI コード。

これが、QT などのフレームワークの出番であると想定しています (残念ながら、GUI フレームワークについてはあまり知りません)。

推奨する GUI フレームワークは何ですか? どれが最も強力で、どれが最も使いやすいですか? C/C++ で GUI をコーディングするタスクに通常どのように取り組んでいますか?

4

2 に答える 2

5

プログラミングしている金属 (いわば) に近づくほど、難しくなります。WinForms (.NET Framework によって提供される) は、Win32 API よりもかなり優れた抽象化であり、ウィンドウを画面に表示するなど、最も単純なタスクでさえ複雑であることを考慮してください。もちろん、これらすべてはまだバックグラウンドで行われています (ウィンドウ クラスの登録、ウィンドウの作成など)。自分でコードを記述する必要はありません。

Mono を「ハック」と書き留めて、Qt のようなライブラリを検討するのは興味深いことです。何を基準に区別しているのか、よくわかりません。Mono ライブラリは、WinForms のサポートに関しては優れていると広く見なされています。最大の批判者は、Microsoft 自身の CLR 実装と同じです。つまり、真のネイティブコードを生成しないということです。これは、ほとんどの状況で、思ったよりもパフォーマンスに関係がありません。さらに、Mono アプリケーションがプラットフォームの UI ガイドラインに完全に準拠していない (つまり、ネイティブ アプリケーションとまったく同じように見えず、動作しない) という不満もありますが、Qt を使用して作成されたアプリケーションについても同様の不満があります。

C++ で GUI 作業を行いたい場合、文字通り誰もが Qt を使用することを推奨しているようです。上で述べたように、私はあなたが現在実行しているプラ​​ットフォームによって提供される完全にネイティブなコントロールとウィジェットを使用することに固執しているため、私のお気に入りのライブラリではありません。Qt が最近この点で少し良くなったことは理解していますが、それでも私の基準には達していないと思います。あなたが私よりも柔軟で (平均的な Mac ユーザーは私ほど柔軟ではないことを警告しておきます)、真のプラットフォームの独立性があなたにとって大きな関心事である場合は、おそらくそれを選択する必要があります。 . 多くの人がそのデザインの優雅さと便利さを称賛していますが、それでも .NET Framework の実装と同じ単純さを提供しているとは思えません。

コードの単純さと簡潔さが質問の冒頭で聞こえるほど重要である場合は、C# と WinForms を使用することを強くお勧めします。抽象化のレイヤーを削除し始めると、事態は難しくなります。そうすることで得られる追加レベルの制御が必要ない場合は、自分でさらに作業を行う正当な理由はほとんどありません。Mono の Forms 実装は、クロスプラットフォーム アプリケーションの完全に実行可能なソリューションであり、ニーズが比較的控えめであると仮定します。

それ以上に、C++ で真のクロスプラットフォーム アプリケーションを正しい方法で作成したい場合は、データ レイヤー コードを UI レイヤーから厳密に分離し、必要な各プラットフォームが提供するツールを使用して UI を作成することをお勧めします。サポート。Windows では、選択肢は比較的オープンです。.NET WinForms は堅実な選択肢です。ネイティブの Win32 は、メリットはあるものの多少面倒です。MFC や WxWidgets などの他のいくつかのライブラリは、完全なネイティブ プログラミングの苦痛を和らげるのに役立ちます (ただし、そうではありません)。 WinForms とほぼ同じです)。Mac では、Cocoa フレームワークを対象とする Xcode、Interface Builder、および Objective-C が唯一の現実的なオプションです。Linux/Unix ベースのシステムはほとんど私の得意分野ですが、Qt は可能な限りネイティブなライブラリであることを理解しています。これは私が思っているよりも手間がかかるように思えます。適切に設計されたライブラリは作業の 80% を処理し、UI の実装に必要な作業は約 20% しか残らないはずです。真にネイティブなコントロールとウィジェットを使用する以外に、このアプローチによって得られるもう 1 つの大きな利点は柔軟性だと思います。Windows と Mac では、Microsoft Word の外観が (表面的な類似点はあるものの) 非常に異なっていることに注意してください。また、iTunes は Mac プラットフォームでは優れた UI デザインの模範と言えるほどになっていますが、Windows では目立たないようになっています。一方、Mac で Windows Media Player のようなものを展開した場合 (そして、Microsoft 自身が試してみましたが、あまり成功していません)、Mac ユーザーは、これを完全な忌み嫌うものとして片付け、おそらくあなたが試したことにいくらか気分を害するでしょう。真にクロスプラットフォーム志向の開発者にとってはあまり良くありません。言うまでもなく、アプリが最も単純なユーティリティではない場合、おそらくサポートする各プラットフォームでは、まったく異なるインターフェイスが正当化されます (さらには期待されます)。
Qt がどんなに優れていても、それを実現することはできません。

于 2011-02-21T03:25:54.257 に答える
3

Qt、手を下します。

これは、入手可能な最も完全で、最も成熟した、最速のフレームワークです。その上、真剣にマルチプラットフォームであり、商業的に使いやすいオープン ソースまたは有料サポートを選択できます。

于 2011-02-21T03:18:53.483 に答える