Merci d'avoir écouté les commentaires de la communauté. Je suis vraiment excité pour WinUI 3.0 (Win32 + WinUI + C++). Cela ressemble au cadre que nous attendions! RIP GDI

(Modèle d'application Win32) + (WinUI 3.0 UI) + (langage .NET ou C++)

Il s'agirait donc essentiellement de l'interface utilisateur UWP, mais sans le cycle de vie et le bac à sable semblables à ceux d'un téléphone ? Cela semble intéressant pour les applications de bureau, alors - je vais expérimenter cela.

Merci pour la mise à jour, et j'espère que d'autres mises à jour viendront à mesure que l'ensemble de fonctionnalités initial de WinUI 3.0 est verrouillé, et tous les nouveaux contrôles ou fonctionnalités de contrôle qui ont été proposés, qui peuvent être intégrés à WinUI 3.0.

Oh, et une documentation sur le fonctionnement de WinUI dans Desktop et sur sa différence avec UWP, WPF et Win32 serait très utile pour anticiper le nombre incalculable de questions qui se poseront.

Peut-être une belle matrice de ce qui est inclus avec quelle combinaison de frameworks et d'API, ainsi que les diagrammes d'architecture que nous avons obtenus chez Build !

Vous êtes incroyables, merci pour tout !
La section xplat a fait ma journée, surtout que Uno est sur le radar.

Notre objectif est toujours Windows 10 et 8.1, mais nous entendons les commentaires selon lesquels certains d'entre vous ont encore des utilisateurs et des clients sur Win7 et nous évaluerons le marché et les options au fil du temps.

En supposant que cette implantation du cadre d'interface utilisateur soit conçue avec l'idée de portabilité, au moins suffisamment pour que son noyau d'interface utilisateur (rendu / entrée) puisse fonctionner sous n'importe quel système d'exploitation Windows prenant en charge .NET Core 3+ quelles limitations sur Windows 7 y aurait-il même être? On dirait que la plupart des fonctionnalités que les gens utilisent sur le bureau fonctionneraient simplement et pour celles qui ne le font pas, les empêcheraient peut-être de faire partie du système d'interface utilisateur principal et les conserveraient dans des packages spécifiques à la plate-forme tels que (Win10, Win8.1, Win7 Nugets, etc.).

De plus, s'il y avait un XAML multiplateforme qui avait la même apparence sur tous les appareils (Win32, Android, iOS et WASM) comme vous pouvez le faire avec HTML (mais pas Xamarin malheureusement), mon entreprise aurait sauté dessus il y a des années.

Aussi heureux que vous considériez cela comme un "marathon (un excellent jeu Bungie aussi)". Moins il y a de fragmentation dans l'espace XAML, mieux c'est pour tout le monde et prendre de nombreux raccourcis vous ramènera là où vous avez commencé ;)

une documentation sur le fonctionnement de WinUI dans Desktop et sur sa différence avec UWP, WPF et Win32 serait très utile

Nous y travaillons et partagerons plus au fur et à mesure que cela se développe !

En supposant que cette implantation du cadre d'interface utilisateur soit conçue avec l'idée de portabilité, au moins suffisamment pour que son noyau d'interface utilisateur (rendu / entrée) puisse fonctionner sous n'importe quel système d'exploitation Windows prenant en charge .NET Core 3+ quelles limitations sur Windows 7 y aurait-il même être?

@zezba9000 WinUI n'utilise pas .NET, et vous n'avez pas nécessairement besoin d'utiliser .NET Core avec WinUI : c'est un framework natif construit sur les API du système d'exploitation, et il s'appuie sur de nouvelles fonctionnalités dans Win8/Win10 qui n'étaient pas présentes dans Win7 - dans certains cas pour les fonctionnalités de base, pas seulement pour les fonctionnalités complémentaires de niveau supérieur telles que des contrôles spécifiques.

une documentation sur le fonctionnement de WinUI dans Desktop et sur sa différence avec UWP, WPF et Win32 serait très utile

Nous y travaillons et partagerons plus au fur et à mesure que cela se développe !

En supposant que cette implantation du cadre d'interface utilisateur soit conçue avec l'idée de portabilité, au moins suffisamment pour que son noyau d'interface utilisateur (rendu / entrée) puisse fonctionner sous n'importe quel système d'exploitation Windows prenant en charge .NET Core 3+ quelles limitations sur Windows 7 y aurait-il même être?

@zezba9000 WinUI n'utilise pas .NET, et vous n'avez pas nécessairement besoin d'utiliser .NET Core avec WinUI : c'est un framework natif construit sur les API du système d'exploitation, et il s'appuie sur de nouvelles fonctionnalités dans Win8/Win10 qui n'étaient pas présentes dans Win7 - dans certains cas pour les fonctionnalités de base, pas seulement pour les fonctionnalités complémentaires de niveau supérieur telles que des contrôles spécifiques.

Pour la compatibilité avec Windows 7, il faudrait un tiers pour créer son propre moteur de rendu compatible pour le XAML, ainsi qu'une sorte de Shim alternatif pour toutes les API de niveau de système d'exploitation nécessaires.

À l'heure actuelle, il n'y a aucune idée si cela est possible - l'espoir est que lorsque les bits WinUI sont supprimés du système d'exploitation, ils sont placés dans le projet open source d'une manière qui permettra à d'autres plates-formes de fournir une sorte de composant de compatibilité. Pensez à Xamarin, Uno ou .Net Core avec un moteur de rendu personnalisé.

c'est un framework natif construit sur les API du système d'exploitation, et il s'appuie sur de nouvelles fonctionnalités dans Win8/Win10 qui n'étaient pas présentes dans Win7 - dans certains cas pour les fonctionnalités de base

Dans mon esprit, ce qui constitue une "fonctionnalité de base" ne serait pas quelque chose qui repose sur les spécificités du système d'exploitation, à part bien sûr le rendu et la saisie. Ce qui, dans ces cas, serait des couches d'abstraction que tout le monde peut étendre. À un niveau fondamental, un devrait en théorie être capable de rendre l'interface utilisateur avec un logiciel de rendu personnalisé et de faire Input avec un backend XInput personnalisé avec un curseur virtuel si vous le souhaitez. Si vous pouvez faire ce genre de modularité, vous pouvez à peu près tout faire et étendre la prise en charge de la plate-forme devient extrêmement facile (comme c'est le cas dans les jeux). Vous passez un peu plus de temps dans ce domaine et sur la route, tout demande beaucoup moins d'efforts. Si WPF XAML avait été conçu de cette manière, il aurait pu être simplement pris et utilisé dans les applications UWP. Sinon, la dette technique deviendra simplement une boucle sans fin.

Des éléments tels que la prise en charge des icônes de la barre d'état système, etc. pourraient se trouver dans un package "Fonctionnalités de base de Windows WinUI (Win7-Win10)". Des éléments tels que les notifications push pourraient se trouver dans un package "Fonctionnalités étendues de Windows WinUI (Win8-Win10)".

J'espère que cela a du sens.

@mdtauk , @zezba9000 tout est théoriquement possible, et nous avons beaucoup d'expertise en abstraction de plate-forme dans l'équipe. Comme pour tout, cela se résume au coût, au calendrier et aux bénéfices attendus

