IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Microsoft révèle la feuille de route pour WinUI 3.0 qui va transformer l'apparence des applications Windows 10

Le , par Sandra Coret
15 commentaires

137PARTAGES

5  0 
Microsoft a présenté ses plans pour WinUI 3.0, qui devrait être livré dans le courant de l'année.

Décrite comme la "plate-forme moderne d'interface utilisateur native de Windows", WinUI est la bibliothèque de contrôles et de styles Fluent basée sur le langage C++ qui permet aux développeurs de créer une nouvelle génération d'applications.

La société a communiqué les détails de la feuille de route de WinUI, expliquant comment la version 3.0 se développera en un cadre UX complet. Elle s'inscrit dans le cadre du projet Reunion qui voit Microsoft rassembler un ensemble unifié d'outils et d'API pour faciliter le développement d'applications pour différents appareils Windows 10.


L'évolution de WinUI 3.0 signifie qu'il sera disponible pour tous les types d'applications Windows pour être utilisé comme couche d'interface utilisateur, y compris Win32 et UWP.

L'aperçu 4 de la plate-forme doit être publié plus tard ce mois-ci, et le graphique ci-dessous montre ce que Microsoft a prévu pour l'année à venir :




Source : Microsoft

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Microsoft annonce qu'il a apporté quelques améliorations importantes à Visual Studio 2019 16.8, afin de faciliter la migration de projets d'envergure de .NET Framework vers .NET 5

Windows Terminal Preview 1.6 inclut la version alpha de la nouvelle interface utilisateur de paramètres et donne la possibilité de définir des actions à activer au démarrage

Microsoft Edge 88 est livré avec de nouvelles fonctionnalités de sécurité, parmi lesquelles un générateur de mot de passe et un outil pour contrôler si vos informations de connexion ont fuité

Une erreur dans cette actualité ? Signalez-nous-la !

15 commentaires
Commenter Signaler un problème
marc.collin
Avatar de marc.collin
Membre émérite https://www.developpez.com
Le 11/02/2021 à 19:13
Citation Envoyé par defZero Voir le message
Donc avec le projet Reunion de MS on a une nouvelle façon "Officiel" de faire des UI sous Windows en plus de Win32, WinForms ou WPF on a WinUI .
Et après, MS ce demande pourquoi les dev sous macOS sont de plus en plus demandé en Entreprise.
Vous faite du Apple, vous êtes sous lock-in comme avec MS, mais vous avez au moins une expérience de dev unifier et pas 3 ou 4 truc pour faire la même chose de manière différente dans un IDE (obligatoire) qui pèse 12GB voire plus en fonction de ce que vous souhaiter développer.
Et pourtant j'ai horreur de l'attitude d'Apple vis à vis de ses clients, mais côté dev, c'est plus simple .
as-tu suivi un peu le développement sous macos?

il y a eu changement à mainte reprise, niveau langage, framework

swift
cocoa
objectif-c
metal
opengl

il y a une question de rétrocompatibilité........
4  0 
redcurve
Avatar de redcurve
Inactif https://www.developpez.com
Le 12/02/2021 à 7:35
Citation Envoyé par defZero Voir le message
Oui, enfin Objective-C date des années 80 et a été utilisé jusqu'en 2006-2007, après quoi Apple est passé à Swift qui est quand même un langage moins casse gueule à utiliser.
1 changement en 30 ans, ça va c'est pas Java / .NET .

Ensuite le passage de Carbon à Cocoa, c'est pareille, un changement tous les 30 ans, c'est gérable, sans compter que Carbon n'a servie que de couche de "portage" vers Cocoa pour les appli macOS 8/9, donc ce n'est pas une révolution absolue non plus.

Quand à l'adoption de Metal vs OpenGL, ça c'est majoritairement du au fait qu'Apple voulait une API unifier sur iOS/IPadOS/macOS et que les capacité des CG moderne nécessite une architecture de dev qu'OpenGL ne prend pas en compte ce pour quoi Khronos a sortie Vulkan et MS DX12.

