Écrire des applications GUI pour Windows est pénible

 (tulach.cc)
8 points par GN⁺ 2024-07-01 | 7 commentaires | Partager sur WhatsApp
  • Récapitulatif des résultats après avoir recherché et comparé des bibliothèques pour créer des GUI en C++
  • Exigences de base : prise en charge de Windows uniquement, usage commercial autorisé, stylisation facile avec mode sombre inclus, génération d’un seul EXE de moins de 40 Mo avec un minimum de dépendances, développement rapide

WinUI 3

  • Au départ, cela semblait être un excellent choix
  • Permet d’utiliser des composants Windows modernes et de personnaliser les couleurs du style
  • On peut concevoir l’interface avec XAML et même utiliser directement le designer de Visual Studio
  • Problèmes :
    • La distribution de l’application sous forme non packagée est mal prise en charge
    • Lorsqu’on déplace l’application vers une VM ou un autre ordinateur, elle échoue le plus souvent à se lancer
    • Il faut fournir de nombreux fichiers .dll pour gérer les fonctionnalités WinUI
    • Impossible de créer un unique fichier .exe portable
    • Aucun problème en mode packagé, mais l’installation sous forme de paquet AppX entraîne des problèmes d’accès à l’API Win32

Win32 / MFC / petites bibliothèques qui encapsulent Win32

  • Comme une grande portabilité est nécessaire, il est logique d’utiliser le rendu natif du système d’exploitation
  • Le programme peut tenir dans un seul fichier .exe et rester très léger (avec liaison statique de MFC)
  • Il est possible d’utiliser une bibliothèque plus minimale déjà écrite par quelqu’un
  • Problèmes :
    • Styliser les contrôles Win32 natifs est très difficile
    • Il faut écrire des fonctions de peinture personnalisées pour tous les contrôles
    • Il existe un mode sombre « caché » utilisé dans l’explorateur de fichiers Windows, mais il ne couvre qu’une partie des contrôles et reste peu convaincant

Qt

  • Le Graal des GUI en C++
  • C’est complexe, mais on peut le styliser facilement avec les Qt Style Sheets
  • Problèmes :
    • En liaison dynamique, l’application a besoin de très nombreux fichiers .dll pour se lancer, et la taille dépasse 40 Mo
    • Il est possible de lier Qt statiquement au programme, mais il faut alors soit le rendre open source, soit distribuer les fichiers objets permettant la recompilation à cause de la licence LGPL de Qt
    • Sinon, on peut acheter une licence commerciale, mais cela coûte plusieurs milliers de dollars

wxWidgets

  • Une bibliothèque facile à apprendre
  • On peut utiliser wxFormBuilder
  • Sa licence est plus permissive que celle de Qt, et elle peut être liée statiquement dans un exécutable de 3 Mo
  • Problèmes :
    • Sous Windows, elle utilise les composants Win32 natifs et n’offre pas d’options de stylisation
    • Elle prend en charge les contrôles sombres de l’explorateur de fichiers Windows, mais le résultat n’est pas très bon

hikogui

  • Une nouvelle bibliothèque GUI en retained mode utilisant Vulkan comme backend
  • Elle intègre un mode sombre et se stylise facilement
  • Problèmes :
    • Il faut apparemment un doctorat en informatique pour réussir à la compiler
    • Après plus de 30 minutes à essayer de compiler les exemples, le seul résultat a été un exécutable qui plantait immédiatement avec une violation d’accès dans la bibliothèque Vulkan

Sciter

  • Une bonne alternative à Electron qui permet d’écrire des GUI d’applications de bureau en HTML/CSS
  • Problèmes :
    • La taille finale de l’application, environ 25 Mo avec tous les fichiers .dll, semble problématique, mais reste acceptable
    • Ce serait encore mieux si c’était open source et si une version à liaison statique pouvait être utilisée commercialement
    • Ce n’est pas aussi cher que Qt ($310), donc ce serait acceptable de payer
    • Le problème, c’est que le rendu n’est pas très bon
    • Il y avait des problèmes d’aliasing sur les polices et les images
    • La fenêtre a un cadre gris assez épais (2-3 px) qu’on ne peut ni personnaliser ni modifier

