Microsoft avance vers l'open source de WinUI, le framework d’interface utilisateur de Windows 11

• Microsoft a annoncé un plan progressif pour open-sourcer WinUI, le framework d’interface utilisateur de Windows 11.
• WinUI ne peut pas être ouverte immédiatement en raison de sa structure complexe et de la quantité élevée de code propriétaire : il faut d’abord distinguer les parties partageables de celles qui ne le sont pas.
• L’ouverture en open source devrait se faire en quatre étapes
  • Étape 1 : augmentation de la fréquence des miroirs : après la sortie de WASDK 1.8 (fin août), les commits internes seront synchronisés avec GitHub plus souvent pour partager plus de transparence et d’informations sur l’avancement du développement.
  • Étape 2 : compilation locale pour les développeurs externes : les développeurs externes pourront cloner le code et le compiler localement, avec mise à disposition de la documentation de configuration et des dépendances.
  • Étape 3 : contributions et tests externes : les contributeurs communautaires pourront soumettre des Pull Request et exécuter des tests locaux ; une rationalisation des dépendances internes ainsi qu’une ouverture de l’infrastructure de test est également prévue.
  • Étape 4 : transition vers un modèle de développement centré sur GitHub : à terme, GitHub deviendra le centre du développement principal, de la gestion des issues et des échanges communautaires, tandis que le système de miroir interne sera progressivement démantelé.
• La feuille de route d’open source de WinUI est gérée publiquement sur le tableau de bord du projet GitHub.
• Les développeurs et utilisateurs peuvent contribuer à l’évolution de WinUI via des retours, la rédaction d’issues claires et des votes sur les idées déjà publiées.

[regentag]

Je n’aime pas COM ni WebView... j’aimerais vraiment avoir une GUI à peu près utilisable.
Jusqu’à présent, la meilleure interface utilisateur que j’ai testée sur Windows, c’était Qt4. Depuis Qt5, la sensation a bien changé.

[regentag]

Franchement, je me souviens que le MFC n'était pas si mauvais... lol

[GN⁺]

Commentaires Hacker News

• Je suis inquiet pour l’avenir de la technologie d’UI native de Windows.
  Les développeurs de systèmes d’exploitation ont généralement réussi à créer des applis natives cohérentes et bien fonctionnelles pour les produits qu’ils utilisent eux-mêmes.
  Mais sur Windows 11, c’est l’inverse.
  Depuis Windows 10, il y avait au moins des apps mail et calendrier de base qui marchaient correctement, mais dans la dernière mise à jour de Windows 11 ces apps ont disparu, remplacées par un wrapper WebView lent qui met plusieurs secondes à démarrer.

  • Quand je regarde les Community Calls WinUI, il semble que la plupart des nouveaux employés n’aient aucune expérience de Windows, et que la direction ne se soucie pas de combler ce manque.
    Résultat : des développeurs qui échouent à répondre à des questions évidentes pour n’importe quel dev Windows, avec un regard qui ne comprend même pas pourquoi ces questions sont posées.
    C’est une des raisons pour lesquelles des instances WebView2 pullulent un peu partout dans Windows 11.

  • Les problèmes d’UI sur Windows 11 semblent venir d’un focus excessif sur les nouvelles apps/fonctions, sans remettre à jour les anciens outils.
    Le Panneau de configuration, par exemple, est quasiment vêtu du même “skin” depuis Windows 7.
    Et plus on creuse, plus on trouve des outils obsolètes planqués partout, comme un mème où on colle des trombones sur Homer Simpson.
    Ça a l’air neuf en façade, mais les limites apparaissent vite à l’usage.

  • Je me demande si un jour on ne réécrira pas complètement MSO (Office) en Dart et WASM.
    Peut-être une solution totalement indépendante du toolkit natif, reproduisant toutes les fonctionnalités d’Excel et accessible partout via un modèle à la O365 Premium.
    Au final, Windows pourrait bien finir par ressembler à ChromeOS, avec une UI native minimale seulement pour l’écran de verrouillage/connexion et un traitement plus léger du reste.

  • Quand on comprend les luttes de pouvoir et la politique interne chez Microsoft, on saisit pourquoi ce type de changement arrive.
    Les départements sont en compétition pour la suprématie.

  • On a l’impression que Windows mélange au moins 10 frameworks UI différents.
    Windows 11 ressemble parfois à une visite de musée d’histoire naturelle.
    Il y a des apps qui sont restées dans un style propre à Windows 2000 (du genre MSC), et d’autres qui gardent une UI brute, très colorée, sous influence Metro.
    Le style Win11 actuel peut sembler crédible, mais au fond c’est souvent comme “mettre du rouge à lèvres à un cochon”.
    Le menu contextuel du clic droit en est l’exemple type : c’est joli, mais manque de fonctions, et il faut cliquer sur “Afficher plus” pour retrouver le style précédent avec davantage d’options.
    En somme, c’est complètement en vrac.

