Composants GPUI cross-platform en Rust

• Bibliothèque de composants UI permettant de créer des applications desktop cross-platform avec le framework GPUI basé sur Rust
• Propose plus de 60 composants UI au style natif, en combinant l’esthétique macOS et Windows avec la modernité de shadcn/ui
• Intègre de nombreuses fonctionnalités comme des tables virtualisées, un éditeur de code haute performance, le rendu Markdown/HTML et la visualisation de graphiques
• Conçu avec un fort accent sur l’extensibilité et la personnalisation, avec système de thèmes, multilingue (i18n) et layout docking
• Dans l’écosystème Rust, se distingue face à Iced, egui et Qt par un style d’UI moderne et de bonnes performances sur le traitement de grands volumes de données

---

Aperçu du projet

• gpui-component est un ensemble de composants UI desktop cross-platform écrit en Rust, reposant sur le moteur de rendu GPUI
  • L’objectif est de permettre de créer des “fantastic desktop applications” rapidement et de manière cohérente
  • Le site officiel est longbridge.github.io/gpui-component
• Licence Apache-2.0

Fonctionnalités principales

• Jeu de composants riche : plus de 60 éléments UI, avec boutons, listes, tableaux, graphiques, éditeur et bien d’autres
• Design à sensation native : une interface moderne inspirée des contrôles natifs de macOS et Windows, combinés au style shadcn/ui
• Simplicité d’usage : architecture de composants RenderOnce sans état, pour écrire un code simple et intuitif
• Système de thèmes et de couleurs : prise en charge de plusieurs thèmes et d’une configuration basée sur des variables via Theme et ThemeColor
• Layout flexible : avec le Dock layout, il est possible d’organiser les panneaux, de les redimensionner et de composer librement une interface en tuiles
• Rendu haute performance : les Virtualized Table/List permettent d’afficher de gros volumes de données de manière fluide
• Rendu de contenu : prise en charge native de Markdown et d’un HTML simple
• Fonctions de graphiques : visualisation de données avec des graphiques intégrés
• Éditeur de code : inclut un éditeur de code haute performance basé sur LSP prenant en charge jusqu’à 200�0 lignes
  • Prend en charge les diagnostics, l’autocomplétion, le hover, etc.
• Coloration syntaxique : utilise Tree Sitter pour fournir la mise en évidence syntaxique dans l’éditeur comme dans le Markdown

Stack technique et statistiques

• Répartition des langages : Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
• Indicateurs du dépôt : 5.4k stars, 223 forks, plus de 45 contributeurs
• Dernière release : v0.3.1 (27 octobre 2025)

Ce qu’il faut en retenir

• gpui-component est considéré dans l’écosystème Rust comme un nouveau framework UI desktop associant UI/UX moderne et rendu haute performance
• Il corrige les limites des frameworks GUI Rust existants et propose des fonctionnalités adaptées à un usage concret, comme le traitement de grands volumes de données, la thématisation et l’intégration de Markdown
• C’est un projet remarqué comme candidat à une couche UI standardisée pour le développement d’applications cross-platform en Rust

[GN⁺]

Commentaires Hacker News