WinForms / WPF

  • Quand on pose une question sur les bibliothèques GUI en C++, la plupart recommandent d’utiliser une autre stack
    • On vous dit que le C++ est une mauvaise idée, et qu’il vaut mieux écrire le frontend du programme dans une autre stack puis charger les fonctionnalités écrites en C++ sous forme de composants/modules
  • On peut avoir un seul .exe de petite taille et utiliser WinForms/WPF
  • Il suffit d’intégrer les .dll comme ressources de l’application, de les extraire dans un dossier temporaire, puis d’utiliser P/Invoke pour appeler les .dll compilées depuis l’application C#/.NET, ou d’utiliser C++/CLI
  • Problèmes :
    • Le framework .NET est préinstallé sur Windows 10 et plus, donc techniquement cela respecte le critère d’absence de dépendances
      • Si l’on intègre les .dll, il faut tout de même les extraire quelque part et écrire du code supplémentaire pour que P/Invoke fonctionne
      • C++/CLI est compilé en code IL .NET, ce qui donne l’impression d’un code C++ traduit en C#

La solution ?

  • Pour une application simple, il ne semble rien y avoir de plus adapté que Dear ImGui
  • Pour concevoir une interface complexe, cela présente surtout des inconvénients, et comme il ne s’agit pas d’une interface en retained mode mais en immediate mode, il faut faire tourner un moteur de rendu GPU comme DirectX à plus de 60 images par seconde pour l’UI
  • Mais sur tous les autres points, cela correspond
  • Le programme compilé ne fait que 500 Ko, et il n’est pas nécessaire d’installer les redistribuables VC++

L’avis de GN⁺

  • Comme le dit l’auteur, il ne semble pas exister de bibliothèque parfaite pour développer des applications GUI. Il y a des compromis selon les exigences
  • Pour les applications simples, Dear ImGui semble être le choix le plus adapté, mais pour des interfaces complexes, il vaut mieux utiliser un toolkit GUI en retained mode
  • Pour créer une application commerciale, le coût de licence peut être un facteur important. Des bibliothèques comme Qt sont coûteuses, alors que wxWidgets peut être utilisé gratuitement
  • Créer une application GUI en C++ n’est pas simple, donc il peut être plus réaliste de développer le frontend en C# ou dans un autre langage, et de n’implémenter en C++ que les parties intensives en calcul
  • Si l’on veut un look-and-feel natif sous Windows, il vaut mieux utiliser WinUI ou MFC, mais si l’on a besoin d’un support multiplateforme, Qt ou wxWidgets peuvent être de meilleurs choix

À lire aussi

7 commentaires

 
tsboard 2024-07-05

hikogui, ça fait vraiment peur, ça fait froid dans le dos
 
fastkoder 2024-07-03

https://getstream.io/blog/flutter-desktop-vs-electron/ comparaison des performances selon différents indicateurs
 
fastkoder 2024-07-03

Comparé à Sciter et Electron, Flutter Windows Desktop Build mérite aussi d’être envisagé. Il existe parfois des plugins avec quelques bugs, mais les bases sont solides, ce qui le rend utilisable comme vecteur de diffusion.

Instance singleton, mises à jour automatiques, barre d’état, notifications Windows, temps de lancement rapide, langage Dart, plugin Win32API, etc.
 
soone 2024-07-03

Delphi
 
soone 2024-07-03

C++ Builder
 
joyfui 2024-07-02

"Il faut un doctorat en informatique pour réussir à compiler"
mdr
 
