2013-04-27 2 views
10

Ich machte eine Anwendung mit Visual Studio, winforms und ich verwende openTK. Kürzlich habe ich darüber nachgedacht, es plattformübergreifend zu machen. Ich werde Mono benutzen, weil ich nichts anderes weiß. Und ich habe überhaupt keine Erfahrung mit GTK +. In meiner Anwendung gibt es derzeit 4 Fenster (natürlich wird es in Zukunft mehr geben). Ich möchte Anwendung in Windows, Linux und OS X schnell machen. Ich habe gelesen, dass GTK + besser als WinForms ist, aber immer noch nicht sicher, welche zu wählen. Also, sollte ich alles für GTK + neu machen oder bei WinForms bleiben und warum? Gibt es irgendein Werkzeug, das diese Arbeit für mich erledigen würde?Sollte ich GUI mit GTK + anstelle von WinForms für Mono umschreiben?

+0

möglich Duplikat von [WinForms vs GtkSharp mit Mono] (http://stackoverflow.com/questions/751884/winforms-vs-gtksharp-with-mono) –

+1

Mono gewinnt eine Menge Dynamik, vor allem mit .NET-Core 5 werfen ihre Unterstützung hinter sich. ASP.NET wird auch ein größerer Spieler als eine UI-Entwicklungsoption und wird gut mit Mono spielen. – VoteCoffee

+0

Nach dem Kampf mit WinForms kann ich Ihnen sagen, dass GTK + definitiv viel besser. Außerdem bietet jede GTK + geschriebene App die Möglichkeit, Dinge, die ein Programmierer nicht außer Kraft gesetzt hat, in einer separaten Datei zu konfigurieren. Z.B. Aktivieren Sie die Emacs-Bewegungstasten für jedes Text-Widget. –

Antwort

14

Ehrlich gesagt, müssen Sie uns mehr über Ihre Publikum/beabsichtigten Markt eine gute Antwort zu liefern, aber meine $ 0,02 aus Erfahrung dort Entwicklung ist, dass GUI-Entwicklung für Mono auf dem Desktop ist eine Multi Zielangelegenheit, wenn Sie es tun wollen "Richtig". Sie müssen das gemeinsam genutzte Back-End außergewöhnlich modular entwickeln und dann die Benutzeroberfläche einmal pro Plattform schreiben.

Windows-

Windows.Forms als auf Mono implementiert ist eine große Krücke, wenn Ihre App in den Kinderschuhen, so dass Sie Windows sofort und implementieren in einer etwas verkrüppelten Art und Weise auf OS X und Linux zum Ziel. Beachten Sie jedoch, dass mir im IRC mitgeteilt wurde, dass die Entwicklung von Windows.Forms auf Mono im Wesentlichen tot ist. Alte Bugs werden nicht aktualisiert, und ich habe beispielsweise festgestellt, dass SelectionBackColor in RichTextBox unter OS X nicht funktioniert (es ist ein Problem in einer Lib, die Mono für Windows.Forms unter OS X verwendet) innerhalb weniger Minuten nach dem Testen. Ordentlich, dass es dort ist, vielleicht gut für schnelle Dienstprogramme, in denen Sie seine Beschränkungen kodieren können (siehe Frage here für ein Beispiel).

OS X

Für OS X Targeting, wenn Sie einen echten, Handels-, Endbenutzers App haben, können Sie sich daran zu gewöhnen müssen werden, um, mit Interface Builder Schnittstelle. Ich sollte hier klarstellen, dass die Verwendung von XCode und Interface Builder erfordert unbedingt, dass Sie Zugriff auf eine Box mit OS X haben. Sonst stecken Sie mit Windows.Forms oder, vorzugsweise, denke ich, Gtk #.

Xamarin hat seine IDE-Stub-out-Verbindungen zu nativen UIs, die in XCode integriert sind, großartig gemacht. So machen sie es auch für die iOS-Entwicklung. Es funktioniert ziemlich gut, obwohl die Dokumentation schwach ist. Es gibt eine great video from 2011 from Michael Hutchingson describing this process, obwohl ich annehme, dass es lange im Zahn (dh, "alt") wird. (Direct link to video)

Ich nehme an, Interface Builder ist auch Ihre einzige echte Wahl, wenn Sie den Mac App Store zielen wollen. Aber schau, es ist eine native UI, die auf deinen C# -Code angewendet wird, was alles in allem ein großartiger Kompromiss ist.

Linux

Ich habe nicht wirklich Linux ausgerichtet. Scheint so, als wäre Gtk # ein natürlicher Anfall, aber ich bin nicht viel praktische Hilfe dort. Meine Sachen bauen sich in Windows.Forms auf, und es gibt Ecken und Kanten, genau wie in OS X. Wenn ich ernsthafter würde, würde ich mit Gtk # beginnen, und dort hat MonoDevelop auch seine GUI RAD.

Beispiel einer schweren, reifen, krossplattformischen Gtk # app

Schnell Anmerkung: Banshee verwendet Gtk# OS X, Windows (alpha) und Linux zum Ziel. Sie können einen guten Zusammenhang sehen, wie schwierig es ist, Gtk # auf einer großen Anwendung plattformübergreifend zu verwenden, indem Sie its mailing list und andere Ressourcen auschecken.

Entschuldigung die Nachrichten sind nicht einfacher. Es gibt keine Silberkugel/einzige richtige Antwort.


201607 UPDATE: Ich denke, die Antwort langsam plattformübergreifende Ziel wird immer Xamarin.Forms zu verwenden. Es kann sein, dass Sie noch immer an einem separaten Mac-Interface feststecken, aber es gibt Grund zu der Annahme, dass Xamarin.Forms auch irgendwann Unterstützung haben wird; siehe unten.

Leider, wenn Sie auf Linux abzielen, sind Sie, glaube ich, noch immer im selben Boot wie vorher.

  • Windows: Sie können jetzt Xamarin.Forms and UWP verwenden.
  • macOS: Sie sind immer noch im Wesentlichen an der gleichen Stelle, aber ich hatte einen Xamarin-Mitarbeiter, der mir am vergangenen Wochenende sagte, dass Xamarin.Forms inoffiziell in der Entwicklung für OS X ist. Ich glaube, this is the repo on GitHub. (Es gibt sogar einen Zweig für tvOS.)
+1

Vielen Dank für Ihre Erfahrungen. –

+0

Warum möchten Sie nicht JavaFX verwenden? Es unterstützt das Erstellen von plattformübergreifenden dynamischen GUIs. http://docs.oracle.com/javafx/ –

+0

@OlowookereEmmanuel Nun, das OP verwendet definitiv und vertraut mit einer Microsoft-Entwicklungsumgebung und fragte speziell nach GTK # vs. Mono. Obwohl sich Java und C# oft sehr ähnlich fühlen, würde der Wechsel von einem zum anderen auch einen ernsthaften Kopf-Thread erfordern und es würde Ihnen nicht erlauben, Bibliotheken einzusetzen, die in Ihrer Lieblingssprache geschrieben sind - hier C#. Allerdings könnte JavaFX eine interessante Alternative sein.Hoffe es ist besser als Swing war! ; ^) – ruffin

10

Ich würde vorschlagen, dass Sie überlegen, was Ihre Zielgruppe ist. Das Schreiben von UI mit einem Framework wie GTK # mag eine gute Idee sein, aber für den durchschnittlichen Benutzer wird Ihre Anwendung nicht wie ihre anderen Windows/OSX-Anwendungen aussehen, was Benutzer daran hindern kann, sie zu benutzen (es sei denn, sie ist wirklich außergewöhnlich).

Der beste Weg, dies zu tun (was aufgrund von Zeit-/Budgetbeschränkungen möglicherweise nicht möglich ist), besteht darin, Ihre Anwendungslogik in eine separate Assembly zu schreiben und dann UI für jede Plattform mit Winform (oder WPF) für Windows zu schreiben. MonoMac/Cocoa für OSX und GTK # für Linux. Es beschränkt Sie auch nicht auf die Verwendung von Funktionen, die auf allen Plattformen verfügbar sind und die Benutzerfreundlichkeit erheblich beeinträchtigen würden.

+2

+1 für die Erwähnung von WPF, welches IMO die einzig wahre Möglichkeit ist, eine seriöse Desktop-Benutzeroberfläche in Windows ab sofort zu erstellen. –

+0

Sekunde auf nativer Benutzeroberfläche. Wenn Sie keine native Benutzeroberfläche benötigen, warum nicht stattdessen als Web-/Browser-Anwendung? Jede moderne Plattform kann HTML und ist viel besser als GTK + unterstützt. – Mathieson

1

Ich stehe jetzt vor einem ähnlichen Problem - aber was Karl-Johan gesagt hat, die Anwendungslogik getrennt zu halten, wird die Aufgabe viel einfacher machen. Schauen Sie in ein ViewModel-Muster (MVVM), und Sie haben viel weniger Code zum Neuschreiben und Testen für jede Plattform, da die zentrale Logik unbenutzt wird.