Das Schreiben von GUI-Apps für Windows ist unerquicklich

 (tulach.cc)
8 Punkte von GN⁺ 2024-07-01 | 7 Kommentare | Auf WhatsApp teilen
  • Zusammenfassung der Ergebnisse einer Recherche und eines Vergleichs von Bibliotheken zum Erstellen von GUIs in C++
  • Grundanforderungen: nur Windows-Unterstützung erforderlich, kommerzielle Nutzung möglich, einfache Stilgestaltung inklusive Dark Mode, Erstellung einer einzelnen EXE-Datei unter 40 MB mit minimalen Abhängigkeiten, schnelle Entwicklung

WinUI 3

  • Wirkte anfangs wie eine hervorragende Wahl
  • Moderne Windows-Komponenten können verwendet und Stilfarben angepasst werden
  • Das Design kann mit XAML erstellt werden, und auch der Visual-Studio-Designer lässt sich direkt nutzen
  • Probleme:
    • Die Bereitstellung der App in nicht paketierter Form wird nur schlecht unterstützt
    • Beim Verschieben der App auf eine VM oder einen anderen Computer schlägt die Ausführung meist fehl
    • Es müssen viele .dll-Dateien mitgeliefert werden, die WinUI-Funktionen verarbeiten
    • Eine einzelne portable .exe-Datei kann nicht erstellt werden
    • Als Paket funktioniert es problemlos, wird aber als AppX-Paket installiert, wodurch Probleme beim Zugriff auf die Win32-API entstehen

Win32 / MFC / kleine Bibliotheken, die Win32 wrappen

  • Da hohe Portabilität benötigt wird, ist es sinnvoll, das native Rendering des Betriebssystems zu verwenden
  • Das Programm kann aus einer einzelnen .exe-Datei bestehen und sehr klein sein (bei statischem Linken von MFC)
  • Man kann eine minimalistischere Bibliothek verwenden, die jemand anderes bereits geschrieben hat
  • Probleme:
    • Das Stylen nativer Win32-Controls ist sehr schwierig
    • Für alle Controls müssen benutzerdefinierte Paint-Funktionen geschrieben werden
    • Es gibt einen „versteckten“ Dark Mode, wie er im Windows-Datei-Explorer verwendet wird, aber er umfasst nur einige Controls und sieht trotzdem nicht besonders gut aus

Qt

  • Der heilige Gral der C++-GUI
  • Komplex, aber mit Qt Style Sheets leicht zu stylen
  • Probleme:
    • Bei dynamischem Linken werden zahlreiche .dll-Dateien zum Ausführen der App benötigt, und die Größe liegt bei über 40 MB
    • Qt kann statisch ins Programm gelinkt werden, aber dann muss man es Open Source machen oder wegen der LGPL-Lizenz von Qt Objektdateien zur Neukompilierung verteilen
    • Alternativ kann man eine kommerzielle Lizenz kaufen, aber die kostet mehrere tausend Dollar

wxWidgets

  • Eine leicht zu erlernende Bibliothek
  • wxFormBuilder kann verwendet werden
  • Hat eine freizügigere Lizenz als Qt und kann statisch in eine 3-MB-Executable gelinkt werden
  • Probleme:
    • Unter Windows werden native Win32-Komponenten verwendet, ohne Styling-Optionen anzubieten
    • Unterstützt die Anwendung dunkler Controls wie im Windows-Datei-Explorer, aber das Ergebnis ist nicht besonders gut

hikogui

  • Eine neue GUI-Bibliothek im Retained-Mode mit Vulkan als Backend
  • Hat integrierten Dark Mode und lässt sich leicht stylen
  • Probleme:
    • Man braucht praktisch einen Doktortitel in Informatik, um sie erfolgreich zu kompilieren
    • Nach über 30 Minuten Kompilationsversuchen für die Beispiele kam nur eine ausführbare Datei heraus, die sofort mit einer Zugriffsverletzung innerhalb der Vulkan-Bibliothek abstürzte

Sciter

  • Eine gute Alternative zu Electron, mit der sich GUIs für Desktop-Apps mit HTML/CSS schreiben lassen
  • Probleme:
    • Die Größe der fertigen App von etwa 25 MB zusammen mit allen .dll-Dateien scheint problematisch, ist aber noch akzeptabel
    • Es wäre besser, wenn es Open Source wäre und man die statisch gelinkte Version auch kommerziell nutzen könnte
    • Es ist nicht so teuer wie Qt ($310), daher würde man gern dafür bezahlen
    • Das Problem ist, dass das Rendering nicht besonders gut ist
    • Es gab Aliasing-Probleme bei Schriftarten und Bildern
    • Das Fenster hat einen ziemlich dicken (2–3 px) grauen Rahmen, der sich nicht anpassen oder ändern lässt