• Dans l’écosystème UI Rust, cela ressemble à la collection de composants la plus aboutie que j’aie vue jusqu’à présent
  Il y a encore très peu de cas d’usage, mais la documentation s’améliore progressivement
  Un autre exemple de maturité comparable serait fyrox-ui, mais il est très peu utilisé en dehors du moteur fyrox
  L’UI Rust gagne en maturité, mais les frameworks populaires comme iced, egui, dioxus et slint semblent encore en retrait sur le plan de la finition des composants
  Pour mise à jour, ce projet montre une avancée majeure dans l’écosystème UI Rust.
  Vous pouvez lancer ici l’application de galerie de widgets qui permet de voir tous les composants — il suffit d’exécuter cargo run --release

  • gpui est un projet détaché de Zed Editor, donc son usage réel est probablement bien plus élevé que celui des autres crates UI Rust
  • Fyrox donne une impression de scepticisme vis-à-vis du développement de jeux en Rust. C’est le moteur le plus mature, et pourtant personne ne l’utilise. À l’inverse, les gens s’enthousiasment uniquement pour l’ECS de Bevy. On dirait qu’au fond, ils s’intéressaient surtout au système lui-même, pas à la création de vrais jeux
  • Les frameworks UI Rust semblent encore peu aboutis parce qu’ils évoluent très vite. Cela dit, la dynamique est bien réelle. Ce n’est que mon expérience personnelle, mais j’ai déjà pu créer des UI de niveau entreprise en Rust
  • J’ai installé moi-même l’application Longbridge, et elle fonctionne vraiment comme une application native Mac. C’est bien plus fluide qu’Electron
  • L’application de galerie de widgets est impressionnante, mais le fait qu’elle ait plus de 900 dépendances est un peu inquiétant. Je ne sais pas si c’est courant pour une application GUI

• Même l’exemple le plus simple a plus de 1000 dépendances. Il dépend de toolkits comme GTK, GDK et pango. Le fait de dépendre d’autres toolkits donne une impression un peu étrange

  • GNOME n’implémente pas les décorations côté serveur, donc il faut dépendre de libadwaita. C’est probablement ce qui entraîne toutes les dépendances liées à GTK
  • Sous Linux, ce genre de structure est courant. Il est habituel d’utiliser GTK ou Qt pour dessiner les fenêtres de niveau supérieur ou les menus
  • Je pense que 1000 petites dépendances composables valent mieux qu’une énorme base de code monolithique. C’est bien plus facile à auditer
  • C’est dommage que les projets Rust récents deviennent de plus en plus gros de cette manière

• Il est amer de voir que tant de technologies fondamentales de l’open source sont créées par des entreprises de trading ou de crypto. Cela dit, le fait qu’elles apportent malgré tout quelque chose à la société reste positif

  • gpui est maintenu par l’équipe de Zed.dev, et Longbridge semble être une société de courtage assez classique qui développe l’application Longbridge Pro. Il ne semble pas y avoir de problème particulier
  • Je pense que l’esprit Bitcoin ressemble à la culture hacker. Cette attitude du type « réparons ce qui est cassé ». Une douleur à court terme peut parfois apporter un bénéfice à long terme
  • On observe peut-être cette tendance dans certains écosystèmes comme Rust ou OCaml (Jane Street), mais à l’échelle globale cela semble exagéré
  • Facebook, qui a créé React, a été impliqué dans des affaires comme le scandale Cambridge Analytica ou le génocide des Rohingyas. Vu sous cet angle, les entreprises de trading ou de crypto qui contribuent à l’open source sont peut-être même moralement préférables

• Je me demande si les toolkits UI dits « modernes » n’ont plus d’éditeur visuel d’interface
  Qt permettait de construire une UI par simple glisser-déposer avec des outils comme QtCreator ou QtDesigner
  Et certains éléments des tableaux comparatifs liés à Qt sont faux — par exemple la taille minimale du binaire ou l’explication de QSyntaxHighlighter

  • Des frameworks comme Slint prennent en charge l’intégration avec Figma, ce qui permet un usage proche de Qt Design Studio. On a l’impression qu’on a un peu oublié à quel point les anciens designers GUI natifs étaient puissants
  • Avec une bibliothèque de composants bien aboutie comme base, il serait possible d’implémenter ce type d’éditeur visuel en Rust. On pourrait relier une structure XML/markup à des macros et créer une application d’aperçu en temps réel qui fonctionnerait comme Glade ou XAML
  • La taille minimale de Qt est en réalité inférieure à 20 Mo, mais en pratique elle tourne plutôt autour de 30 à 40 Mo. Les modules Core, Gui, QML et Widget font chacun environ 8 Mo, donc même un Hello World en nécessite 2 ou 3
  • Qt Designer convient pour des UI simples, mais dès qu’on applique un style personnalisé, tout se casse rapidement. J’ai donc fini par écrire les fichiers UI à la main. C’était bien plus propre et plus léger
  • Dire que Qt6 ne prend pas en charge les thèmes est tout simplement faux