• Les annonces du genre “alignement sur les objectifs Microsoft” ou “allocation prudente des ressources” ne semblent pas du tout sincères.
  Ça donne l’impression d’externaliser le framework, de retirer des ressources et d’espérer que des développeurs externes, mus par leur passion, assurent la maintenance.

  • L’expression “losers passionnés” me semble trop négative.
    Même si je ne suis pas intéressé par l’UI de Win11, ou même si je suis cynique en pensant que cette ouverture n’est qu’un moyen de réduire les coûts, je voudrais malgré tout montrer un certain respect à ceux qui veulent faire avancer le truc.

  • Pour être clair, c’est une communication de grand groupe du type : “pas de support garanti, pas d’update prévue en dehors des bugs de sécurité, débrouillez-vous”.

  • Ça me donne presque envie de dire, sur le mode blague : “Quand sort Apache Windows ?”
    Sérieusement, les toolkits UI desktop ne sont plus le lieu principal de compétitivité ni une vraie barrière à l’entrée, notamment parce qu’il existe déjà 3 à 4 styles différents officiellement sur Windows.
    Mais la sécurité et la stabilité restent essentielles pour que Windows survive dans les entreprises, la finance et l’administration.

  • Il y a des cas où ouvrir le framework UI d’une autre société se comprend.
    Par exemple, les frameworks d’Atlassian ou d’AWS, déjà utilisés par Jira/AWS, peuvent avoir du sens en B2B SaaS.
    Mais là, je ne vois pas pourquoi on devrait utiliser ce framework.
    Si le but n’est pas de développer uniquement des apps Windows natives, je pense qu’il existe déjà de meilleures options.

  • Je pense que WinUI est un échec.

• Dans la communauté Windows, il y a très peu de gens qui s’intéressent vraiment à WinUI, hormis les développeurs déjà investis dans WinRT/UWP qui sont piégés dedans depuis un moment.
  Depuis Windows 8, trop de ponts ont été cassés et la confiance de la communauté a été perdue.
  En pratique, cela ressemble au choix de Microsoft de laisser la communauté corriger les problèmes au lieu de les régler en interne.

  • Le fait que des éditeurs comme DevExpress et Progress Telerik n’investissent pas eux-mêmes dans les contrôles WinUI signifie aussi qu’ils ne croient pas au futur de WinUI.
    À ce stade, pour des apps d’entreprise, WinForms et WPF restent les options réalistes.
    Je n’ai jamais vu d’app réellement utilisée en production construite en WinUI 3.

  • Franchement, qui va sérieusement adopter un framework UI Microsoft aujourd’hui ?
    Les frameworks qui existaient déjà étaient déjà régulièrement abandonnés alors qu’ils n’étaient jamais vraiment terminés, laissés à moitié faits, puis on bascule vers un framework plus neuf et scintillant, ce qui les condamne à l’oubli.
    En fait, les frameworks open source cross-platform sont souvent plus aboutis en base et en fonctionnalités, et mieux maintenus.
    Ce WinUI restera probablement une autre victime du même sort qu’UWP : ouvert, puis oublié.

