11

私はVisual Studio、winformsでアプリケーションを作成していて、openTKを使用しています。最近、クロスプラットフォームにすることを考えました。他に似たようなものを知らないので、Mono を使用します。そして、私はGTK +の経験がまったくありません。私のアプリケーションでは、現在 4 つのウィンドウがあります (もちろん、将来的にはさらに増える予定です)。Windows、Linux、OS X でアプリケーションを高速化したい。では、GTK+ 用にすべてを作り直す必要がありますか、それとも WinForms のままにしておく必要がありますか? また、私のためにこの作業を行うツールはありますか?

4

3 に答える 3

16

正直なところ、優れた回答を提供するには、オーディエンス/対象市場について詳しく説明する必要がありますが、そこでの開発経験から得た私の $0.02 は、デスクトップでの Mono の GUI 開発は、必要に応じて複数のターゲットに対応するものであるということです。 「正しく」行うこと。共有バックエンドを例外的にモジュール化して開発し、プラットフォームごとに 1 回 UI を記述する必要があります。

ウィンドウズ

Mono に実装されている Windows.Forms は、アプリが初期段階にある場合に非常に役立ちます。これにより、すぐに Windows をターゲットにして、OS X と Linux にやや不自由な方法で展開できます。ただし、IRC で、Mono での Windows.Forms の開発は基本的に終了していると聞いたことに注意してください。古いバグは更新されず、たとえば、テストの数分以内に、OS X の RichTextBox で SelectionBackColor が機能しないことに遭遇しました (これは、Mono が OS X の Windows.Forms に使用するライブラリの問題です)。そこにあるということはきちんとしていて、おそらく、その制限を回避してコーディングできるクイックユーティリティに適しています (例については、こちらの質問を参照してください)。

OS X

OS X を対象とする場合、実際の商用のエンドユーザー アプリがある場合は、 Interface Builderとのインターフェイスに慣れる必要があります。 ここで、XCode と Interface Builder を使用するには、OS X を実行しているボックスにアクセスできることが絶対に必要であることを明確にしておく必要があり ます。

Xamarin は、XCode に組み込まれたネイティブ UI への IDE スタブ アウト接続を作成するという素晴らしい仕事をしました。それは彼らが iOS 開発でも行う方法です。ドキュメントは弱いですが、かなりうまく機能します。2011 年に Michael Hutchingson がこのプロセスを説明している素晴らしいビデオがありますが、私はそれが長くなりつつあると思います (つまり、「古い」)。（動画への直リンク）

Mac App Store をターゲットにしたい場合は、Interface Builder が唯一の現実的な選択肢でもあると思います。しかし見てください、これは C# コードにスタブ化されたネイティブ UI です。

Linux

私は実際に Linux をターゲットにしたわけではありません。Gtk# が自然に適合するように思えますが、私はあまり実践的な支援を行っていません。私のものは Windows.Forms でビルドされますが、OS X と同じようにラフなエッジがあります。もっと真剣に考えるなら、Gtk# から始めます。MonoDevelop には GUI RAD もあります。

本格的で成熟したクロスプラットフォーム Gtk# アプリの例

クイック ノート: BansheeはGtk#を使用して、OS X、Windows (アルファ)、および Linux をターゲットにしています。Gtk# のメーリング リストやその他のリソースをチェックすることで、大規模なアプリケーションのクロスプラットフォームで Gtk# を使用することがいかに難しいかについての優れたコンテキストを得ることができます。

申し訳ありませんが、ニュースはこれ以上簡単ではありません。特効薬/単一の正解はありません。

201607 更新: Xamarin.Forms を使用してクロスプラットフォームをターゲットにすることが、答えになりつつあると思います。今のところ、別の Mac インターフェイスを作成するのにまだ行き詰っているかもしれませんが、いつか Xamarin.Forms もサポートされると信じる理由があります。下記参照。

残念ながら、Linux をターゲットにしている場合は、今のところ以前と同じボートに乗っていると思います。

  • Windows: Xamarin.Forms と UWP を使用できるようになりました。
  • macOS: 基本的には同じ場所にいますが、先週末、Xamarin の従業員から、Xamarin.Forms が OS X 向けに非公式に開発中であると教えてもらいました。これは GitHub のリポジトリだと思います。(tvOS 用のブランチもあります。)
于 2013-04-28T14:27:36.783 に答える
10

ターゲットオーディエンスが何であるかを検討することをお勧めします。GTK# のようなフレームワークを使用して UI を記述することは良い考えのように思えるかもしれませんが、平均的なユーザーにとって、アプリケーションは他の Windows/OSX アプリケーションのようには見えず、簡単に使用をやめてしまう可能性があります (他の方法で本当に例外的でない限り)。

これを行う最善の方法 (時間/予算の制約により不可能な場合があります) は、アプリケーション ロジックを別のアセンブリに配置し、Windows では Winform (または WPF)、Windows ではMonoMac /Cocoa を使用して、プラットフォームごとに UI を記述することです。 Linux 用の OSX および GTK#。また、ユーザー エクスペリエンスを大幅に低下させるすべてのプラットフォームで利用可能な機能の使用を制限することもありません。

于 2013-04-28T18:41:17.730 に答える
1

私は今、同様の問題に直面していますが、アプリケーション ロジックを分離しておくことについて Karl-Johan が言ったことは、タスクをはるかに簡単にしてくれます。ViewModel パターン (MVVM) を調べると、中央のロジックが UI にとらわれなくなるため、プラットフォームごとに書き直してテストするコードがはるかに少なくなります。

于 2013-08-08T19:15:13.620 に答える