Mais encore une fois, Apple fait un choix et s'y tient pendant un bon moment (~20-30 ans) alors que de l'autre côté, MS à sortie combien d'API d'UI ou de Framework .Net diffèrent en à peine 10 ans ?
Appel ne se tiens à rien du tout, ils foutent régulièrement tout en l'air parce qu'ils n'ont pas de vrai client qui ont besoin de stabilité et de rétrocompatibilité.
4  0 
stardeath
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 11/02/2021 à 22:30
Citation Envoyé par defZero Voir le message
...
apple fait en sorte de casser toutes les applis à chaque micro changement de techno ; parce que y a aussi l'abandon du 32 bits, l'abandon du power pc, bientôt l'abandon du x86, l'abandon des anciens os et les technos associées que ça soit sonore, réseaux ou affichage (que ça soit sur desktop ou mobile, rien n'est pérenne) ...
bref non, apple, c'est max 5 ans de stabilité, contre aujourd'hui encore des applis/apis win32 de windows 3.1/95 qui tournent toujours.
2  0 
stardeath
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 13/02/2021 à 1:08
Citation Envoyé par defZero Voir le message
C'est de la mauvaise fois de citer le changement d'architecture comme une volonté d'Apple et encore plus d'appeler ça des "micro changements".
tu te fous de la tronche de qui là? je ressors ce que tu as dit : "Mais encore une fois, Apple fait un choix et s'y tient pendant un bon moment (~20-30 ans)"
on te prouve que non, c'est même plutôt le contraire, et là tu essaies de dire que c'est pas de la faute d'apple? au final, le changement il est là, et apple, avec la puissance financière qu'il a pourrait faire en sorte de ça change moins, mais vu que ça l'arrange que les gens rachètent tout ...

donc ici, la mauvaise foi, c'est toi.

Citation Envoyé par defZero Voir le message
Quant à l'abandon des anciens OS & des technos associer, encore une fois, qui parmi les dev ici présent n'as jamais repris un projet de A à Z en s'endormant sur l'interopérabilité avec des technos qui n'ont plus de sens ?
donc tu confirmes bien ce qui a été dit, apple c'est très loin d'être pérenne, tu le dis toi même : "ces technos qui n'ont plus de sens".
de plus, il y a une grande différence entre abandonner le support de l'ancien (très bien pour perdre des clients, si tu fais ça à l'emporte pièces) et la politique d'apple où cet ancien devient carrément persona non grata, le tout en mettant la responsabilité de son merdier aux développeurs tiers, le tout saupoudré avec un petit marché captif et un store anti-concurrentiel, ça nous donne une bonne recette d’œillères.

je vais passer sur le reste de ton discours, entre approximation et *auto censure*, j'ai autre chose à faire qu'à corriger ça.

mais bon, tu fais ce que tu veux après tout, si tu aimes cette politique d'apple ; par contre vient pas reprocher tes méconnaissances aux autres.
2  0 
chrtophe
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 12/02/2021 à 19:14
c'est du Win16 et actuellement sans VM impossible de faire tourner des applis Win16 sur Windows 10
Cela est dû à l'architecture des CPU Intel, pas à Windows. Avec un CPU Intel en mode 64 bits, il n'est pas possible d’exécuter une application 16 bits. Une version Windows 10 32 bits pourra exécuter une appli 16 bits. Un processeur Intel 64 bits peut exécuter un OS 32 bits. E t il reste possible de faire une VM.

La rétro-compatbilité est là. Maintenant, quel est l’intérêt d’utiliser encore dbase par exemple. Maintenant je conçois qu'elle soit pratique pour des produits super couteux mais au bout d'un moment il faudra bien évoluer. Et rétro-compatibilité veut pas dire que ça marche à toute épreuve.