• On en est à ne plus savoir compter combien de frameworks UI existent sur Windows, c’est trop confus.
  Je me demande franchement ce qu’on attend de cette ouverture.
  Est-ce juste une image “open” bien entretenue, ou un réel bénéfice pour les devs ciblant Windows ?

  • WinUI est une version issue de l’UWP, et l’UWP est déjà une évolution de WinRT.
    L’intention de WinUI est claire, et c’est une tech qui a mûri longtemps (on en est à WinUI 3).
    MAUI est plus une solution cross-platform qu’un concurrent direct.
    Mais sans repenser tout l’OS, en particulier les outils d’administration, en WinUI, obtenir une confiance à long terme ne sera pas facile.

  • En lisant toutes les acronymes dans le commentaire précédent, j’ai d’abord cru que c’était satirique.
    WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt, etc.
    Le nombre de versions et de noms de frameworks est tellement mélangé que c’est déjà long et confus à l’énoncer.

  • Peut-être que Microsoft, encore une fois, se concentre sur la nouvelle tendance du moment (maintenant l’IA !) et cherche une façon d’écarter les technologies anciennes avec peu d’opposition.
    Les opposants me semblent probablement minoritaires.

  • En réalité, Windows a trois frameworks UI et deux seulement sont vraiment vivants.
    Les autres ne sont que des évolutions répétées de deux lignes : Win32/natif et WPF/Managed.
    WinUI3 est venu pour combler l’écart entre les deux.

  • À long terme, MFC demeure probablement l’option la plus durable.
    Les mises à jour sont arrêtées pour l’instant, mais il tiendra probablement encore vingt ans.

• J’aimerais que Microsoft ait simplement continué à faire évoluer WPF.
  Je l’ai utilisé pendant longtemps sur des projets variés ; la courbe d’apprentissage existe mais le Data Binding, le ViewModel et XAML restent bien exploitables.
  Il faut juste un certain nombre d’améliorations pour qu’il devienne parfait.
  J’ai aussi testé les nouveaux frameworks Microsoft ou des open source comme Avalonia, Uno, mais soit les exemples ne démarrent pas, soit la manière de développer ne colle pas.
  Je reviens donc au WPF que je connais.
  L’idée d’amélioration la plus importante pour WPF, c’est de faire le système de Data Binding via une génération de code .NET compile-time au lieu de la Reflection runtime.
  Ça permettrait un vrai build AOT, avec une amélioration de perf spectaculaire, plus une meilleure stabilité de type XAML et un meilleur support cross-platform, entre autres.
  J’ai voulu tenter le truc en open source, mais je n’ai pas eu le temps : il y a trop de choses à faire.

  • Le deuxième paragraphe cité correspond exactement à Avalonia.
    Avalonia gère déjà l’AOT, la détection d’erreur de binding au compile-time et les fonctionnalités cross-platform.
    Si vous n’avez pas vu les dernières MAJ, voyez Avalonia compile-time data binding docs et le projet XamlX.

  • Cette approche permet aussi de faire du trimming d’assemblies.
    Pour un déploiement autonome, la lib .NET embarquée dépasse souvent 200 Mo aujourd’hui, et cette méthode permettrait de bien réduire ça.

• Quand j’ai évalué WinUI3, j’ai trouvé l’expérience développeur catastrophique.
  Pour déboguer une app qu’on veut déployer, il fallait l’installer effectivement sur le système.
  Du coup, beaucoup d’entrées inutiles se mettaient dans le menu Démarrer et la base registre devenait sale.
  Et même dans le code d’exemple, un clic sur un bouton pouvait faire crasher immédiatement l’app.
  Quand je développe des apps Windows, je reste toujours sur Win32+WTL.

  • Le fait qu’il fallait installer l’app pour déboguer vient du choix d’un modèle “packagé”.
    Les fonctionnalités et la gestion des permissions l’exigent.
    macOS fonctionne de manière similaire : si l’app est packagée, elle doit aussi être installée, même si elle ne s’affiche pas dans Launchpad, elle reste trouvable via Spotlight.

