Cross-Platform GUI aus bestehendem WinForms-Projekt

Hallo 😃

Ich hoffe, dass ich hier im Unterforum richtig bin auch wenn es eigentlich um** Alternativen **zu Windows Forms geht ...

Ich habe ein bestehendes Projekt, in dem mittlerweile viel Arbeit drin steckt, grob gesagt so ziemlich alle Zeit, die mir in den vergangenen 12 Monaten neben dem Studium so geblieben ist ..
Es handelt sich um eine Art von DAW (Digital Audio Workstation) u.a. mit graphischem Editor für Musikspuren und (vereinfacht gesagt) anderen Formen von graphischen Editoren in denen der Benutzer Abläufe "zeichnen" kann, statt sie in Textform einzutippen ..
Das ganze besteht zum größten Teil aus WinForms-Elementen wie PictureBoxen, Paneln und selbsterstellten Komponenten, die bewegt und in ihrer Größe und Optik verändert werden, ein typischer Spureneditor eben. Der größte Teil der Funktionalität ist in den GUI-Elementen selbst realisiert (Beispiel: ein Element auf einer Audiospur berechnet anhand seiner Größe die auf dem Element angezeigte Waveform-Bitmap selbst und stellt diese dar). Sollte das nicht die eleganteste Methode sein, so etwas zu realisieren bitte ich um Hinweis, es war bis hier hin verdächtig einfach und intuitiv 😃

Zu meinem Hintergrund: Ich studiere Elektrotechnik und habe mich schon vorher mit C# beschäftigt (nur Konsole oder WinForms, immer auf Windows). Aus dem Studium kann ich zwar etwas C/C++, python und MATLAB, ersteres hat mich allerdings bisher immer nur abgeschreckt und letzteres ist definitiv nicht das, was ich brauche. Kurz gesagt: ich mag C#/.NET und würde gern dabei bleiben.

Das eigentliche Problem:
Da viele der Freunde, die mein Programm gerne nutzen würden und mir wertvolles Feedback geben könnten allerdings überzeugte Mac-Nutzer sind (so wie außerdem überproportional vieles im DAW/Multimedia-Bereich über Apple läuft), würde ich gerne die Zeit investieren meinen Code auch auf OSX lauffähig zu machen, zur Not mein komplettes Projekt neu aufzurollen.

Die Suche nach Cross-Platform-GUI-Frameworks liefert zwar einige Ergebnisse, jedoch scheinen viele GUI-Frameworks veraltet und verlassen und scheinen schlicht grottenschlecht dokumentiert. Und ich gebe zu, aus meiner heilen Welt der WinForms-Entwicklung in VS heraus, komme ich mir da auch etwas überfordert vor.

Um zu den wichtigen Dingen zu kommen, was will ich überhaupt?
-> Ein plattformunabhängiges Programm mit GUI für Windows und Mac in C# auf meinem Windows-Rechner schreiben, dieses für Windows und OSX erstellen und (mit so wenigen Anpassungen wie möglich) auf einem Mac zum laufen kriegen.
Ich bin gerne bereit, mich in neue Dinge einzuarbeiten und freue mich auch darauf.
Wenn das ganze aber komplett neu aufrolle, will ich dass es am Ende auch mit vertretbarem Aufwand funktioniert und frage lieber vorher nach worein ich meine Zeit investiere. (vertretbarer Aufwand ist für mich eigentlich alles was schneller ist als das Programm für beide Betriebssysteme komplett nativ selbst zu schreiben)
Es geht nicht darum, die Funktionalität von der GUI zu trennen und dann eine plattformabhängige GUI zu schreiben, die diese aufruft. Die Hauptfunktionalität steckt ja leider in der GUI. Eher geht es darum, diese Elemente und Bausteine plattformunabhängig neu zu entwerfen und sie in einer GUI zu nutzen, dafür suche ich geeignete Werkzeuge.

Über Links zu Tutorials, Einführungen oder Buchempfehlungen würde ich mich ebenfalls sehr freuen.

Viele Grüße 😃

PS: Nicht nur die GUI macht Probleme bei der Portierung, ich nutze außerdem einen Multimedia Timer, der den Win32 Multimedia Timer wrapt und die SerialPort-Klasse zur Kommunikation mit einem Arduino .. werde ich Äquivalente für die Mac-Version finden?

Wenn Du wirklich eine plattformunabhängige UI willst, dann ist HTML5 derzeit alternativlos.
Und das wird auf absehbare Zeit auch so bleiben. Es gibt derzeit technologieübergreifend keine Möglichkeit, für alle drei relevanten Betriebssysteme ein und die selbe 10000% UI Technologie auf Desktop-Basis umzusetzen (außer eben HTML).

Bzeüglich Plattform-Features kannst Du Dich am .NET Standard orientieren.
Dieser bietet Schnittstellen, die alle unterstützten OS ebenfalls können.

Spezifische Features - zB. Windows Registry, die es unter Linux halt nicht gibt - für ein OS muss dann spezifisch implementiert werden. Das gilt für fast alle Win32 Schnittstellen.
Du kannst Dir das hier wie ein OOP Interface vorstellen: Du gibst ein Interface vor, das dann pro OS individuell implementiert werden muss.

Da musst Du dann eben aus Application Lifecycle-Sicht pro Betriebssystem andere Pakete mitliefern.
Das ist heute schon Gang und Gebe und im Prinzip ebenfalls "alternativlos".