En plus des coûts de développement et de test (qui s'étendraient à des domaines potentiellement non évidents, par exemple en s'assurant que tout fonctionne avec les anciennes technologies d'assistance), nous devons également prendre en compte les coûts de support sur de longues périodes.

Vous attendez-vous à avoir de nouveaux clients sur Win7 en 2020+ ? Les commentaires et les cas d'utilisation précis nous aident à établir des priorités.

En plus des coûts de développement et de test (qui s'étendraient à des domaines potentiellement non évidents, par exemple en s'assurant que tout fonctionne avec les anciennes technologies d'assistance), nous devons également prendre en compte les coûts de support sur de longues périodes.

Vous attendez-vous à avoir de nouveaux clients sur Win7 en 2020+ ? Les commentaires et les cas d'utilisation précis nous aident à établir des priorités.

@jesbis Je ne vois pas beaucoup d'avantages à ajouter la compatibilité à Win7 pour WinUI 3.0 - Linux, Android, iOS, iPadOS et MacOS, cependant, peut être bénéfique pour fournir une solution multiplateforme, qui ne repose pas sur des cadres d'interface utilisateur natifs.

@mdtauk
@jesbis Je ne vois pas beaucoup d'avantages à ajouter la compatibilité à Win7 pour WinUI 3.0 - Linux, Android, iOS, iPadOS et MacOS, cependant, cela peut être bénéfique pour fournir une solution multiplateforme.

D'accord avec ça. J'ajouterais juste l'assemblage Web, pour moi c'est encore plus essentiel que Linux.

Vous attendez-vous à avoir de nouveaux clients sur Win7 en 2020+ ? Les commentaires et les cas d'utilisation précis nous aident à établir des priorités.

Non, mon entreprise ne le fait pas. Je donnais davantage un argument de conception dans un domaine avec lequel j'ai vu XAML lutter dans toutes ses itérations (de mon point de vue), mais je vois tout à fait pourquoi MS ne voudrait pas y passer du temps. Cependant, ce serait cool si WinUI était suffisamment capable pour que d'autres puissent faire ce travail s'ils en avaient besoin (ce qui a tendance à arriver, j'ai remarqué) sans tomber dans un trou de lapin de dépendances Windows comme c'est le cas avec WPF maintenant.

Pour être clair sur ce que mon entreprise aimerait voir, le support Android et WASM serait un peu plus officiel que UNO (et il y a 3 ans). Nous fabriquons un logiciel de gestion qui régit l'état d'un ensemble d'ordinateurs locaux et de configurations système impliquant généralement un grand besoin d'API Win32 (UWP ne fonctionnerait jamais pour nous mais nous aimons l'interface utilisateur à cause des erreurs de compilation contrairement aux systèmes de construction HTML) et notre les clients + nous ont besoin d'expériences d'interface utilisateur Win32 + Android + navigateur qui ont une expérience et une sensation uniformes. HTML n'est qu'un gros problème car il ajoute une abstraction et une complexité inutiles qui n'auraient pas besoin d'être là car notre base de code principale est en C#.

J'espère que c'est un meilleur retour pour vous.

De plus, oui, WASM est la plus grande cible que nous voudrions par rapport à toute autre plate-forme. DE LOIN!!
Comme il résout notre problème Android / iOS / mobile ainsi que les problèmes de portail Web.

Merci d'avoir écouté les commentaires!

Desktop + WASM sera de l'or !

Wow, merci pour le cri, @jesbis ! Totalement inattendu et très apprécié et respecté. ??

La discussion autour de Windows 7 est un peu distrayante, car la quantité d'efforts (sans parler du coût) entraînerait un retard important pour WinUI 3.0. Windows 7 arrive en fin de vie en janvier et nous encourageons tous les clients à passer à Windows 10. Mes clients peuvent ne pas s'aligner sur les autres ici, mais même Windows 8.1 n'est pas une plate-forme qui nous intéresse.

Plutôt content de la mise à jour. Les cibles à venir pour WinUI semblent très brillantes et prometteuses ! Même la section Xplat était quelque chose à laquelle je ne m'attendais pas mais qui est très bien accueillie. J'attendrai avec impatience d'utiliser les améliorations ainsi que les goodies en magasin pour WinUI.

Merci à l'équipe pour la transparence.

Je voudrais mentionner l'importance des logiciels métiers pour aider les gens à résoudre divers problèmes.

J'ai travaillé pendant un certain temps avec l'outil Lightswitch et j'ai eu un gain significatif en temps de construction. Le développement rapide d'applications a été très prometteur pour les applications LOB. Mais avec la guerre des brevets aux États-Unis qui est très prise au sérieux, il a fallu que le produit soit terminé.

Nous savons que nous avons INotifyDataErrorInfo pour la prochaine livraison. Mais ce serait merveilleux si WinUI disposait de ressources RAD pour les livraisons futures comme les versions 3.x et suivantes.

merci l'équipe, j'ai hâte d'être au crayon dans l'assemblage web. cela fera ma journée, mon année et ma décennie et placera MS au sommet de la pile technologique. WinUI + Xamarin + WASM + .NET => pure merveille !!

@jesbis Merci pour cette mise à jour. Bonne équipe de travail :+1:. Comprenant qu'il est encore tôt, quand pensez-vous que nous verrons le jalon WinUI 3.0 créé et les problèmes marqués contre lui ?

Quand pensez-vous que nous verrons le jalon WinUI 3.0 créé et les problèmes associés à celui-ci ?

@shaggygi Bonne question ! Je viens de le créer :

Jalon WinUI 3.0

C'est génial les gars !

Petite question : déplacer Windows.UI.Composition vers Microsoft.UI.Composition, est-ce plus proche de 2.2 ou 3.0 ?
Et dans le délai pour s'y attendre, cela me prendrait-il 2-3 mois ou plus, lorsque la 3.0 sera disponible ?

À l'avenir, lorsque vous parlerez d'années (comme dans « d'ici la fin de l'année »), pouvez-vous être clair sur les années civiles et les années financières [Microsoft].
Il est facile d'avoir de la confusion lorsque cela n'est pas explicitement indiqué et j'ai connu des occasions où cela a amené les gens à croire que les choses arrivent 6 mois plus tôt que prévu.

Déplacer Windows.UI.Composition vers Microsoft.UI.Composition, est-ce plus proche de 2.2 ou 3.0 ?

@jtorjo ce sera 3.0 (au minimum). Nous espérons inclure une première version dans la première préversion de la 3.0, mais pas encore garantie à 100 %.

À l'avenir, lorsque vous parlerez d'années (comme dans « d'ici la fin de l'année »), pouvez-vous être clair sur les années civiles et les années financières [Microsoft].

@mrlacey merci, je garderai cela à l'esprit ! Toutes les dates que nous utilisons sont généralement en temps calendaire.

@jesbis C'est un peu triste. Donc vous dites qu'il est possible que nous n'ayons pas Microsoft.UI.Composition en 3.0 ?

@jtorjo

Nous espérons inclure une version préliminaire dans la première préversion de la 3.0 , mais pas encore garantie à 100 %

Il existe souvent de nombreuses versions préliminaires. .NET Core 3 est sur Preview 6, par exemple.

Notre plan est d'inclure les API de composition dans 3.0.

La partie framework Xaml sera open source avant la partie composition cependant.

@jesbis Merci,

Feuille de route fantastique, excellent travail!

Comme tout le monde ici, j'aime la transparence et j'attends avec impatience WinUI 3.0. Pour moi, WinUI 3.0 est la chose la plus excitante depuis l'introduction de WPF en 2006.

J'ai également encore des clients exécutant Windows 7, mais je pense que la prise en charge de Windows 10 est la plus importante et je ne consacrerais pas de temps et de ressources à la prise en charge de Win7. La plupart des entreprises dans lesquelles je travaille passent à 10. Et je pense qu'à la fin de 2020, la seule entreprise que je connaîtrai qui utilise encore Windows 7 sera probablement mon dentiste. Et s'il me demande d'écrire une application Windows pour lui, je migrerai ses PC vers Windows 10. :-)

Le soutien de WASM à l'avenir serait incroyable.

Hier lors d'une conférence :

Une petite histoire pour montrer à @jesbis et à l'équipe que nous qui écrivons et participons ici ne sommes que la pointe de l'iceberg excité. :-)