• Comme beaucoup l’ont signalé, les frameworks UI Windows n’ont jamais été consolidés proprement et la confusion n’a fait qu’augmenter.
  Côté open source cross-platform, c’est malheureusement pareil.
  GTK a lui aussi été un peu chaotique un moment, et bien que Qt soit très fonctionnel, sa licence est trop lourde pour un usage pro.
  (L’élan des débuts de Nokia a disparu avec Elop chez MS, puis avec les changements de propriétaire de Qt, etc.)
  Même s’il existe de bonnes solutions sectorielles comme Dear Imgui, dans l’ensemble il n’existe presque pas d’alternative qui combine licence permissive, compilation native, bon layout de widgets et rendu 3D via Vulkan parmi les frameworks UI/widgets natifs ou cross-platform.

  • La critique d’Electron ou React Native repose souvent sur une culture “le web est mauvais”, mais en réalité, si on veut de la flexibilité plateforme, les alternatives sont quasi inexistantes.
    Microsoft aurait pu faire un vrai produit important dans ce domaine ; ses tentatives ont été trop tièdes, donc jamais vraiment abouties.

• J’aimerais qu’une barre des tâches native verticale revienne sur Windows 11.
  Cette fonction existait depuis Windows 98, et elle a disparu sur 11.
  Des outils tiers comme Windhawk (forcer la barre horizontale) ou StartAllBack (restauration de code Windows 10) existent, mais aucun n’est parfait.

  • Ouvrir un framework UI en open source ne fera pas que la barre des tâches s’enrichisse.
    Dans ce cas, l’apport externe doit passer par l’ouverture non du framework UI, mais de la barre des tâches elle-même (donc explorer.exe).

  • FYI, la barre verticale était déjà une option depuis Windows 95.

  • La barre des tâches relève d’explorer.exe.
    La communication autour de l’open source dont on parle ne concerne pas explorer.

  • Je doute que l’équipe Windows construise une vraie UI desktop native avec WinUI.

• Les travaux UI pour Windows se font aujourd’hui principalement avec Win32, GDI, DirectDraw.
  Grâce à CsWin32 et au C# moderne (ref returns), c’est bien plus accessible qu’avant.
  Avant, on devait généralement créer un projet séparé en C++, mais maintenant il suffit d’écrire dans un NativeMethods.txt uniquement les fonctions nécessaires, et le codegen se charge du reste.
  Win32 est clairement plus bas niveau que les autres frameworks UI, mais à l’inverse il est aussi beaucoup plus difficile pour Microsoft de le toucher ou de l’abandonner.
  À long terme, rien n’a survécu aussi durablement qu’une API de ce type.
  Le web ne serait même pas comparable sur le long terme.

  • Il reste pourtant beaucoup de zones où le C++ est indispensable.
    C’est en grande partie dû à l’attachement de l’équipe Windows au COM.
    Les Windows Runtime Components étaient une occasion de faire monter le niveau de l’écosystème .NET, mais cette opportunité a été manquée.
    Les extensions de shell, l’extension du menu contextuel etc. doivent être faites en C++ ; en .NET, cela implique en fin de compte de poser un stub C++ qui appelle un process .NET.

  • Les discussions sur les frameworks haut niveau sont moins intéressantes que celles sur les APIs bas niveau.
    Si l’on dit que toute la stack de rendu Windows repose sur GDI/DirectX, Win32 elle-même repose pourtant sur GDI au final.
    Pour discuter d’un stack UI Windows vraiment proche du métal, je pense qu’il faut mieux partir de DirectX.

  • Vu du point de vue utilisateur, Win32 est déjà suffisamment haut niveau.
    Jusqu’ici, c’est la seule toolkit capable de dessiner correctement des boutons, barres de défilement, etc.

  • J’aimerais qu’une vraie bonne communauté se charge de construire un framework pour le dev natif Windows.
    Réalité : une telle communauté n’est malheureusement pas assez grosse.

• Ce que je regrettais le plus dans l’ancien développement UI Windows,
  c’était de faciliter la création d’apps qui semblaient “faites par Microsoft”, sans à-coup.
  Depuis l’arrivée des technologies web, la cohérence de l’expérience UI Windows s’est fortement dégradée.
  Le problème n’est pas seulement que Microsoft n’ait pas mis à jour les apps existantes, mais aussi qu’elle n’ait pas fourni de libs adaptées aux guidelines dans les nouveaux outils.
  Ça commence avec Vista, et même la documentation MSDN s’appauvrit progressivement, avec moins d’exemples du type “essayez cette fonctionnalité comme ceci”.