apple a supprimé la compatibilité des applis 32 bits depuis Catalina, obligeant beaucoup de gens à racheter des applications. Mais ça ce conçoit par le changement de CPU qui vient d'avoir lieu. Et là du coup, pas possible d"envisager la virtualisation. Leur émulateur Intel Rosetta fait le job. Je pense que ça aurait été beaucoup trop de travail d'en faire un compatible 32 bits.
1  0 
chrtophe
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 13/02/2021 à 14:20
mais faut quand même avouer qu'un projet commencé y a 20 ans sous winform, on s'attend à ce qu'il tourne toujours correctement sous windows
Maintenant, 20 ans c'est tellement vieux en informatique, que si ça fonctionne plus au bout de 20 ans, c'est pas non plus surprenant. Je ne m'attend pas non plus à ce qu'un poste à galène fonctionne encore.
1  0 
defZero
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 11/02/2021 à 19:38
as-tu suivi un peu le développement sous macos?

il y a eu changement à mainte reprise, niveau langage, framework

swift
cocoa
objectif-c
metal
opengl

il y a une question de rétrocompatibilité........
@marc.collin
Oui, enfin Objective-C date des années 80 et a été utilisé jusqu'en 2006-2007, après quoi Apple est passé à Swift qui est quand même un langage moins casse gueule à utiliser.
1 changement en 30 ans, ça va c'est pas Java / .NET .

Ensuite le passage de Carbon à Cocoa, c'est pareille, un changement tous les 30 ans, c'est gérable, sans compter que Carbon n'a servie que de couche de "portage" vers Cocoa pour les appli macOS 8/9, donc ce n'est pas une révolution absolue non plus.

Quand à l'adoption de Metal vs OpenGL, ça c'est majoritairement du au fait qu'Apple voulait une API unifier sur iOS/IPadOS/macOS et que les capacité des CG moderne nécessite une architecture de dev qu'OpenGL ne prend pas en compte ce pour quoi Khronos a sortie Vulkan et MS DX12.

Mais encore une fois, Apple fait un choix et s'y tient pendant un bon moment (~20-30 ans) alors que de l'autre côté, MS à sortie combien d'API d'UI ou de Framework .Net diffèrent en à peine 10 ans ?
2  2 
sergio_is_back
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 12/02/2021 à 8:13
Citation Envoyé par stardeath Voir le message
apple fait en sorte de casser toutes les applis à chaque micro changement de techno ; parce que y a aussi l'abandon du 32 bits, l'abandon du power pc, bientôt l'abandon du x86, l'abandon des anciens os et les technos associées que ça soit sonore, réseaux ou affichage (que ça soit sur desktop ou mobile, rien n'est pérenne) ...
bref non, apple, c'est max 5 ans de stabilité, contre aujourd'hui encore des applis/apis win32 de windows 3.1/95 qui tournent toujours.
Windows 3.1 c'est pas du Win32 au niveau des API c'est du Win16 et actuellement sans VM impossible de faire tourner des applis Win16 sur Windows 10

Windows 95,98 et les premières versions de Windows NT (jusqu'à 4.0 il me semble) ont gardé la compatibilité Win32/Win16 mais ce n'est plus le cas à partir de Windows 2000
0  0 
stardeath
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 12/02/2021 à 11:25
Citation Envoyé par sergio_is_back Voir le message
...
j'ai bien parlé de win32 et pas de win16, tu peux regarder, le plus lointain que tu puisses faire tourner du win32 c'est sous win 3.1 avec les extensions win32s.
0  0 
foetus
Avatar de foetus
Expert éminent sénior https://www.developpez.com
Le 12/02/2021 à 20:24
Citation Envoyé par defZero Voir le message
Et l'introduction de NTFS avec ces dir/filenames en UTF-16, c'était que du bonheur pour les portages .
Je pense qu'au tout départ, c'était UCS-2

Citation Envoyé par chrtophe Voir le message
Cela est dû à l'architecture des CPU Intel, pas à Windows. Avec un CPU Intel en mode 64 bits, il n'est pas possible d’exécuter une application 16 bits. Une version Windows 10 32 bits pourra exécuter une appli 16 bits. Un processeur Intel 64 bits peut exécuter un OS 32 bits.
je pense que c'est + 1 problème de mode réel et mode protégé. Le mode protégé avec 1 processeur 16 bits semble exister mais apparemment c'est assez rare
0  0 
Commenter Signaler un problème