Pas plus tard qu'hier, j'ai discuté lors d'une conférence de développeurs en Allemagne avec des développeurs .NET et je leur ai parlé de WinUI 3.0, et ils ne le savaient pas. Je leur ai parlé de la feuille de route et ils ont dit :

"Wouh, c'est dingue".

Une fille du groupe m'a demandé :

« Mais avez-vous le droit de nous dire tout cela ? »

Je l'ai regardée ainsi que les autres, puis j'ai profité d'une pause réthorique de

await Task.Delay(3000);

avant de dire

"Enfer oui ! Vous pouvez tout lire sur GitHub".

Merci @jesbis et toutes les personnes impliquées. De bons moments pour être développeur Windows ❤️

J'espère que les applications propriétaires (comme Word ?) pourront utiliser les couches de WinUI, et les développeurs seraient heureux de voir que, "Hé, WinUI est une vraie chose qui peut faire fonctionner les affaires, plutôt qu'un jouet".
S'ils l'utilisent déjà, dites-le à voix haute.

Acrylique pour WPF, Win32 et WinUI Desktop.

Oh et peut-être reconsidérer la politique acrylique uniquement sur les fenêtres actives.

Oui, si vous avez plus d'un moniteur, le rendu se fait dans une seule fenêtre. Au moins sur plusieurs moniteurs, cela devrait fonctionner correctement...

Je pensais aux implications de l'expérience de développement d'avoir deux ensembles de contrôles d'interface utilisateur disponibles dans les applications UWP - lorsque nous aurons accès à la fois aux contrôles WinUI et aux contrôles d'interface utilisateur hérités, lorsque dans le code C#-behind, IntelliSense car cela nous obligera toujours à correctement choisissez l'espace de noms à partir duquel le contrôle doit provenir au lieu d'utiliser Alt + Entrée pour simplement ajouter using et continuer. Sera-t-il possible d'éviter cela d'une manière ou d'une autre ?

Une fois que WinUI3 est disponible pour les développeurs, les SDK Windows 10 devraient envisager de suggérer le changement d'espace de noms pour les projets ouverts avec un SDK pris en charge installé. Essayez d'éloigner les gens des espaces de noms du système d'exploitation.

Acrylique pour WPF, Win32 et WinUI Desktop.

Ce que j'aimerais voir en premier, c'est que MS mûrit suffisamment les îles Xaml pour que, par exemple, l'acrylique dans la barre de titre puisse être utilisé pour des projets non-UWP basant leur interface utilisateur sur WinUI (voir le dernier paragraphe de cet article ). @marb2000 est probablement la personne à qui poser la question.

@MartinZikmund Nous voulons éviter ce scénario. Lorsque vous utilisez WinUI 3, vous ne devriez avoir accès qu'aux contrôles du package. L'idée étant que nous avons tout ce dont vous avez besoin avec les derniers et les plus grands changements.

@MartinZikmund
@LucasHaines

Un correctif devrait être que vous pouvez exclure les références Windows.UI.Xaml.* WinMD de la construction. Désormais, les cibles de construction font uniquement référence à Unified WinMD aka. Windows.winmd , ajoutez une option dans les cibles pour référencer également des WinMD individuels, de cette façon, nous pouvons inclure ou exclure les références en fonction de l'application que nous construisons.

Est-ce ainsi qu'il n'est pas nécessaire de modifier les espaces de noms, car il se comporte comme un .NET dll il peut fonctionner avec des redirections d'assembly vers une version locale à l'intérieur du package plutôt que celles fournies par le système.

Je sais que cette méthode est spécifiquement pour .NET Framework, mais pour UAP, il devrait y avoir une solution pour ce genre de scénarios. Je sais qu'il y a FrameworkDependency sur le manifeste msix/appx . Peut-être pouvons-nous l'utiliser pour fournir au nouveau WinUI des espaces Windows.* noms Microsoft.* .

Côté dev, nous aurions moins de peine à mettre à jour nos applications, puisque nous ne changeons que la référence et non le code !

Je préférerais ne pas changer du tout l'espace de noms !

Avantages:

1. Vous n'avez pas à changer de code dans les deux sens.

2. Une fois que le code WinUI local a été stabilisé, vous pouvez fusionner à nouveau dans la plate-forme Windows, afin que les applications système et les applications LOB puissent profiter des nouvelles améliorations, à chaque nouvelle version de Windows.

3. D'un côté, il s'agit d'un framework système très stable avec une compatibilité élevée comme .NET Framework. Et de l'autre côté, c'est comme .NET Core, avec des changements à un rythme plus rapide, avec tous les avantages des deux et aucun des problèmes.

Je viens de regarder une présentation impressionnante de Steve Sanderson sur l'interface utilisateur Blazor + (non html) enveloppée dans une application native multiplateforme. Environ 52 minutes après le début de la vidéo. Un must pour les fans d'UWP, WinUI et c#. Je suis sérieusement impressionné par Blazor !!!

https://youtu.be/uW-Kk7Qpv5U

Une chose que j'ai oublié de dire dans ces discussions, que je trouve importante, c'est...
WinUI 3.0 lui-même a-t-il des améliorations de performances ? Le moteur de rendu XAML vient-il d'être découplé ou subit-il des modifications ? Les contrôles XAML utiliseront-ils principalement la composition, et donc, hors thread et dwm comme DirectUI ?

Les performances de certains contrôles et l'utilisation de la RAM pourraient être bien meilleures, comme ListView/GridView = ItemsControl.

Vous voyez cela sur Windows lui-même. Le menu Démarrer de Windows 8 (DirectUI) est bien plus fluide que le menu Démarrer XAML de Windows 10.
Essayez de charger un GridView avec suffisamment d'informations, comme la page Groove Albums, et les choses ne se passent pas si bien. C'est quelque chose que iOS et Android se comportent beaucoup mieux, tout comme winforms, QT.
(WPF est encore pire que UWP XAML à mon avis).

WinUI 3.0 lui-même a-t-il des améliorations de performances ? Le moteur de rendu XAML vient-il d'être découplé ou subit-il des modifications ? Les contrôles XAML utiliseront-ils principalement la composition, et donc, hors thread et dwm comme DirectUI ?

La performance est définitivement quelque chose dans laquelle nous voulons continuer à investir, mais je ne m'attendrais à aucune amélioration pour la 3.0. L'effort initial de la version 3.0 est principalement axé sur le découplage de Xaml pour l'expédier en tant que package NuGet et open source.

