Le Project Reunion de Microsoft supporte désormais WinUI 3, WebView 2 et .NET 5

Le Project Reunion de Microsoft supporte désormais WinUI 3, WebView 2 et .NET 5

Le Project Reunion de Microsoft supporte désormais WinUI 3, WebView 2 et .NET 5

Reunion est un important projet pour Microsoft. Il consiste à décorréler UWP (Universal Windows Platform) et Win32 de Windows pour les faire travailler ensemble. Les développeurs peuvent alors se servir des deux jeux d’API sans se soucier (ou presque) de la version de Windows.

Ce dernier point est crucial pour la firme, qui dit recevoir régulièrement la même plainte des développeurs, depuis longtemps : ils doivent attendre qu’une version de Windows se soit suffisamment diffusée auprès des utilisateurs pour considérer l’exploitation de ses nouveautés, soit un à deux ans en moyenne

La nouvelle mouture 0.5 est présentée par l’éditeur comme une étape majeure vers la version 1.0. Elle apporte le support de .NET 5, WinUI 3 et WebView 2. En outre, cette version 0.5 s’accompagne d’un support complet, de type production. Elle prend toutes les versions de Windows 10 en charge depuis la 1809 (branche LTSC).

L’arrivée de WinUI 3 en particulier est une étape importante, puisque la bibliothèque intègre tous les éléments modernes d’interface pour Windows 10. Sun Valley, qui serait le nom de code du remaniement graphique dans la 21H2 de Windows 10, consisterait justement à passer toute l’interface à la moulinette WinUI 3. Pour les développeurs, l’intégration peut se faire depuis un projet neuf, ou progressivement dans un existant.

Il reste toutefois des limitations. Les développeurs ne peuvent ainsi produire que des applications Desktop classiques et non UWP. Il n’y a pas non plus de support pour les fenêtres multiples. La version Preview de Reunion 0.5 proposait ces capacités, mais elles n’ont a priori pas eu le niveau de qualité requis pour la finale.

Cette nouvelle mouture réclame Visual Studio 2019 16.10 Preview pour fonctionner. Techniquement, la 16.9 supporte Reunion, mais n’est pas compatible avec les outils WinUI 3.

Commentaires (6)



Il n’y a pas non plus de support pour les fenêtres multiples. La version Preview de Reunion 0.5 proposait ces capacités, mais elles n’ont a priori pas eu le niveau de qualité requis pour la finale.




C’est triste qu’en 2021, on en soit à attendre le “support pour les fenêtres multiples”. Et c’est pas du tout une critique à l’encontre de Microsoft. Je suis juste abasourdi qu’avec les technos/frameworks “modernes” on, n’arrive plus à faire des GUI aussi facilement qu’il y a 10 ou 20 ans.



La quasi décennie du “tout web / tout mobile” qu’on vient de traverser a réduit à néant l’évolution des frameworks sérieux pour faire des applis “purement desktop” à peu près multiplateformes. Je sais que Qt/Gtk/Swing etc … ne sont pas morts, mais si tu fais pas du C++ ou du Java, ça tourne quand même vite aux bindings foireux et incohérents tellement ces libs ont stagné.



Ca me manque quand même un peu les applis “natives” qui s’ouvraient instantanément sur des configs bien plus faiblardes que ce sur quoi je bosse aujourd’hui. J’ai littéralement une machine de guerre pour le taf, et Spotify par exemple met quasiment 3 secondes à s’ouvrir. C’est sûr que c’est rien de bien insupportable. Mais bon sang, pour le même usage, les premières versions en Qt s’ouvraient instantanément sur un Athlon XP déjà vieux à l’époque.


C’est un gâchi, on détourne les langages de leur usages premiers (qui a dit python?) et on a le laisser faire qui laisse les éditeurs faire leur sauce.



Mais en plus il est relativement abérant de voir que le coté universitaire ne se manifeste pas plus que cela et que rien n’émerge vraiment. Si ce n’est pour tenter de réinventer la soupe (qui a dit PWA).



jpaul a dit:


C’est triste qu’en 2021, on en soit à attendre le “support pour les fenêtres multiples”. Et c’est pas du tout une critique à l’encontre de Microsoft. Je suis juste abasourdi qu’avec les technos/frameworks “modernes” on, n’arrive plus à faire des GUI aussi facilement qu’il y a 10 ou 20 ans.



La quasi décennie du “tout web / tout mobile” qu’on vient de traverser a réduit à néant l’évolution des frameworks sérieux pour faire des applis “purement desktop” à peu près multiplateformes. Je sais que Qt/Gtk/Swing etc … ne sont pas morts, mais si tu fais pas du C++ ou du Java, ça tourne quand même vite aux bindings foireux et incohérents tellement ces libs ont stagné.



Ca me manque quand même un peu les applis “natives” qui s’ouvraient instantanément sur des configs bien plus faiblardes que ce sur quoi je bosse aujourd’hui. J’ai littéralement une machine de guerre pour le taf, et Spotify par exemple met quasiment 3 secondes à s’ouvrir. C’est sûr que c’est rien de bien insupportable. Mais bon sang, pour le même usage, les premières versions en Qt s’ouvraient instantanément sur un Athlon XP déjà vieux à l’époque.




C’est probablement parce qu’on détourne des langages qui n’ont pas été pensés pour ça.



Par exemple, tu parles de Java : Java a toujours mis plus de temps à démarrer que C++, même si techniquement, si tu as le même traitement qui tourne sur une même durée, tu n’auras aucune différence.



Là, j’imagine que Spotify est codé en techno web, donc HTML5 + Javascript, sauf que du coup, tu charges l’application, qui charge le moteur de rendu (et t’as pas de chance s’il s’appelle Electron :D), qui charge la page - probablement distante pour simplifier les mises à jour.



Bon….



Après, le coup des fenêtres multiples, moi ça me fait surtout penser à la suite Office incapable d’ouvrir un document s’il porte le même nom (mais pas le même chemin) qu’un document déjà ouvert.



jpaul a dit:


La quasi décennie du “tout web / tout mobile” qu’on vient de traverser a réduit à néant l’évolution des frameworks sérieux pour faire des applis “purement desktop” à peu près multiplateformes.




En l’absence d’entente entre les éditeurs de linux/win/mac pour définir une plateforme d’exécution commune, les acteurs du marché ont décidé à leur place: la plateforme d’exécution commune sera chromium.



Certes c’est horriblement lent et lourd, mais ca répond au problème de base. Pour compenser, on prend une config plus musclée. De toutes façons, c’était nécessaire à chaque évolution d’OS.



Microsoft semble avoir embrassé le mode “tout web”. Toutes leurs annonces, évolutions, rachats récents vont dans ce sens.



Reste encore leur arlésienne de l’API ultime de développement unifié. Ca fait 25 ans que Ms crée puis abandonne des trucs pour virer win32 mais plus personne n’y croit vraiment.



Je me vois mal conseiller a qqn de miser sur la toute dernière techno/api de windows pour faire la killing app de 2022. Je lui conseillerait plutôt des frameworks html/javascript a la vue.js ou angular.


On est bien d’accord sur tous les points. Mais c’est triste. Et ça donne l’impression d’un beau gaspillage.


Il faut les dénoncer aux écologistes : ça doit en faire des gaz à effet de serre, toute cette puissance électrique nécessaire à faire tourner ces trucs peu performants.


Fermer