WinForms / WPF

  • Fragt man nach einer C++-GUI-Bibliothek, empfehlen die meisten stattdessen einen anderen Stack
    • C++ sei keine gute Idee, daher solle man das Frontend des Programms in einem anderen Stack schreiben und die in C++ geschriebene Funktionalität als Komponente/Modul laden
  • Man kann eine einzelne .exe-Datei in kleiner Größe haben und WinForms/WPF verwenden
  • .dll-Dateien können als Ressourcen in die App gebündelt, in einen temporären Ordner extrahiert und dann per P/Invoke verwendet werden; außerdem kann man kompilierte .dll-Dateien innerhalb der C#/.NET-App aufrufen oder C++/CLI verwenden
  • Probleme:
    • Das .NET Framework ist unter Windows 10 und höher vorinstalliert und erfüllt damit technisch gesehen das Kriterium „keine Abhängigkeiten“
      • Wenn man .dll-Dateien bündelt, müssen sie irgendwohin extrahiert werden, und es muss zusätzlicher Code geschrieben werden, damit P/Invoke funktioniert
      • C++/CLI wird zu .NET-IL-Code kompiliert, sodass C++-Code erscheint, der nach C# übersetzt wurde

Lösung?

  • Für einfache Apps scheint nichts besser geeignet zu sein als Dear ImGui
  • Beim Entwerfen komplexer UIs hat es vor allem Nachteile, und da es keine Retained-Mode-, sondern eine Immediate-Mode-UI ist, muss ein GPU-Renderer wie DirectX laufen, um die UI mit mehr als 60 Frames pro Sekunde zu rendern
  • In allen anderen Punkten passt es jedoch
  • Das kompilierte Programm ist nur 500 KB groß, und es muss kein VC++ Redistributable installiert werden

Meinung von GN⁺

  • Wie der Autor sagt, scheint es keine perfekte Bibliothek für die Entwicklung von GUI-Apps zu geben. Je nach Anforderungen gibt es Trade-offs
  • Für einfache Apps scheint Dear ImGui am besten geeignet zu sein, aber für komplexe UIs ist ein GUI-Toolkit im Retained Mode vermutlich die bessere Wahl
  • Beim Erstellen kommerzieller Apps können Lizenzkosten ein wichtiger Faktor sein. Bibliotheken wie Qt sind teuer, während wxWidgets kostenlos genutzt werden kann
  • Das Erstellen von GUI-Apps in C++ ist nicht einfach, daher könnte es realistischer sein, das Frontend in C# oder einer anderen Sprache zu entwickeln und nur die performancekritischen Teile in C++ zu implementieren
  • Wenn man unter Windows ein natives Look-and-Feel möchte, sind WinUI oder MFC sinnvoll, bei Bedarf an plattformübergreifender Unterstützung könnten Qt oder wxWidgets jedoch die bessere Wahl sein

Verwandte Beiträge

7 Kommentare

 
tsboard 2024-07-05

hikogui ist ja ein furchteinflößendes Ding, wow
 
fastkoder 2024-07-03

https://getstream.io/blog/flutter-desktop-vs-electron/ Vergleich der Performance anhand verschiedener Kennzahlen
 
fastkoder 2024-07-03

Im Vergleich zu Sciter und Electron ist auch Flutter Windows Desktop Build eine Überlegung wert. Es gibt zwar gelegentlich Plugins mit Bugs, aber die Basis ist solide, sodass es sich als Transportmedium nutzen lässt.
Singleton-Instanz, automatische Updates, Statusleiste, Windows-Benachrichtigungen, schnelle Startzeit, die Sprache Dart, Win32API-Plugin usw.
 
soone 2024-07-03

Delphi
 
soone 2024-07-03

C++ Builder
 
joyfui 2024-07-02

„Um erfolgreich zu kompilieren, braucht man einen Doktortitel in Informatik“
LOL
 