WinUI 3.0 (comme UWP Xaml aujourd'hui) est construit sur la couche de composition et exécute une grande partie de son rendu et de son animation hors thread via le DWM.

C'est quelque chose que iOS et Android se comportent beaucoup mieux, tout comme winforms, QT.
(WPF est encore pire que UWP XAML à mon avis).

Il y a souvent un compromis performance vs flexibilité/richesse lorsque l'on considère ces scénarios. Les plates-formes basées sur Xaml (y compris UWP et WPF) ont tendance à avoir des arborescences d'objets d'interface utilisateur plus grandes et plus riches pour chaque contrôle : cela offre une grande flexibilité pour modifier le style et l'UX de n'importe quel contrôle, alors que d'autres plates-formes ont tendance à avoir des arborescences d'objets beaucoup plus plates qui ne sont pas aussi flexibles mais peuvent parfois être chargés plus rapidement.

Ce compromis est certainement quelque chose auquel nous pensons et que nous garderons à l'esprit pour les changements futurs potentiels. La flexibilité supplémentaire des modèles de contrôle Xaml complexes n'est pas nécessaire la plupart du temps, nous pourrions donc potentiellement simplifier les contrôles pour qu'ils se chargent plus rapidement dans les cas où vous n'avez pas besoin de flexibilité supplémentaire.

J'espère que Microsoft pourra fournir un nouveau comctl32.dll et comdlg32.dll basé sur WinUI 3.0.

Parce que la plupart des applications Win32 auront l'expérience d'interface utilisateur moderne et cela aidera les développeurs à adapter leurs applications à l'interface utilisateur moderne.

De nombreux développeurs Win32 doivent adapter plusieurs versions de Windows. Ils ne peuvent donc pas utiliser directement WinUI aujourd'hui. C'est excellent si Microsoft peut fournir une méthode pour les aider à réduire la charge de travail de la modernisation de l'interface utilisateur de leurs applications.

De plus, j'espère que Microsoft pourra fournir un concepteur XAML pour les applications C++ Win32 qui utilise WinUI.

Kenji Mouri

@MouriNaruto, vous pouvez utiliser FileOpenPicker dès aujourd'hui (à partir de Win32).

@MouriNaruto, vous pouvez utiliser FileOpenPicker dès aujourd'hui (à partir de Win32).

Je sais, mais j'espère que tous les contrôles et boîtes de dialogue communs modernes apporteront à Win32.

@MouriNaruto

Techniquement, c'est possible. Mais les développeurs Windows doivent recréer non seulement les comportements exacts des implémentations COMCTL et COMDLG mais aussi les bogues connus et inconnus qui existent dans la base de code.

La compatibilité est notre ennemie !

Même s'ils le font, au moment où ils le terminent, chaque logiciel utilisant ces bibliothèques aurait suffisamment de temps pour migrer vers WinUI ! L'ironie!! ??

@MarkIngramUK

Pour info : FileOpenPicker n'est pas une boîte de dialogue/contrôle WinRT natif. Il s'agit essentiellement d'un wrapper de ExplorerFrame qui est lui-même écrit en DirectUI (développé par ATG Team et basé sur DirectX ) et COM !

Techniquement, c'est possible. Mais les développeurs Windows doivent recréer non seulement les comportements exacts des implémentations COMCTL et COMDLG, mais aussi les bogues connus et inconnus qui existent dans la base de code.
La compatibilité est notre ennemie !
Même s'ils le font, au moment où ils le terminent, chaque logiciel utilisant ces bibliothèques aurait suffisamment de temps pour migrer vers WinUI ! L'ironie!! ??

Je ne pense pas qu'il soit facile pour de nombreux projets de migrer vers WinUI sans cela à cause de la réalité.

Vous avez dit "La compatibilité est notre ennemi!". Oui, c'est aussi l'une des raisons de mes suggestions. L'ironie!! ??

Je serais simplement heureux d'avoir une version XAML WinUI des boîtes de dialogue communes, même si WPF et WinForms devaient choisir d'utiliser les nouvelles versions.

La cible WinUI 3 semble très excitante et je l'attends avec impatience. J'ai quelques questions concernant la distribution/déploiement, dans le cadre d'une application Win32 classique utilisant WinUI 3

1. Est-ce que chaque application doit apporter sa bibliothèque WinUI avec elle ou est-ce que le partage entre les applications est possible, peut-être même automatiquement via les mécanismes Windows
2. Sera-t-il possible de lier statiquement WinUI ?
3. Disons que je dois le redistribuer, quelle sera la taille approximative de WinUI en Mo ?

Est-ce que chaque application doit apporter sa bibliothèque WinUI avec elle ou est-ce que le partage entre les applications est possible, peut-être même automatiquement via les mécanismes Windows

Nous prévoyons de distribuer principalement WinUI 3 via NuGet, qui dispose de mécanismes pour mettre en cache et partager automatiquement les packages - plus d'informations sont disponibles ici :

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

Sera-t-il possible de lier statiquement WinUI ?

Ce n'est pas quelque chose que nous prévoyions actuellement - avez-vous un scénario en tête où cela serait avantageux ?

Disons que je dois le redistribuer, quelle sera la taille approximative de WinUI en Mo ?

Nous sommes toujours en train de déterminer à quoi ressemblera le graphique de dépendance final, mais pour les éléments de l'interface utilisateur, il sera probablement similaire aux tailles de dll system32 existantes pertinentes (10 Mo).

Nous prévoyons de distribuer principalement WinUI 3 via NuGet, qui dispose de mécanismes pour mettre en cache et partager automatiquement les packages

Je pensais que le nuget était juste pour le développement ou est-ce que j'ai raté quelque chose ? Pour autant que je sache, les packages basés sur Nuget doivent être déployés par chaque application individuellement et ne peuvent pas être partagés. C'est pourquoi il existe des programmes d'installation dédiés pour un runtime dotnet core partagé, sinon cela ne serait pas nécessaire étant donné que les packages dotnet core sont déjà sur nuget ...

Vous ne devriez pas avoir à installer d'outils de développement ou de SDK uniquement pour partager les packages de framework d'interface utilisateur. WPF et WinForms pour .NET Core avaient le même problème et ont investi dans la création d'un ensemble partagé afin que les gens n'aient pas à installer le SDK sur les ordinateurs des utilisateurs finaux , cela vaut probablement la peine de le faire pour WinUI une fois que vous y êtes arrivé (peut-être même obtenez-vous inclus dans le pack WindowsDesktop)

En particulier, il existe déjà des options de construction dans VS pour le déploiement dépendant du framework et WinUI doit les exploiter pour garantir que les packages sont partagés. Bien sûr, ils doivent d'abord fournir un package partageable.

Pour les applications fournies par le Microsoft Store, le contenu du package de version doit également être automatiquement partagé lors du déploiement.

Pour les applications win32 déployées par d'autres moyens, c'est sur notre liste de choses à faire pour étudier des options comme ce que vous avez mentionné 😊

Sera-t-il possible de lier statiquement WinUI ?

Ce n'est pas quelque chose que nous prévoyions actuellement - avez-vous un scénario en tête où cela serait avantageux ?

Je pense que je dois clarifier : sera-t-il possible d'utiliser WinUI dans un EXE lié statiquement (qui lie statiquement le VC-Runtime) ? Je suppose que cela ne devrait pas être un problème à cause de C++/WinRT mais je voulais juste être sûr...

Disons que je dois le redistribuer, quelle sera la taille approximative de WinUI en Mo ?

Nous sommes toujours en train de déterminer à quoi ressemblera le graphique de dépendance final, mais pour les éléments de l'interface utilisateur, il sera probablement similaire aux tailles de dll system32 existantes pertinentes (10 Mo).

Merci pour l'information.

Transparence impressionnante d'ailleurs pour une entreprise aussi énorme, je l'aime beaucoup.

Je pense que je dois clarifier : sera-t-il possible d'utiliser WinUI dans un EXE lié statiquement (qui lie statiquement le VC-Runtime) ? Je suppose que cela ne devrait pas être un problème à cause de C++/WinRT mais je voulais juste être sûr

Cela devrait être possible (en théorie) mais comme l' a dit

La discussion autour de Windows 7 est un peu distrayante, car la quantité d'efforts (sans parler du coût) entraînerait un retard important pour WinUI 3.0. Windows 7 arrive en fin de vie en janvier et nous encourageons tous les clients à passer à Windows 10. Mes clients peuvent ne pas s'aligner sur les autres ici, mais même Windows 8.1 n'est pas une plate-forme qui nous intéresse.

Vous avez raison. Mais nous ne pouvons pas contrôler mon client et il y a plus de 60% de système win7 en Chine. Et nous ne pouvons pas abandonner ce marché, nous ne pouvons donc utiliser aucune technologie qui ne prend pas en charge win7.

Les données proviennent de baidu, voir https://tongji.baidu.com/data/os

Mais nous ne pouvons pas contrôler mon client et il y a plus de 60% du système est win7 en Chine

TBH, je resterais simplement avec .NET Framework 4.8 + WPF si vous êtes bloqué sur Win7.

Mais nous ne pouvons pas contrôler mon client et il y a plus de 60% du système est win7 en Chine

TBH, je resterais simplement avec .NET Framework 4.8 + WPF si vous êtes bloqué sur Win7.

Mais le Win7 Sp1 peut installer .NET Framework 4.8 et le win7 sans sp1 ne peut pas l'installer.

Configuration système requise pour .NET Framework |

Si vous n'avez même pas le SP1, vous êtes déjà en fin de vie depuis 6 ans.

La prise en charge de Windows 7 RTM sans service packs a pris fin le 9 avril 2013.

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

Si vous souhaitez prendre en charge Windows 7, vous devez utiliser une technologie qui prend déjà en charge Windows 7 et ne pas vous attendre à ce que Microsoft résolve ce problème pour vous.

@MarkIngramUK Ce n'est pas que Microsoft a résolu ce problème pour moi, mais je ne peux pas aider mes clients qui utilisent win7 sans sp1. Je ne peux pas contrôler nos clients pour qu'ils utilisent n'importe quel système, mais ceux qui utilisent win7 sans sp1 abandonneront notre application et cela signifie que nous avons perdu ce marché. Mais mes concurrents qui n'utilisent pas la nouvelle technologie peuvent supporter win7 sans sp1 et mes concurrents gagneront ce marché.

Triste mais vrai, trop de clients ne se soucient pas de la technologie que nous utilisons, mais ils se soucient que l'application puisse bien fonctionner sur tous leurs appareils.

C'est le statu quo de mon industrie, et les conclusions ci-dessus peuvent ne pas convenir à d'autres industries.

@linxi comme je l'ai dit, vous ne pouvez pas vous attendre à ce que les nouvelles technologies soient portées sur un système d'exploitation qui est déjà en fin de vie depuis 6 ans. Si vous souhaitez cibler l'ancien système d'exploitation, vous avez besoin d'une ancienne technologie.

@linxi Je pense que si le client ne veut pas utiliser la technologie prise en charge et préfère quelque chose d'obsolète, alors il ne peut pas raisonnablement s'attendre à avoir une interface utilisateur moderne. Ces deux exigences sont purement exclusives l'une de l'autre...

@MarkIngramUK Triste. Je pense que lorsque je peux utiliser la nouvelle technologie d'aujourd'hui, cette nouvelle technologie est devenue une vieille technologie.

@linxi c'est littéralement le contraire de ce qui se passe. Vous ne pouvez pas appeler une nouvelle technologie « ancienne technologie » simplement parce qu'elle n'est pas portée sur un ancien système d'exploitation. Si vous voulez la prise en charge de Win7 (pas de SP1), utilisez WinForms ou MFC ou quelque chose.

@MartinZikmund Vous avez raison. En fait, presque aucun de nos utilisateurs ne comprend la technologie informatique, même win7 et win10 ne peuvent pas le dire. Ils ne se soucient pas de la technologie que nous utilisons.

@jesbis J'aimerais me salir les mains avec le nouveau WinUI en utilisant C++. J'ai fait de mon mieux en utilisant UWP et C++/Cx dans le passé, mais en plus de l'application PhotoEditor et de quelques exemples, vous avez toujours fini par vous gratter la tête et à essayer de trouver une bonne documentation, par exemple pour lier XAML avec Platform::Collections et des trucs comme cette. C'est l'une des raisons pour lesquelles je suis revenu à C# pour UWP et Qt pour le développement C++ sous Windows. S'il vous plaît, montrez plus d'amour au C++.

Sur mes clients, j'ai utilisé une clé USB (PenDrive) avec Windows 10 Media, et je l'ai simplement mise à niveau gratuitement de Windows 7 vers la dernière version de Windows 10. Ils ont bénéficié d'un système d'exploitation moderne, avec antivirus, mises à jour Windows, Edge WebBrowser et prennent en charge les technologies d'interface graphique des plus anciennes comme WinForms, WPF, aux plus récentes, y compris UWP et au-delà (WinUI). De plus, au lieu d'arrêter, j'ai mis Windows en veille prolongée et j'ai appris aux utilisateurs à simplement appuyer sur le bouton d'alimentation pour commencer à travailler avec le PC et à appuyer sur le bouton d'alimentation lorsque vous avez terminé d'utiliser le PC.
Aussi j'ai mis un ISO sur le réseau, pour installer/mettre à niveau facilement les machines.

Et ils ont aussi l'avantage d'avoir Candy Crush préinstallé sur leurs ordinateurs !

Avis

Je pensais que les implémentations des contrôles de WPF pouvaient être fusionnées dans WinUI pour la prise en charge de l'ancienne version de Windows. (Par exemple, Windows 7.) Mais il est trop difficile pour Microsoft de le réaliser à cause de la politique du bureau, lol.

réponses

@lindexi
Je sais qu'il y a beaucoup d'utilisateurs de versions Windows obsolètes en Chine aujourd'hui. Mais je pense qu'il est nécessaire d'abandonner les utilisateurs de Windows NT 5.x aujourd'hui et je sais que c'est difficile.

@MartinZikmund

Je pense que si le client ne veut pas utiliser la technologie prise en charge et préfère quelque chose d'obsolète, alors il ne peut raisonnablement pas s'attendre à avoir une interface utilisateur moderne. Ces deux exigences sont purement exclusives l'une de l'autre...

La prise en charge de l'interface utilisateur moderne et de l'ancienne plate-forme est nécessaire en Chine si vous ne voulez pas que votre travail soit servi à une minorité. Ainsi, l'un de mes amis, un développeur chinois, a porté Blink et V8 sur Windows XP sans aucune mise à jour installée , de nombreux développeurs l'utilisent pour mettre en œuvre leurs expériences d'applications modernes. En Chine, la version minimale requise du système d'exploitation est égale à une version sans aucune mise à jour installée . Par exemple, si vous savez que la version requise du système d'exploitation d'une application en provenance de Chine est Windows 7, cela vous indique que vous pouvez utiliser l'application sous "Windows 7 RTM" ou "6.1.760.16385 (win7_rtm.090713-1255)". Même dans le monde Android, de nombreuses applications prennent toujours en charge Android 4.4 aujourd'hui.

C'est pourquoi la plupart des applications créées par des développeurs non chinois ne peuvent pas être le choix de la majorité en Chine.

PS Nous pouvons utiliser le dernier Visual Studio 2019 pour créer des applications pour Windows XP RTM sans aucune mise à jour installée , avec le dernier SDK Windows 10 et la dernière norme C++17 ou en essayant C++20 maintenant. À cause de VC-LTL (https://github.com/Chuyu-Team/VC-LTL) et YY-Thunks (https://github.com/Chuyu-Team/YY-Thunks).

Note sur moi-même

La plupart du temps, j'utilise la dernière version stable de Windows. (J'utilise 10.0.18362 aujourd'hui. J'utilise 19H1 et 19H2.) Mais mes projets Win32 conçus pour Windows Vista RTM sans aucune mise à jour installée , et mes projets UWP conçus pour Windows 10, version 1703 sans aucune mise à jour installée ou ultérieure car la condition La prise en charge de XAML est introduite dans RS2. (J'adore le XAML conditionnel. Pourquoi n'existe-t-il pas sur Windows 10 Build 14393 ?)

Kenji Mouri

S'il vous plaît, s'il vous plaît, envisagez de dé-sceller toutes les classes de contrôle WinUI 3.0 !

D'après ce que j'ai compris, Microsoft a décidé de sceller toutes les classes de contrôle UWP, car JavaScript (qui ne connaît pas l'héritage) causait des problèmes lorsqu'il était utilisé avec des classes héritées. Maintenant que JS/HTML est obsolète, le nouveau framework d'interface utilisateur n'a plus besoin de sceller toutes les classes. Un-selaing rendrait beaucoup plus facile la personnalisation des contrôles UWP, comme cela a toujours été possible dans WPF. Il serait également très utile, lors de l'écriture de contrôles ou de panneaux de liste de virtualisation personnalisés, d'avoir une classe de base de virtualisation non scellée dont hériter. Ni C#, ni C++/CX ou C++/WinRT n'ont de problèmes d'héritage. Ce n'est que l'échec appelé JS/HTML qui nous a imposé cela.

Veuillez donc supprimer cette restriction inutile lors de la création de WinUI 3.0.

@gisfromscratch merci pour le retour ! Nous voulons absolument prendre en charge le développement C++ (en particulier avec C++/WinRT).

Qu'est-ce qui faciliterait l'utilisation du C++ ? Avez-vous essayé C++/WinRT au lieu de CX ?

Est-ce que d'autres exemples d'applications seraient utiles ?

Vous avez mentionné qu'il était difficile de trouver de la documentation sur la liaison : y avait-il d'autres fonctionnalités spécifiques qui nécessitent une meilleure documentation ?

S'il vous plaît, s'il vous plaît, envisagez de dé-sceller toutes les classes de contrôle WinUI 3.0 !

@lukasf c'est quelque chose que nous allons probablement faire 🙂 Il y a une discussion connexe en cours dans #780

@jesbis Je dois beaucoup plus me salir les mains en utilisant C++/WinRT. Je viens de suivre l' exemple d'application Photo Editor C++/WinRT . Mais lorsque vous lisez les liens fournis, tels que la liaison de données en profondeur, vous vous retrouvez dans de nombreux extraits de code C# et quelques notes secondaires telles que "Pour C++/WinRT, toute classe d'exécution que vous déclarez dans votre application qui dérive d'une classe de base est connue sous le nom de classe composable. Et il y a des contraintes autour des classes composables…". Cette page cible 95% C# et seulement 5% C++.

@gisfromscratch merci ! Nous garderons cela à l'esprit pendant que nous travaillons à la mise à jour des documents pour WinUI 3.

Si cela peut vous aider, la page de liaison de données que vous avez mentionnée renvoie également à des pages distinctes concernant spécifiquement la liaison de données avec C++/WinRT, par exemple :

contrôles XAML ;

contrôles d'éléments XAML ;

Il existe également un certain nombre d'autres sujets spécifiques à C++/WinRT dans cette section.

Merci pour vos excellents travaux ! Très heureux de voir que Xaml Island est supprimé de WinUi 3.0.
Btw : Je me demande juste si l'implémentation de bas niveau de la projection de composant WinRT semble avoir un

@zenjia XAML Islands n'est pas supprimé de WinUI 3. WinUI 3 contiendra les API qui permettent aux applications WPF/WinForms/MFC d'héberger les contrôles WinUI 3.

J'ai essayé de suivre les progrès de WinUI. J'ai déjà essayé d'écrire des applications UWP avec C#, mais j'ai trouvé que c'était une bataille difficile. Mais je suis impatient d'essayer à nouveau après Winui 3.0.

J'ai des questions sur la feuille de route winui. En voici quatre. Désolé s'ils ont été couverts ailleurs. Je n'ai pas trouvé de réponses, malgré de nombreuses recherches... faites-moi savoir s'il existe un meilleur forum pour poser ce genre de questions.

• Les wrappers .net pour les contrôles natifs seront-ils également open-source ? Il n'est pas clair que ce soit la repro github qui soit responsable du côté .Net de winui, étant donné que le seul code c# que je semble trouver est destiné aux tests automatisés. Je recherche des choses comme Microsoft.UI.Xaml.UIElement mais je ne trouve ce code nulle part.

• Lorsque nous arriverons à la sortie de winui 3.0, le modèle d'application UWP et le modèle d'application win32 exécuteront-ils le même runtime .Net Core ? Je n'ai jamais vraiment compris quelle version du noyau .Net est utilisée par les applications UWP. J'imagine que c'est quelque chose qui est intégré à Windows lui-même et que les SDK de Windows 10 permettent à VS 2019 de cibler la version correcte du noyau .Net disponible dans UWP.

• Une question sur les îles Xaml. Y a-t-il une chance que WPF et UWP partagent le même espace aérien ? Je n'ai pas hâte d'avoir à gérer des problèmes d'espace aérien comme nous l'avons fait entre winforms et WPF. Étant donné que WPF et UWP sont tous deux construits sur direct-X, ce serait génial s'ils pouvaient partager des pixels entre eux. Par exemple, si je devais avoir un menu dans les coulisses sur un ruban (en WPF) qui devra superposer un îlot xaml UWP, ce serait merveilleux si cela pouvait se produire de manière transparente. Il ne semble pas que je devrais avoir à sauter à travers des tonnes de cerceaux pour quelque chose comme ça. ... Je me souviens qu'au début de WPF, ils essayaient de résoudre les problèmes d'espace aérien pour les applications clientes qui voulaient utiliser le contrôle winforms "WebBrowser". Ils ont fait un essai d'une fonctionnalité du navigateur Web appelée "WebBrowser.CompositionMode" et elle était censée permettre au WebBrowser de fonctionner correctement avec WPF. ... Mais je pense que cette stratégie a finalement été abandonnée. Peut-être que l'interopérabilité entre UWP et WPF pourrait être si transparente qu'ils pourraient même partager des pixels entre eux (contrairement à winforms et WPF). Un avantage potentiel de cela serait de permettre à WPF d'améliorer la fonctionnalité d'un contrôle UWP. Par exemple, WPF pourrait superposer un îlot xaml avec des visuels supplémentaires d'une manière analogue à un calque d'ornement. Cela pourrait devenir pratique à la rigueur.

• Y a-t-il une chance qu'une application WPF avec des îles xaml (disons 50% WPF et 50% WINUI) puisse être compilée nativement vers ARM64 un jour ? Le ciblage ARM est possible avec des applications 100% UWP, et ce serait bien si les dépendances WPF ne nous obligent pas à abandonner notre ciblage ARM64 natif. (L'alternative serait d'exécuter l'application en émulation x86 - mais cela est plus lent et limite la mémoire disponible pouvant être utilisée).

Espérons que ces questions soient toutes pertinentes pour la feuille de route de winui. Tout avis sera le bienvenu.

Les wrappers .net pour les contrôles natifs seront-ils également open-source ? Il n'est pas clair que ce soit la repro github qui soit responsable du côté .Net de winui, étant donné que le seul code c# que je semble trouver est destiné aux tests automatisés. Je recherche des choses comme Microsoft.UI.Xaml.UIElement mais je ne trouve ce code nulle part.

UIElement n'est pas dans WinUI 2, il n'est donc pas actuellement dans le référentiel. Ce sera dans WinUI 3 qui n'est pas encore publié ou open source, mais nous y travaillons !

Vous pouvez voir des exemples dans le référentiel d'autres contrôles natifs exposés à .NET via des projections WinRT, par exemple les contrôles WinUI 2.2 documentés ici . Ils ne nécessitent généralement pas de fichiers wrapper par langue préexistants, c'est pourquoi vous ne trouvez pas de fichiers .cs dans le référentiel.

@ marb2000 pourrait mieux commenter les questions sur les îles / le bureau.

Q : _WinUI 3 UWP et Desktop utiliseront-ils le même environnement d'exécution .NET ?_
R : Oui, c'est le plan. UWP et Desktop utiliseront .NET Core 3. Les bibliothèques WinRT gérées utiliseront .NET Core 3 au lieu de .NET Native.

Q : _WPF et UWP partageront-ils le même espace aérien ?_
R : Bien que WPF et WinUI (et XAML UWP) semblent similaires, ils ne le sont pas. WPF utilise DirectX9 et WinUI/XAML UWP utilise Windows.UI.Composition pour les besoins de composition, de rendu et d'animation de XAML (en plus d'une version moderne de DirectX11). Malheureusement, cela rend l'interopérabilité très compliquée. Votre proposition sur les ornements WPF est intéressante. En théorie, l'adoptant peut créer une fenêtre contextuelle pour placer le contenu WinUI/XAML sur le contenu WPF. Ou il peut informer l'arborescence visuelle WPF qu'une nouvelle mise en page est requise, mais tout est basé sur HWnds.
@dbeavon C'est une bonne proposition, pouvez-vous créer une demande de fonctionnalité pour cela ?