Bezüglich des Beispiels mit MultimediaTimer:
Die Unterstützung in einer Basis ist das eine, die sinnvolle Verwendung die andere.
Selten hab ich den Multimedia-Timer sinnvoll im Einsatz gesehen. Beispiel: Eine Auflösung von 1ms ist nichts anderes, als sich selbst anzulügen.
Eine 1ms Auflösung eines Timers gibt es unter einen Nicht-Echtzeit-Betriebssystem nicht.
Die Frage ist also bei solchen Dingen dann: was tust Du überhaupt genau und ist es so überhaupt sinngemäß im Einsatz, damit man dann eine sinnvolle Lösung finden kann.
Timer am Serialport riecht ohnehin schon etwas "schmutzig".

Vielen Dank schonmal für die Antwort!

Es gibt derzeit technologieübergreifend keine Möglichkeit, für alle drei relevanten Betriebssysteme ein und die selbe 10000% UI Technologie auf Desktop-Basis umzusetzen (außer eben HTML).

Ich bin immer wieder über Frameworks gestolpert (Eto.Forms z.B.), die angeben, die nativen UI-Elemente des jeweiligen OS einzubinden und zu wrappen. Dass das nicht über die selbe native UI-Technologie funktioniert leuchtet ein, ich dachte dabei eher an so etwas ..

Du gibst ein Interface vor, das dann pro OS individuell implementiert werden muss.

Hast du eventuell ein paar gute Links da, die mir eine Einführung in die Programmierung mit GUI in dieser Form geben könnten und mir den Einstieg erleichtern.

Zum Timer und dem SerialPort:
Zur Musik wird Hardware angesteuert, die Komposition dieser Steuerung (in 10ms-Schritten gesamplet) übernimmt das Programm. Es gehen also alle 10ms bestimmte Steuerbefehle (2 Byte) über den SerialPort zum Arduino.
Dass ein genaues Timing in einem nicht-RT-OS nicht möglich ist weiß ich.
Es kommt jedoch nicht darauf an, ob das Senden der Daten nun 0ms oder 2ms Jitter aufweist, da das für den Beobachter im Endeffekt nicht sichtbar ist, das bestätigt auch die seit Monaten laufende Praxis mit dem System.

Klar, solche Halbansätze wie Eto.Forms gibt es wie Sand am Meer. Die gibts quasi jeden Tag nen neues Open Source Framework in die Richtung und jeden Tag stirbt auch eines.

Und natürlich gibt es auch "höherwertige" unabhängige Bibliotheken wie dann GTK+ oder Cute (Qt). Aber so wirklich UI-unabhängig sind sie dann am Ende doch nicht zu 1000%.
Da gibt es immer Punkte, die dann spezifisch anders sind.
Am Nähesten ist dann doch Java mit SWT oder FX (oder nun Decora); dessen Grenzen dann aber auch bekannt sind, sobald was spezifisches vom Betriebssystem gebraucht, dargestellt oder angesprochen wird und teilweise auch HTML als Deklaration verwendet.

Zum Timer: 10ms stabile Auflösung ist trotzdem unsicher.
Zudem gibt es ein Limit von MultimediaTimern unter Windows, weswegen die Nutzung parallel zu anderer Software, die Multimedia Timer (unbewusst) nutzt, problematisch sein kann.

Hast du eventuell ein paar gute Links da

Ein Link genau zu der Frage kann ich leider nicht alá FF aus dem Ärmel schütteln.
Läuft dann aber ganz abstrakt auf eine Plugin-ähnliche Architektur hinaus.

Am Ehesten deckt vermutlich dann wirklich Java Deine Anforderung ab, da Du vermutlich nicht in die Dinge laufen wirst, die bei Java dann wieder spezifisch sein würden.
Im Bereich .NET Standard ist diese Story erst mit dem XAML Standard am Anfang.

Meine Recherchen nebenbei haben mich auch immer mehr in Richtung Java und JavaFX getrieben. Und die Bilder von Netbeans sehen zugegebenermaßen auch ganz hübsch aus .. (Eclipse habe ich im Studium hassen gelernt).

Ich werde mir das Ganze mal anschauen, beginnen die kritischsten, wichtigsten Klassen und UI-Elemente zu designen und dann mal sehen wie es mir liegt.
Bei einem Wechsel scheint Java ohnehin der einzig vertretbare Kompromiss, die Unterschiede sind hoffe ich nicht so hart zu überwinden.

Zudem gibt es ein Limit von MultimediaTimern unter Windows, weswegen die Nutzung parallel zu anderer Software, die Multimedia Timer (unbewusst) nutzt, problematisch sein kann.

Das ist interessant zu wissen .. 😃

Viele Grüße

Java ist ähnlich; ich würde aber trotzdem den .NET Stack mit HTML bevorzugen bzw. direkt TypeScript mit HTML verwenden (zB mit Hilfe von NativeScript oder Cordova).

Zur Orginalfrage, Scott Hanselman hat dazu erst vor 3 Wochen was gepostet.
https://www.hanselman.com/blog/WhatWouldACrossplatformNETUIFrameworkLookLikeExploringAvalonia.aspx

Avalonia mag für so ein kleines Projekt wie hier wirklich eine Option sein; man muss aber bedenken, dass Avalonia auch "schon" über zwei Jahre im Alpha Stadium ist.

Als Einschränkung für Xamarin unter Windows gilt aber, daß es nur UWP unterstützt, also nur unter Windows 10 läuft - ansonsten hätte ich Xamarin auch sofort vorgeschlagen (für reine Desktop-Programme würde ich es aber (derzeit trotzdem) nicht verwenden).
Explizit für Windows und Mac würde ich daher noch GTK# vorschlagen (welches auch von den Xamarin-Entwicklern entwickelt wurde und auf GTK+ beruht) - auch wenn man sich der Probleme von Mono bewußt sein sollte.