.NET GUI Frameworks für Windows, Linux, Mac
Hallo zusammen,
ich versuche eine Anwendung zu schreiben, welche weitestgehend plattformunabhängig ist. Der Logik Teil ist dank .NET Core und Mono nicht das Problem.
Ich möchte nicht für jede Plattform eine eigene GUI schreiben, sondern wenn möglich die GUI weitestgehend wiederverwenden.
Folgende Frameworks habe ich gefunden:
Eto.Forms:
[+] Bestes aussehen, gut strukturiert.
[+] relativ leichtgewichtig
[+] eine lib pro Plattform
QTSharp:
[+] QT
[-] große dependencies?
Gtk#:
[-] GUI ist nicht die schönste
ChromiumFX + selber compilieren
[+] HTML5 GUI
[+] wohl am flexibelsten, was GUI Struktur angeht, da HTML5
[-] sehr große dependencies (Chromium)
[-] etwas umständlich um für Linux und Mac zu builden
Meine Präferenz liegt im Moment bei Eto.Forms und ChromiumFX, da HTML5 GUis einfach genial sind, allerdings ist das builden ein ziemliches Theater.
Ist jemand bereits auf das gleiche Problem / Entscheidung gestossen und kann mir eventuell einen Erfahrungsbericht geben? Womöglich hat sich ja jemand aus bestimmten Gründen für oder gegen ein Framework entschieden.
Viele Grüße
AW: .NET GUI Frameworks für Windows, Linux, Mac
Zitat:
Zitat von
ChEeTaH182
Eto.Forms:
[+] Bestes aussehen, gut strukturiert.
[+] relativ leichtgewichtig
[+] eine lib pro Plattform
Ebenfalls mein Favorit hier.
Zitat:
Zitat von
ChEeTaH182
QTSharp:
[+] QT
[-] große dependencies?
Bin ich leider nicht up2date, aber vor paar Jahren war noch kaum ein Unterschied zur Standard-GUI von Mono zu erkennen (außer dass die Kompatibilität besser war).
Zitat:
Zitat von
ChEeTaH182
Gtk#:
[-] GUI ist nicht die schönste
Selbiges wie bei QT.
Zitat:
Zitat von
ChEeTaH182
ChromiumFX + selber compilieren
[+] HTML5 GUI
[+] wohl am flexibelsten, was GUI Struktur angeht, da HTML5
[-] sehr große dependencies (Chromium)
[-] etwas umständlich um für Linux und Mac zu builden
Das umständliche Builden ist ein sehr großes KO-Kriterium. Vorallem im Prototyping. Eine normale Kompilierung für Android dauert bei mir zwischen 1 und 3 Minuten. Selbst das war mir beim Prototyping viel zu lang, weswegen ich dann zu einer auf Smalltalk basierende Technologie gewechselt bin. Du siehst also dass selbst die normalen Build-Umstände dich merkbar einschränken können. Daher würde ich es allein aus dem letzten Grund nicht verwenden. Dazu kommt noch dass bei der Darstellung der Elemente das Betriebssystem und Chromium arbeiten. Doppelte Arbeit also. Daher gibt es auch meistens ein kleines Flackern wenn ein neues "Fenster" geladen wird, da das Canvas erstmals leer angezeigt wird und erst nachdem es vom BS erstellt wurde Chromium darauf zeichnet. Du müsstest hier also auf Technologien von Hybridapps zurückgreifen, die alles über JS laden, so dass bei einem Wechsel der Ansicht kein Flackern durch das Löschen des Canvas entsteht. Heißt also dass sich das neue Fenster über das alte legt und das Alte erst wenn es nicht mehr sichtbar ist gelöscht wird.
Vorteil hier ist aber dass rein theoretisch möglich ist, schnelles Design-Prototyping - indem du einfach nur das HTML neu lädst, statt die App neu zu kompilieren - betreiben kannst.