Q : _Une application WPF avec Xaml Islands sera-t-elle compilée vers ARM64 ?_
R : Si .NET Core 3 pour Windows prend en charge ARM64 à coup sûr. Aujourd'hui, il prend en charge ARM32 sous Windows. Cependant, sous Linux prend en charge ARM64. Je pense que c'est sur la feuille de route .NET Core pour prendre en charge ARM64 dans Windows également. Bien AFAIN, il n'y a pas encore de date. @richlander , des nouvelles ?

@marb2000

Q : WPF et UWP partageront-ils le même espace aérien ?

UWP peut-il utiliser Windows.UI.Composition pour créer une couche qui peut obtenir le rendu d'un bitmap DirectX ? Et puis le WPF rend les fenêtres sur cette couche comme win2d. Peut-être qu'il peut partager le même espace aérien. Mais il est difficile de rendre WPF sur un calque.

@linxi Je suppose que cela pourrait être le paradis :D

UWP peut-il utiliser Windows.UI.Composition pour créer une couche qui peut obtenir le rendu d'un bitmap DirectX ?

UWP Xaml a plusieurs façons de rendre des bitmaps DirectX ou des chaînes d'échange en Xaml et de les composer avec Windows.UI.Composition afin qu'ils partagent le même espace aérien, y compris SurfaceImageSource , VirtualSurfaceImageSource et SwapChainPanel - plus d'informations sont disponibles ici :

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