• Malheureusement, c’est un framework. Il doit donc avoir sa propre boucle d’événements
  L’intégration est difficile dans des environnements où une autre boucle existe déjà. À l’inverse, egui est simplement une bibliothèque appelée à chaque frame

• Je me demande si l’accessibilité pour les lecteurs d’écran fonctionne correctement

  • Je ne l’ai pas exécuté moi-même, mais d’après la documentation officielle, le projet prend en charge la spécification ARIA. Il suffit d’ajouter les labels et descriptions nécessaires
  • Mais Zed Editor reste totalement opaque pour les lecteurs d’écran. Je n’en attends donc pas grand-chose
  • Chaque fois que je vois un nouveau framework UI, la première question que je pose concerne précisément l’accessibilité

• Je me demande si « natif » veut simplement dire que ce n’est pas du web, ou si cela signifie aussi qu’il utilise les widgets natifs du système d’exploitation. Le monde Java a beaucoup souffert de cette distinction

  • Seul macOS est une plateforme où l’on peut faire de vraies applications natives. Linux est divisé entre GTK et Qt, et sur Windows il y a tellement de frameworks mélangés que même une WebView peut sembler native
  • Ici, natif veut dire « ce n’est pas du web ». Le rendu se fait directement via une API GPU
  • Autrement dit, c’est un exécutable natif, pas une application qui utilise les widgets de l’OS
  • Il n’y a pas d’intégration OS, c’est un rendu entièrement propriétaire

• Je me demande si ce framework a implémenté l’accessibilité (a11y). Les UI Rust sont souvent jolies, mais dès qu’il y a des exigences d’accessibilité, il faut tout réécrire

  • Si l’accessibilité est importante, Dioxus peut être une option à envisager. En revanche, il n’existe pas encore de bibliothèque de composants aussi aboutie à ce niveau
  • GPUI repose sur la base construite par l’équipe de Zed, mais reste opaque pour les lecteurs d’écran. Si l’accessibilité est essentielle, mieux vaut regarder du côté de Slint ou de Qt (cxx-qt), et comme System76 a adopté Iced, cela devrait aussi progresser de ce côté-là
  • L’accessibilité est implémentée

• La fonctionnalité de listes et tableaux virtualisés est vraiment excellente. Beaucoup de frameworks UI obligeaient à l’implémenter soi-même, ce qui était pénible

• Rust a beaucoup de toolkits GUI, mais manque de collections de composants réutilisables
  Cette collection semble utile, mais elle ressemble surtout à la liste de composants de la plupart des frameworks web. Le seul élément vraiment spécifique au natif semble être la webview. Pour des choses comme une boîte de dialogue d’ouverture de fichier, il faut encore utiliser une bibliothèque externe comme rfd, ce qui casse la cohérence visuelle

  • Le fait de casser la cohérence visuelle est au contraire une bonne chose. Les utilisateurs veulent de la cohérence entre les applications. Autrement dit, une boîte de dialogue native de l’OS leur est plus familière. Les logiciels professionnels comme Blender ou Photoshop sont des exceptions, mais pour une application classique, le natif est préférable
  • La plupart des bibliothèques UI ont aussi besoin d’un minimum d’intégration native. Raccourcis clavier, menus système, boîtes de dialogue de fichiers, menus contextuels, etc. C’est ce genre de détails qui rend une application plus familière pour l’utilisateur
  • Le sélecteur de fichiers doit impérativement utiliser la boîte de dialogue native de l’OS. Il ne faut pas l’implémenter soi-même