プログラマーとしての副業として、C++ でオーディオ ファイルをさまざまな形式に変換するプログラムを作成する予定です。おそらく、これには単純な GUI の構築が含まれます。
Qt や GTK などのクロスプラットフォーム ツールキットの代わりに、Cocoa と WinForms を使用して Mac と Windows 用の個別の GUI を構築するのは大変なことでしょうか?
(とにかく、Windows 版と Mac 版を別々に維持する必要があります)
GUI はおそらく非常に単純で、非常に基本的な機能のみが必要です。
ネイティブ GUI は、クロスプラットフォームの GUI よりもはるかに直感的であると常に感じていました...
専門知識がある場合は、ネイティブ フロントエンドを使用すると、UI に必要な作業が事実上 2 倍になりますが、私の経験からすると、非ネイティブ UI はネイティブ UI よりも少し扱いにくいものです。
wxWidgetsを見たことがありますか？クロスプラットフォームのネイティブコントロール。
クロスプラットフォームのツールキットは、多かれ少なかれ、プラットフォーム間の違いはボタンの配置とウィジェットのスタイルの問題であるという誤った仮定をしています。場合によっては、これを回避することができます-Qtアプリは、Windows（UI規則が非常に緩い）とLinux、特にKDE環境の両方でかなりネイティブに感じられます。一般に、LinuxとWindowsの間を比較的簡単に移動できます。規則は似ており、Windowsコミュニティはそれらについて緩いです。
Macは難しいものです。そのUIは、WindowsまたはほとんどのLinux環境とはまったく異なるパラダイムに基づいて構築されています。
ただし、一般的に、ネイティブアプリでは、ウィジェットスタイルだけでなく、プラットフォームの母国語をより多くの方法で話す方が簡単です。
可能であれば、ネイティブフロントエンドが進むべき道であることに同意します。私は最近wxWidgetsを使用しておらず、長い道のりを歩んでいると聞きましたが、wxWindowsの頃、X/Motifでビルドするように仕様が定められたアプリをビルドしました。私たちが努力を終えて納品したとき、顧客はそれがX / Motifのように十分に見えず、私たちの費用でUI全体を作り直さなければならなかったと言いました... Joel Spolskyはこれについて良い記事を書きましたが、私はできますタイトルを覚えていません。彼が言ったこと、IIRCは、Javaの問題であり、他のクロスプラットフォームUIは、「あなたの犬が私のアプリに吠える」ということでした。
このための独自のクロス プラットフォーム アプリケーション GUI レイヤーをすぐに作成する予定です。アプリケーションの複雑さによっては、これは QT、GTK、または FOX に必要なもののほんの一部である可能性があります。
その理由は、プラットフォーム ベンダー (最初に Apple) がシステムをユニークに見えるように設計しようとする傾向があるためです。これにより、QT、GTK、FOX、およびその他のプラットフォーム ツールが最新のウィジェットと常に同期し続けることが非常に困難になります。
基盤となる手法がますます同じになると、OS ベンダーは、プラットフォームのルック アンド フィールをブランディングする以外に選択肢がなくなります。
はい。
しかし、真剣に、それはあなたの目標に依存します. ネイティブ UI ライブラリに多大な労力を注ぐことで、はるかに優れた結果が得られることに同意しますが、多くのアプリでは非常に基本的な UI で十分であり、既存のクロス プラットフォーム フレームワークの 1 つを使用すれば労力は大幅に軽減されます。 .
おそらく、CLI から始めて機能を動作させることが、オーディオ変換アプリケーションにとって最も理にかなっています。