Vous pouvez également insérer un visuel Windows.UI.Composition dans une arborescence d'interface utilisateur UWP Xaml et y dessiner du contenu DirectX, par exemple en utilisant ICompositorInterop , ICompositionDrawingSurfaceInterop et ICompositionGraphicsDeviceInterop comme indiqué ici :

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

Ces approches devraient fonctionner de la même manière avec WinUI.

Une application de bureau UWP pourra-t-elle référencer une DLL WPF/WinForm et ouvrir une fenêtre WPF/WinFrom ? Cela me permettrait de migrer progressivement.

@marb2000 -- .NET Core pour Windows ARM64 est sur notre feuille de route. Je travaille sur un plan pour ça maintenant.

Avec WinUI 3.0, sera-t-il possible de compiler win2d dessus ?
(ainsi, le découplant de UWP)
Si c'est le cas, ce serait vraiment génial !

Nous travaillons toujours sur les détails de l'intégration DirectX, mais nous espérons qu'il sera possible de mettre à jour Win2D pour utiliser les classes de base WinUI au lieu des classes de base UWP Xaml.

je croise les doigts :D

désolé si c'est hors sujet : rapports de bogues sur UWP - est-ce que j'ajoute un problème sur https://github.com/microsoft/microsoft-ui-xaml/ ou ailleurs ?

