Discussion :

[Sandra Coret]

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

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é

[defZero]

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 .

[marc.collin]

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é........

[defZero]

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 ?

[stardeath]

...

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.

[redcurve]

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é.

[sergio_is_back]

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

[stardeath]

...

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.

[defZero]

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.

@stardeath

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".
C'est pas de la faute à Apple si IBM n'as pas su ce mettre au niveau d'Intel/AMD en sont temps ?
Pareillement pour le passage à ARM, si Intel/AMD s'endorme sur la R&D pendant 20 ans (pourtant Intel à les moyens, je croit) ?

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 ?
Combien ici développent en pure C89 ou pour Python 2.x sur des nouveaux projets pour garder une compatibilité avec la stack existante ?
(S'il y en a, je suis désoler pour eux )

Qui veut du FireWire800 quand il peut avoir du TB3/4, ou un clavier en PS/2 quand il peut avoir de l'USB ?
C'est comme vouloir reprocher à Apple/Intel de pousser le Thunderbolt (rétro compatible USB pour le coup) contre l'USB ou encore maintenir le connecteur USB type A/B et leurs variantes Mini/Micro, quand le Type C existe (et est rétro compatible également), ça n'as pas de sens.

A vouloir maintenir la rétrocompatibilité à tous prix ont abandonne forcément l'innovation.
Donc où est la limite ?
Vous préférez vos SSD NVMe sur PCIe 4 qui plafonnes à 7 GB/s ou vos HDD en PATA à 150 Mo/s (et encore, je croit pas que l'IDE puisse atteindre cette vitesse) ?

Là dessus, le seule reproche que je ferais à Apple, c'est de pousser le TB4 tout en voulant conserver le Lightning et/ou le (future nouveau)MagSafe.
Deux / trois techno pour le même usage, ça n'as aucun intérêt, à part faire passer à la caisse (ce dont Apple est roi ).

Quand à la rétrocompatibilité à toute épreuve de Windows, je regrette, mais pour avoir vu pas mal de logiciel Win16/Win32 ne fonctionnent tout simplement plus avec "le mode de compatibilité", je comprend facilement pourquoi des Usines et autres sont obligé de faire tourner des VM (ou des postes) sous Windows 95.
D'ailleurs Windows 95 est la première version à couper la rétrocompatibilité avec les API 16 bits et pourtant à ne supporter que le FS VFAT16 au lancement.
Paradoxale quand même sachant qu'il supportait également les noms de fichiers en 255 caractère et qu'il utiliser MS-DOS comme "couche de compatibilité" pour les apps Win16.
Les appels d'API Win16 avec les noms de fichier au format 8.3 c'était folko.
Et l'introduction de NTFS avec ces dir/filenames en UTF-16, c'était que du bonheur pour les portages .

[chrtophe]

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.

[foetus]

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

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

[chrtophe]

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

Non. Le fonctionnement de la pagination en 64 bits n'est pas compatible 16 bits. Quand on parle de 16 bits avec Windows, c'est aussi en mode protégé. Seule version Windows 1 et 2 pouvait fonctionnait en mode réel.

[stardeath]

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.

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.

[chrtophe]

De ce que j'ai vu, la rétrocompatibilité est moindre chez Apple. Maintenant une vieille appli codée avec les pieds sous PC ne fonctionnera pas non plus. D'un autre coté, changer de CPU 3 fois depuis 20-30 n'aide pas. Par contre, Apple a inséré à chaque fois une couche de compatibilité. La migration de Motorola vers PowerPC s'est passé sans trop de problèmes (attention je je dis pas qu'il n'y en a pas eu), et de PowerPC vers Intel non plus grâce notamment à Rosetta. Le passage Intel vers M1 est trop récent pour juger. De ce que j'en ai vu, ça fonctionne, mais avec des appls assez récentes (pas toutes portées vers M1), applis ayant du être mises à jour il n'y a pas très longtemps suite à l'arrêt du support du 32 bits. Par contre plus de virtualisation pour ceux qui utilisent.

Sur l'aspect matériel, un mac se garde statistiquement plus longtemps et se déprécie peu par rapport à un PC, mais par contre est quasi-irréparable.

[stardeath]

...

Évidemment que tout n'est pas aussi noir ou blanc, 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. La même assertion ne vaudra pas pour mac (pas les mêmes clients/besoins etc.)

On a régulièrement ici des voix qui s'élèvent quand crosoft pond une tablette sans win32, là c'est inadmissible.

Sur l'aspect matériel, un mac se garde statistiquement plus longtemps et se déprécie peu par rapport à un PC, mais par contre est quasi-irréparable.

En général l'un ne va pas sans l'autre, rien que pour la combinatoire pour faire les tests de compatibilité et d'intégration.

[chrtophe]

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.