Zitat Zitat von ChEeTaH182 Beitrag anzeigen
Eto.Forms:
[+] Bestes aussehen, gut strukturiert.
[+] relativ leichtgewichtig
[+] eine lib pro Plattform
Ebenfalls mein Favorit hier.


Zitat Zitat von ChEeTaH182 Beitrag anzeigen
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 Beitrag anzeigen
Gtk#:
[-] GUI ist nicht die schönste
Selbiges wie bei QT.


Zitat Zitat von ChEeTaH182 Beitrag anzeigen
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.