désolé si c'est hors sujet : rapports de bogues sur UWP - est-ce que j'ajoute un problème sur https://github.com/microsoft/microsoft-ui-xaml/ ou ailleurs ?

@jtorjo excellente question ! Ce dépôt est le meilleur endroit pour signaler tout problème lié à :

• les API du framework UWP UI (par exemple Windows.UI.Xaml)
• Conception fluide
• WinUI

En général, il devrait y avoir un lien « Envoyer des commentaires sur ce produit » au bas de la plupart des pages de documentation sur docs.microsoft.com qui vous indiquera la meilleure façon de fournir des commentaires sur une fonctionnalité ou une API spécifique.

Pour la plupart des aspects d'UWP, mis à part ce qui précède, il s'agira de classer les bogues dans la catégorie Plate-forme de développeur dans le Hub de commentaires, qui comporte un certain nombre de sous-catégories pertinentes.

WinUI 3 inclura-t-il le contrôle UWP SemanticZoom ? Je pense que c'est le contrôle le plus cool de tous.

@jesbis Merci ! Je viens de poster une discussion sur System.IO

Même Microsoft n'abandonne pas la prise en charge de Windows 7 pour Office, pourquoi WinUI 3 le ferait-il ? Je veux dire, presque tous les logiciels sérieux ont le support de Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Si WinUI ne supporte pas Windows 7...

Même Microsoft n'abandonne pas la prise en charge de Windows 7 pour Office, pourquoi WinUI 3 le ferait-il ? Je veux dire, presque tous les logiciels sérieux ont le support de Windows 7 (Photoshop, Office, Visual Studio 2019, VSCode, ...) Si WinUI ne supporte pas Windows 7...

Office abandonnera probablement le support bientôt, car le support de Microsoft pour Windows 7 se termine très très bientôt. Mais il est construit sur une base de code qui prenait déjà en charge Windows 7.

WinUI a été construit sur Windows 10 et devrait donc être rétroporté sur Windows 7. L'effort pour le faire n'a aucun sens avec le système d'exploitation entrant en fin de vie, et les gens devront donc passer à Windows 10.

Q : WinUI 3 UWP et Desktop utiliseront-ils le même environnement d'exécution .NET ?
R : Oui, c'est le plan. UWP et Desktop utiliseront .NET Core 3. Les bibliothèques WinRT gérées utiliseront .NET Core 3 au lieu de .NET Native.
Q : WPF et UWP partageront-ils le même espace aérien ?
R : Bien que WPF et WinUI (et XAML UWP) semblent similaires, ils ne le sont pas. WPF utilise DirectX9 et WinUI/XAML UWP utilise Windows.UI.Composition pour les besoins de composition, de rendu et d'animation de XAML (en plus d'une version moderne de DirectX11). Malheureusement, cela rend l'interopérabilité très compliquée. Votre proposition sur les ornements WPF est intéressante. En théorie, l'adoptant peut créer une fenêtre contextuelle pour placer le contenu WinUI/XAML sur le contenu WPF. Ou il peut informer l'arborescence visuelle WPF qu'une nouvelle mise en page est requise, mais tout est basé sur HWnds.
@dbeavon C'est une bonne proposition, pouvez-vous créer une demande de fonctionnalité pour cela ?
Q : Une application WPF avec Xaml Islands sera-t-elle compilée en ARM64 ?
R : Si .NET Core 3 pour Windows prend en charge ARM64 à coup sûr. Aujourd'hui, il prend en charge ARM32 sous Windows. Cependant, sous Linux prend en charge ARM64. Je pense que c'est sur la feuille de route .NET Core pour prendre en charge ARM64 dans Windows également. Bien AFAIN, il n'y a pas encore de date. @richlander , des nouvelles ?

Alors allons-nous nous débarrasser du bac à sable UWP ? Ce qui à son tour implique que UWP dans sa forme actuelle va également disparaître, et avec lui le bac à sable protégé de l'App Store tel que nous le connaissons ?

Alors allons-nous nous débarrasser du bac à sable UWP ? Ce qui à son tour implique que UWP dans sa forme actuelle va également disparaître, et avec lui le bac à sable protégé de l'App Store tel que nous le connaissons ?

se débarrasser du bac à sable UWP serait incroyablement génial !