GN⁺ 2024-07-01
Hacker-News-Kommentar
  • Beim Lesen vieler Kommentare wurde klar, dass die gesamte Grundannahme falsch ist. Es wäre besser, den Blogbeitrag in „Das Schreiben von GUI-Apps für Windows ist schmerzhaft, wenn die Anforderungen unrealistisch sind“ umzubenennen
  • Es wäre sinnvoll, mit .NET Framework 3.5 auf WinForms zu zielen. Das ist auf allen aktuellen Windows-Versionen installiert
  • Dieser Artikel bietet einen guten Überblick über mehrere Optionen, aber die spezifischen Anforderungen des Autors schließen viele Optionen aus
    • Die Anforderung, vollständig benutzerdefiniertes GUI-Styling zu wollen, ohne eigene Rendering-Funktionen zu schreiben, macht die Aufgabe im Grunde zur Auswahl einer leicht anpassbaren GUI-Bibliothek
    • Auch die Anforderungen nach einer in sich geschlossenen ausführbaren Datei und einer Größenbeschränkung von unter 40 MB schließen viele Optionen aus. Qt hätte diese Anforderungen erfüllen können, aber die Open-Source-Lizenz passte nicht zum Ziel, und man wollte keine Lizenz kaufen
    • Wenn Abhängigkeiten erlaubt wären, eine größere Downloadgröße akzeptabel wäre oder eingebaute Windows-GUI-Controls verwendet würden, sähe die Lage ganz anders aus
    • Wenn man eine leichtgewichtige, vollständig benutzerdefinierte GUI ohne externe Abhängigkeiten schreiben und eine freizügige Lizenz haben möchte, hätte ich erwartet, dass ImGui die Antwort ist
  • Es wird darauf hingewiesen, dass an der WinForms-/WPF-Idee kein großer Fehler besteht, aber außer der Anforderung von zwei Stacks wird nichts weiter dazu gesagt. Man will nativen Code und kein C# sehen, erklärt aber nicht warum. Vielleicht ist es die Angst vor Reverse Engineering. UI-Code enthält selten Geheimnisse
    • Die Verteilung als einzelne exe ist manchmal praktisch, kann in diesem Szenario aber lästig sein. Mit einem Packager wie Velopack (Squirrel) kann man als einzelne exe verteilen und bekommt auch automatische Updates dazu. Dass bei der Installation zwei oder mehr Dateien auf der Festplatte liegen, ist ein guter Kompromiss
    • Windows ist die schlechteste Plattform für die Entwicklung von Desktop-Apps, abgesehen von allen anderen Plattformen
  • Ich halte sehr wenig von Entwicklern, die sich darüber beklagen, für kommerzielle Lizenzen von Softwarebibliotheken unter LGPL bezahlen zu müssen. Sie erwarten selbst, für ihre Arbeit entlohnt zu werden, und sichern das ab, indem sie Closed-Source-Software schreiben. Aber Entwickler, die den tatsächlich schwierigen Teil beim Erstellen einer UI-Bibliothek gelöst haben, sollen bitte erwachsene Menschen sein, die der Welt ihren Code frei schenken
  • Zu Sciter und dem Problem mit dem „Anti-Aliasing“ ... der Autor hat in der Anwendung keine Unterstützung für hohe DPI-Auflösungen aktiviert
    • Das lässt sich in Visual Studio aktivieren oder durch Einbinden eines passenden Manifests beheben
    • Es wird im Tutorial „Hello C++“ erklärt
  • Genauer gesagt:
    • „Portable“ (eine einzelne exe ohne selbstentpackendes Archiv)
    • kommerziell und ohne kompilierte Objektdateien weiterverteilen zu wollen (das erlaubt zusammen mit der Anforderung „portable“ kein LGPL)
    • Dark Mode
    • Windows-GUI-Apps sind schmerzhaft. Wenn man eine dieser Anforderungen streicht, gibt es viele gute Optionen
    • Die meisten „portablen“ Anwendungen verwenden win32. Üblicherweise sind portable Anwendungen klein und einfach; Funktionalität ist wichtiger als Dark Mode oder andere Styling-Möglichkeiten
  • Als jemand, der viel von Open Source anderer Leute verlangt, scheint der Autor seine eigene Lösung nicht als Open Source veröffentlichen zu wollen
  • Ich arbeite an einem GUI-Toolkit, das zu den Anforderungen passt: Slint - https://slint.dev
    • Es kann statisch in eine einzelne .exe mit weniger als 40 MB kompiliert werden. Es hat eine Lizenz, die auf dem Desktop kostenlos nutzbar ist. Es bietet Dark-/Light-Styling. Außerdem ist ein (in Arbeit befindlicher) Drag-and-Drop-WYSIWYG-Editor enthalten
  • Dass man für alle Controls benutzerdefinierte Paint-Funktionen schreiben müsse, zeigt, dass die alte win32-Philosophie nicht zum Autor passt. Das Kernelement von win32 ist wndproc. Die meisten Controls fragen ihre Eltern nach der Farbe
    • Wenn das unbequem ist, ist es kein großes Problem, es mit einer kleinen Bibliothek zu wrappen und so Boilerplate zu entfernen
  • Das Ergebnis sollte eine einzelne .exe-Datei ohne oder mit minimalen Abhängigkeiten sein und kleiner als 40 MB
    • Computer haben heute moderne Browser. Statt einer .exe-Datei könnte man eine einzelne .html-Datei mit eingebetteten Bildern/CSS/JavaScript verwenden