GN⁺ 2024-07-01
Commentaire Hacker News
  • En lisant de nombreux commentaires, j’ai réalisé que la prémisse générale était erronée. Il vaudrait mieux renommer l’article de blog en « Écrire une application GUI pour Windows est pénible quand les exigences sont irréalistes »
  • Il vaudrait mieux cibler WinForms avec .NET Framework 3.5. Il est installé sur toutes les versions récentes de Windows
  • Cet article offre une bonne vue d’ensemble des différentes options, mais les exigences spécifiques de l’auteur en éliminent beaucoup
    • Exiger un style GUI entièrement personnalisé tout en ne voulant pas écrire ses propres fonctions de rendu revient à chercher une bibliothèque GUI facile à personnaliser
    • L’exigence d’un exécutable autonome avec une limite de taille inférieure à 40 Mo élimine également de nombreuses options. Qt aurait pu répondre à ces exigences, mais sa licence open source ne correspondait pas à l’objectif et l’auteur ne voulait pas acheter de licence
    • Si l’on accepte des dépendances, une taille de téléchargement plus importante, ou l’utilisation des contrôles GUI Windows intégrés, la situation est très différente
    • Si l’on veut une GUI légère, entièrement personnalisée, sans dépendance externe, avec une licence permissive, j’aurais pensé que ImGui était la réponse
  • L’auteur souligne qu’il n’y a pas de gros défaut dans l’idée WinForms/WPF, mais ne mentionne rien d’autre que le fait d’exiger deux piles. Il veut du code natif et ne veut pas voir de C#, sans expliquer pourquoi. C’est peut-être par crainte de l’ingénierie inverse. Le code UI contient rarement des secrets
    • Déployer un seul exe est parfois pratique, mais cela peut être contraignant dans ce scénario. En utilisant un packageur comme Velopack (Squirrel), on peut distribuer un seul exe tout en ajoutant les mises à jour automatiques. Avoir deux fichiers ou plus sur le disque après l’installation est un bon compromis
    • Windows est la pire plateforme pour développer des applications desktop, à l’exception de toutes les autres
  • J’ai une très mauvaise opinion des développeurs qui se plaignent de devoir payer une licence commerciale pour des bibliothèques logicielles sous licence LGPL. Ils s’attendent à être rémunérés pour leur propre travail et s’en assurent en créant des logiciels closed source. Mais les développeurs qui ont réellement résolu la partie difficile, à savoir créer une bibliothèque UI, devraient, eux, offrir gratuitement leur code au monde comme des adultes
  • Concernant Sciter et le problème d’« anti-aliasing »… l’auteur n’a pas activé la prise en charge du DPI haute résolution dans son application
    • Cela peut se corriger en l’activant dans Visual Studio ou en incluant le manifeste approprié
    • C’est expliqué dans le tutoriel « Hello C++ »
  • Plus précisément :
    • « portable » (un seul exe, sans auto-extraction)
    • usage commercial, sans vouloir redistribuer de fichiers objets compilés (ce qui, avec l’exigence « portable », exclut la LGPL)
    • mode sombre
    • les applications GUI Windows sont pénibles. Retirez l’une de ces exigences et il existe beaucoup de bonnes options
    • la plupart des applications « portables » utilisent win32. En général, le portable concerne des applications petites et simples, où la fonctionnalité compte plus que le mode sombre ou d’autres capacités de style
  • Alors qu’il exige beaucoup de l’open source des autres, l’auteur ne semble pas vouloir publier sa propre solution en open source
  • Je travaille sur un toolkit GUI correspondant à ces exigences : Slint - https://slint.dev
    • Il peut être compilé statiquement en un seul fichier .exe de moins de 40 Mo. Il dispose d’une licence gratuite pour une utilisation desktop. Il propose des styles sombre/clair. Il inclut aussi un éditeur WYSIWYG drag-and-drop (en cours de développement)
  • Dire qu’il faut écrire des fonctions de peinture personnalisées pour tous les contrôles montre que l’ancienne philosophie win32 ne convient pas à l’auteur. L’élément central de win32, c’est le wndproc. La plupart des contrôles demandent leur couleur au parent
    • Si c’est inconfortable, l’envelopper dans une petite bibliothèque pour supprimer le boilerplate n’est pas un gros problème
  • Le résultat doit être un seul fichier .exe avec zéro dépendance ou un minimum de dépendances, et une taille inférieure à 40 Mo
    • Les ordinateurs disposent désormais d’un navigateur moderne. Au lieu d’un fichier .exe, on pourrait utiliser un seul fichier .html avec les images/CSS/JavaScript intégrés en ligne