Cela ne signifie certainement pas que UWP va disparaître. La plate-forme Windows universelle est le seul moyen de créer nativement pour tout le spectre des appareils Windows (PC, Xbox, HoloLens, etc.) et c'est là que Windows concentre ses investissements sur la plate-forme native. RE : sandboxing en particulier : l'isolation des conteneurs d'applications continue de fournir de nombreux avantages importants pour les applications et les utilisateurs d'applications UWP et de bureau.

Les principaux changements sont :

• nous élargissons la portée de la plate-forme UX (c'est-à-dire WinUI) afin qu'elle puisse également être utilisée avec un modèle d'application de bureau (win32)
• nous dissocions WinUI de Windows afin de pouvoir le mettre à jour plus fréquemment, rendre les nouvelles fonctionnalités rétrocompatibles et l'ouvrir plus facilement

Cela signifie que pour les nouvelles applications, vous pourrez choisir entre les modèles d'applications UWP et de bureau en fonction de ce qui a du sens pour votre application, et si vous avez des applications de bureau existantes (par exemple WPF, WinForms, MFC), vous pouvez les mettre à jour progressivement avec Fonctionnalité WinUI utilisant les îles Xaml.

Alors allons-nous nous débarrasser du bac à sable UWP ? Ce qui à son tour implique que UWP dans sa forme actuelle va également disparaître, et avec lui le bac à sable protégé de l'App Store tel que nous le connaissons ?

UWP sera l'une des options pour créer une application WinUI 3.0. L'utilisation de l'UWP permettra à votre application de fonctionner sur Xbox, Hololens, etc.

Mais vous pouvez également créer une application Win32 avec WinUI 3.0 et accéder aux API UWP - mais l'endroit où votre application peut s'exécuter sera plus limité.

@mdtauk @jesbis Je suis totalement pour UWP, mais en ce moment :

1. les temps de compilation sont incroyablement lents ! (à peu près, 6 fois plus lent que WPF - j'utilise la version cible build 1809 - build 17783)
2. Je sais que l'API d'énumération de fichiers StorageFolder ne fait pas partie d'UWP, mais c'est incroyablement lent. Le bac à sable UWP (au moins sur Windows Desktop) fait plus de mal qu'il n'aide.
3. Bien sûr, la programmation asynchrone est amusante, mais dans UWP, lorsqu'une exception se produit, elle est en quelque sorte mangée par le code UWP, puis s'interrompt plus tard dans le débogueur, avec tout le contexte de la pile perdu. Parfois, j'ai le contexte de pile à l'intérieur de l'exception levée elle-même, mais pas toujours.
4. Le profilage du code UWP est presque impossible. L'événement dotTrace s'interrompt instantanément lorsque vous essayez de le faire.

(Il m'a fallu plus d'un mois pour porter mon code de WPF vers UWP, car j'ai incroyablement besoin de win2d, il n'y a donc aucun moyen pour moi d'éviter UWP.)

@mdtauk @jesbis Je suis totalement pour UWP, mais en ce moment :

1. les temps de compilation sont incroyablement lents ! (à peu près, 6 fois plus lent que WPF - j'utilise la version cible build 1809 - build 17783)
2. Je sais que l'API d'énumération de fichiers StorageFolder ne fait pas partie d'UWP, mais c'est incroyablement lent. Le bac à sable UWP (au moins sur Windows Desktop) fait plus de mal qu'il n'aide.
3. Bien sûr, la programmation asynchrone est amusante, mais dans UWP, lorsqu'une exception se produit, elle est en quelque sorte mangée par le code UWP, puis s'interrompt plus tard dans le débogueur, avec tout le contexte de la pile perdu. Parfois, j'ai le contexte de pile à l'intérieur de l'exception levée elle-même, mais pas toujours.
4. Le profilage du code UWP est presque impossible. L'événement dotTrace s'interrompt instantanément lorsque vous essayez de le faire.

(Il m'a fallu plus d'un mois pour porter mon code de WPF vers UWP, car j'ai incroyablement besoin de win2d, il n'y a donc aucun moyen pour moi d'éviter UWP.)

Il serait utile que cela soit publié dans ce fil de discussion #1517 et j'espère que vous pouvez inclure dans le nom de quelqu'un de l'équipe SDK

@jtorjo

les temps de compilation sont incroyablement lents ! (à peu près, 6 fois plus lent que WPF

Utilisez-vous C++/WinRT ? Si oui, utilisez-vous des en-têtes précompilés ?

@mdtauk vient de poster là-bas

@MarkIngramUK C'est du code c#

Clôture - veuillez adresser la feuille de route et les commentaires alpha à : #1531

À l'heure actuelle, il n'y a aucune idée si cela est possible - l'espoir est que lorsque les bits WinUI sont supprimés du système d'exploitation, ils sont placés dans le projet open source d'une manière qui permettra à d'autres plates-formes de fournir une sorte de composant de compatibilité. Pensez à Xamarin, Uno ou .Net Core avec un moteur de rendu personnalisé.

Est-ce vraiment quelque chose sur la feuille de route ou était-ce juste une supposition ?

@mdtauk , @zezba9000 tout est théoriquement possible, et nous avons beaucoup d'expertise en abstraction de plate-forme dans l'équipe. Comme pour tout, cela se résume au coût, au calendrier et aux bénéfices attendus

Peut-être que l'abstraire d'une manière qui permettrait à un tiers de le faire fonctionner sur Android ou iOS serait énorme. Je suis sûr que la communauté peut le faire. J'y contribuerais certainement.

@andreinitescu Désolé pour la diatribe et les plaintes mais juste mes réflexions d'après ce que je comprends: Alors que j'utiliserai WinUI 3 pour remplacer WPF pour Windows / Win32 uniquement... Parce que WinUI sur Windows utilise une API de rendu Windows uniquement et non un agnostique un, WinUI semble s'appuyer sur des tiers pour réimplémenter / fragmenter (ugg) WinUI sur d'autres plates-formes (comme le proj UNO, ce qui est cool mais comme Mono vers .NET est une fragmentation inutile et perdante si les choses n'étaient que conçu dès le départ). Au lieu d'utiliser un portable comme Skia, ou d'en créer un MS. Je ne comprends pas non plus la nécessité de prendre en charge les 1% de personnes qui n'utiliseront pas C# avec WinUI, faisant de C# une cible de deuxième classe dans un sens et plus important encore, le temps de développement prend beaucoup plus de temps. Tout comme Android utilise Java + post-AOT pour de nombreuses applications principales, Windows devrait également utiliser C# + pré-AOT. Parce que ça fait gagner du temps. 70% des bogues utilisant C++ utilisent des PTR désalloués après tout.

Le manque de communication entre les groupes d'une entreprise pour les cas d'utilisation à long terme, alors que cela deviendra de plus en plus un problème lorsqu'ils sortiront leur version Android OS pour les plates-formes mobiles (que je prévois d'utiliser) et que plus de gens veulent le cibler avec les outils MS... sentez que ça va être une autre situation similaire à WinPhone7 d'une certaine manière. Windows en tant que terme ne devrait plus être aussi lié au noyau WinNT. Un écosystème est plus qu'une simple plate-forme ou un cadre d'entreprise sur lequel il est construit.

Dommage que MS ne puisse/ne fasse pas ce qu'Apple a fait il y a près de 20 ans avec le passage d'OS9 à OSX. En ce sens, vous déchirez le pansement en passant à un noyau UNIX/LINUX MAIS en ayant un émulateur/simulateur intégré au système d'exploitation pour les logiciels hérités pour les 5 à 10 prochaines années, tandis que les gens migrent les logiciels et les outils de développement pour qu'ils s'exécutent en mode natif. (Pensez ce que vous voudrez de cela mais je peux rêver)