Probablement une chose lointaine, mais Blend doit être révisé et a besoin d'un flux de travail axé sur la conception.

Le concepteur XAML doit être robuste et puissant.

Un moyen de visualiser la structure en couches de la page/fenêtre, particulièrement important avec des contrôles élevés.

Façons de visualiser les éléments de l'interface utilisateur en dehors d'une page, tels qu'un contrôle/modèle individuel.

Affichage des personnalisations de contrôle qui sont faites pour CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens, le tout dans le concepteur.

Concepteurs combinés pour XAML mélangés avec WinForms, WPF, MFC et tous les autres frameworks avec lesquels WinUI Desktop fonctionnera.

De bons moyens d'importer et d'exporter du XAML, afin que les concepteurs puissent travailler dans Blend isolément de l'application principale, puis les remettre aux équipes de développement pour les intégrer à l'application.

Une meilleure visualisation et une meilleure liste des ressources système, ainsi que d'excellents moyens d'extraire ces ressources globales qui peuvent être légèrement stylisées pour remplacer les valeurs par défaut, et la surface de conception reflète ces changements en temps réel.

De meilleures façons de tester différentes mises à l'échelle DPI avec des applications impliquant WinForms, MFC, etc.

Modèles pour les nouveaux contrôles, dictionnaires de ressources thématiques personnalisés, intégration de Fluent Theme Editor, modèles pour les combinaisons d'applications prises en charge (Win32 MFC avec Xaml UI, etc.) .

Modèles pour les points d'intégration du shell, comme les sélecteurs de fichiers, les menus volants de la barre des tâches.

Ce ne sont que quelques réflexions...

Mes pensées sont les suivantes :

1. MSIX, c'est bien beau, mais j'utilise toujours le bon vieux MSI pour installer des applications plus complexes qui nécessitent des fonctionnalités que MSIX ne prend pas en charge. Je suis également méfiant à l'idée d'utiliser MSIX en raison du coût des certificats Authenticode requis. (Je peux facilement signer mon code avec un certificat auto-signé, qui, à mon avis, est tout aussi sécurisé que celui que j'achète auprès d'une entreprise, mais Windows ne le chargera pas. Windows acceptera volontiers un fichier MSI auto-signé, cependant .) Tant que je peux utiliser WinUI 3 à partir d'une application basée sur MSI, je suis content.
2. Un meilleur concepteur XAML serait grandement apprécié, mais je n'ai pas besoin de la complexité supplémentaire d'intégrer les concepteurs WinUI XAML et WinForms/WPF en un seul. Je suis parfaitement d'accord avec le basculement entre les différents onglets dans VS.
3. Comme je l'ai commenté précédemment , le découplage du compilateur XBF des systèmes de projet C# et Visual Basic serait très utile. (Ce serait encore mieux si la source du compilateur XBF, ou une documentation suffisante pour le recréer, était publiée, mais je ne sais pas quelle est la probabilité que cela se produise.)
4. Meilleure prise en charge de C++/WinRT et MIDL 3 dans le système de projet C++. Actuellement, le support du projet pour l'utilisation de C++/WinRT est fragile et maladroit. (Par exemple, si vous modifiez l'espace de noms dans le fichier IDL - ce qui est souvent requis s'il y a un point dans le nom du projet que vous souhaitez utiliser dans les espaces de noms, car le modèle les convertit automatiquement en traits de soulignement - votre projet échouera à compiler , et la résolution du problème d'après mon expérience nécessite de déplacer les fichiers *.h et *.cpp , de les régénérer à partir de zéro, de copier le code, puis de décharger et de modifier le fichier vcxproj pour corriger l'imbrication.) Autant j'aimerais utiliser quelque chose de plus moderne et flexible que vcxproj, autant je ne peux pas le faire en raison de la forte dépendance du compilateur XBF à son égard.

Si quelque chose d'autre arrive, je ne manquerai pas de le poster ici. Merci!

1. Ce que je me demande ici, est ... Eh bien, dois - je utiliser le préfixe d'espace de noms comme < winui: Listview ou < contrôles: listview ou quelles que soient les devs décide? Je pense qu'il serait bien mieux, si possible, d'avoir la même expérience que maintenant, juste Le préfixe est ok, et génial, pour seulement quelques contrôles. Mais lorsque vous commencez à utiliser partout, cela fait de la lecture XAML un cauchemar et très.
   Cela n'a pas de sens d'utiliser un préfixe d'espace de noms, car il ne sera pas possible d'utiliser Windows.UI.Xaml.Controls et WinUI sera le choix par défaut.

2. Pour le moment, je n'utilise même pas le concepteur XAML. Je désactive littéralement dans les paramètres. XAML Designer est lent et a besoin d'un meilleur support. C'était bien pour WPF, mais pas pour UWP, surtout si vous voulez faire du responsive design, gérer des pages, afficher des données, etc.
   C'est probablement un retour pour le futur lointain, mais je pense que c'est un bon retour à regarder. Le concepteur WPF est beaucoup plus rapide.
   C'est à cause du bac à sable ou quoi ?

3. Serait intéressant un outil pour faire une migration. D'autant plus qu'il peut avoir quelques problèmes de compatibilité avec les contrôles WinUI 3.0 mis à jour, comme ScrollViewer. Donc, s'il existe un outil, il devrait au moins afficher les avertissements possibles sur ces contrôles mis à jour/réécrits.

1. Nous avons besoin d'un éditeur de code xaml robuste avec IntelliSense séparé du concepteur.
   La plupart du temps, je n'écris que du code xaml comme C#. Actuellement, l'éditeur de code est lent et fragile, expliqué dans mon commentaire précédent . L'expérience IntelliSense est également assez simple. Aucune information de documentation rapide, aucun changement de nom de membre.
2. La prise en charge des données de conception pour x:Bind peut être assez difficile, car j'écris une aide complexe dans les liaisons de fonction. Mais les choses peuvent être meilleures si les fonctionnalités intégrées de xaml peuvent remplacer certaines aides.
3. Je veux beaucoup plus de combinaisons gratuites de modèles d'emballage pour mes applications. Peut-être hors sujet, mais je ne trouve aucun commentaire à l'équipe de modélisation de l'application.

TL; DR Je veux qu'un modèle d'application prenne en charge la

Quelqu'un peut-il me dire comment réduire cela?

Tout d'abord, j'utilise également l'application que je développe quotidiennement (et j'utilise>> déboguer la plupart des jours). Donc, faire coexister la version dev avec la version stable m'aidera beaucoup. Actuellement, je dois augmenter le numéro de version, emballer un msix de débogage, mettre à jour la version du package installé pour déboguer.
Au cours des différentes phases de débogage, je souhaiterai des capacités différentes. Pour les données complexes du monde réel, je souhaite que l'instance de débogage partage les données avec une instance stable. Pour les fausses données arbitraires, je veux cependant l'isolement. Ceci est théoriquement résolu en accédant aux données à l'aide du sélecteur de dossier, mais c'est vraiment désolé que SQLite dans UWP ne le supporte pas, et il n'y a pas d'autre moteur ACID intégré à ma connaissance.

Oh, et autre chose. J'apprécierais vraiment, _vraiment_ si quelque chose pouvait être fait sur la façon dont vcxproj nécessite l'utilisation de packages.config pour les références de package NuGet. WinUI est distribué sous forme de package NuGet, tout comme C++/WinRT et d'autres composants clés. Je n'aime vraiment pas utiliser packages.config. PackageReference est beaucoup plus efficace (et il n'en résulte pas une construction cassée si vous déplacez le vcxproj dans un répertoire différent). Il fonctionne réellement lorsqu'il est utilisé à partir d'un vcxproj, tant que la cible de restauration est exécutée au moment approprié. (C'est parce que les cibles vcxproj importent indirectement la machine de restauration PackageReference pour les projets C# non SDK.) J'ai écrit un ensemble de cibles qui exécutent automatiquement la cible de restauration lorsque l'ensemble d'éléments PackageReference a changé, car VS ne le fera pas lui-même (encore). Malheureusement, le système NuGet n'en sait rien et, en tant que tel, il tente d'ajouter un fichier packages.config lorsque j'ajoute un modèle de fichier C++/WinRT. Cela provoque toutes sortes de ravages, entraînant la levée d'une exception et un fichier de projet cassé. Je ne suis pas sûr de la meilleure façon de résoudre ce problème, mais j'apprécierais vraiment qu'il soit au moins examiné avant la sortie de WinUI 3. Merci!

Ce serait bien si WinUI prend en charge le nouveau projet sdk - Microsoft.NET.Sdk ou MSBuild.Sdk.Extras .
Les fichiers csproj de style ancien sont difficiles à maintenir. Et nous ne pouvons pas utiliser plusieurs TargetFrameworks avec, ce qui pourrait être utile pour la migration vers WinUI.

Pourquoi pas de support F# ?

Les fonctionnalités Azure DevOps et Visual Studio App Center doivent-elles être abordées ici ?

Comme @vitorgrs , je préfère les contrôles natifs sans préfixe d'espace de noms, cela ajoute du "bruit" au code. Et cela aide de voir quels sont les contrôles natifs et ceux de tiers.

Un outil de migration serait bien sûr bien. Si cela fonctionne avec les grands fournisseurs tiers (Telerik, DevExpress,...) ce serait déjà un gros problème.

Modèles

Existe-t-il un intérêt/un besoin pour les versions précédentes des modèles UWP XAML de rester dans le nouveau flux de projet VS ?

De mon côté, il n'est pas nécessaire de conserver les modèles. Mais se pourrait-il que UWP ait un contrôle qui n'est pas dans WinUI ? Si cela pouvait arriver, cela pourrait être une raison valable pour créer une application UWP traditionnelle et la migrer vers WinUI lorsque le contrôle requis est là. Ensuite, le modèle peut être nécessaire.

C'est peut-être aussi déroutant pour les développeurs si vous avez créé une application et que vous ne pouvez plus la créer avec la dernière version de Visual Studio.

Mais personnellement, je n'ai pas intérêt à garder les modèles

Comment pouvons-nous vous aider à être plus efficace ou plus performant en ce qui concerne les modèles et les composants dans Visual Studio ?

Pour moi, cela semble très bien pour UWP. Maintenant, je veux voir la même chose pour Win32. :)

Cette visite guidée est-elle utile et aimeriez-vous en voir plus au fur et à mesure que les scénarios prennent forme ?

Oui définitivement. Cette visite guidée est très utile pour comprendre à quoi pourrait et devrait ressembler l'avenir. J'aimerais en voir plus.

Migration

Serait-il avantageux de fournir un outil de migration qui automatise les étapes 1 à 3 ?

Absolument. Peut-être qu'une petite extension Visual Studio serait une excellente option pour cette migration. Je peux aussi penser à quelque chose comme un "Analyseur de compatibilité WinUI" qui affiche ce qui peut être migré et ce qui ne l'est pas. Quelque chose de similaire à l'analyseur de portabilité .NET.

Quelles bibliothèques utilisez-vous en dehors du jeu de contrôle natif Windows 10 ?

Généralement Telerik DataGrid et Community Toolkit

De quelles manières pouvons-nous aider à la migration à laquelle nous ne pensons pas actuellement ?

Si vous ouvrez une application UWP dans Visual Studio dont la version est inférieure à celle du SDK Win que vous avez installé, Visual Studio la migre pour vous. Vous devriez peut-être penser à quelque chose comme ça pour la migration WinUI aussi. Je ne suis pas sûr, mais c'est quelque chose à garder à l'esprit. Surtout lorsque Visual Studio n'a plus les modèles UWP normaux, il peut être déroutant pour les développeurs d'avoir une application que vous ne pouvez pas créer avec un modèle.

Autres

Comme déjà mentionné dans d'autres commentaires, je pense qu'il est temps de passer aux fichiers .csproj de style SDK.

ajouter des modèles winui 3.0 au studio de modèles Windows.

WinUI dans les applications de bureau

WinUI in Desktop permettra aux développeurs d'utiliser la bibliothèque d'interface utilisateur Windows sur un modèle d'application de bureau. @marb2000 travaille sur un article de discussion plus détaillé dans les semaines à venir. N'hésitez pas à utiliser ce fil jusque-là pour des suggestions.

En tant que développeur .net, c'est la partie qui m'intéresse le plus.

Modèles

• Existe-t-il un intérêt/un besoin pour les versions précédentes des modèles UWP XAML de rester dans le nouveau flux de projet VS ?

Selon le nombre de modèles. Si le nombre est faible (par exemple, seule la "Blank App (Universal Windows)" par langue, donc 1 dans le cas de c#), le bruit est faible et peut être pris en charge. Mais si cela implique plus que quelques modèles, ne les incluez pas par défaut et ajoutez un composant d'installation VS facultatif pour les ajouter.

• Comment pouvons-nous vous aider à être plus efficace ou plus performant en ce qui concerne les modèles et les composants dans Visual Studio ?

Gardez un vrai modèle vierge sans échafaudage (mieux pour les tutoriels). Jetez un œil à ce que fait le noyau asp.net, il y a beaucoup de changements qu'ils ont fait dans leur nouvelle expérience de projet. En gros, vous choisissez un modèle générique "App (UWP WinUI)", puis un deuxième écran, spécifique à votre modèle d'application vous permet de choisir parmi différents modèles. Utilisez cette étape pour choisir également la version minimale et cible de la plate-forme (donc aucune étape supplémentaire). Vous pouvez ajouter une option pour créer directement le projet de packaging de l'application par exemple.

Fournir également un bon support pour les composants dans la boîte à outils entre les projets. Les nouveaux contrôles doivent être affichés immédiatement dans la boîte à outils, regroupés par projets. Peut-être un support pour les icônes de créateurs pour aider à les distinguer.

• Cette visite guidée est-elle utile et aimeriez-vous en voir plus au fur et à mesure que les scénarios prennent forme ?

Oui

Support linguistique

• Serait-il avantageux de fournir un outil de migration qui automatise les étapes 1 à 3 ?

Une bonne documentation (une page avec des étapes claires) devrait suffire. Si tout peut être fait à partir de VS sans modifier le csproj à la main, je suggère de n'ajouter qu'une page de documentation décrivant les étapes.

Si vous décidez (et j'espère que vous le ferez) de passer au nouveau format csproj, alors un outil de migration sera certainement nécessaire, car la migration nécessitera la modification du fichier csproj.

Emballage

MSIX est la méthode de packaging moderne pour toutes les applications. Pour WinUI dans Win32 devrions-nous prendre en charge ClickOnce ? Pour quelles autres méthodes d'emballage devrions-nous inclure un support ? Surtout pour WinUI dans Win32

Comparez les différences entre le déploiement clickonce et msix :

1. la fonction App Installer n'offre pas la même expérience sur les anciennes versions de Windows
2. MSIX requiert un package signé valide (interne ou public). Clickonce prend en charge les packages auto-signés.
3. le modèle de package a certaines limitations, principalement causées par l'environnement isolé (pas d'accès local aux appdata par exemple, pas d'opération élevée).

Pour moi, le problème le plus ennuyeux est le 2. Nous avons généralement des applications clickonce qui sont déployées en interne avec des ordinateurs non enregistrés avec un domaine. Donc, pour ce type d'applications, il nous faudra signer le package avec un certificat de signature public valide.

Il est difficile d'anticiper toutes les différences entre ces deux frameworks, car le format d'emballage Appx n'est souvent annoncé que pour les applications ciblant le Store, et lorsque nous voyons des limitations, nous ne savons pas toujours si elles s'appliquent également au format de distribution Web.

• Expérience de concepteur

Performances, performances, performances et accompagnement de grandes solutions avec beaucoup de projets.

La version WinUI du SDK Windows 10 et le concepteur WinUI Xaml seront-ils rendus open source ?

Serons-nous en mesure de publier des demandes pour le flux de travail et l'expérience au moment de la conception ?

Le SDK suivra-t-il une cadence de publication similaire à celle des versions nuget de WinUI ?

Quelques douleurs supplémentaires :
améliorer l'expérience de débogage de mixage managé-non managé.
Actuellement, lorsqu'une exception se produit dans le code non managé, COMException est affiché dans le site de débogage managé. Les choses peuvent être pires si la pile d'appels franchit la limite gérée/non gérée plus d'une fois.
Par rapport à WPF, la pile d'appels managée est toujours disponible et l'exception levée porte une chaîne utile pour le débogage.
Je sais que le monde non géré et le modèle COM ne sont pas aussi pratiques que gérés. Mais au moins, lorsqu'une exception (HResult erroné) est levée par le framework, je veux les informations nécessaires pour localiser la ligne de code du référentiel open source. Le chemin peut être manuel, mais doit être déterministe.

Nous comptons beaucoup sur ClickOnce, ce serait donc bien de le soutenir à court terme. Nous serions prêts à migrer vers MSIX, mais après que des fonctionnalités similaires soient proposées.

En ce qui concerne les modèles, ce serait bien d'en avoir un qui fournit une interface utilisateur et un code standard pour une NavigationView et une navigation.

THX

Nous comptons beaucoup sur ClickOnce, ce serait donc bien de le soutenir à court terme. Nous serions prêts à migrer vers MSIX, mais après que des fonctionnalités similaires soient proposées.

En ce qui concerne les modèles, ce serait bien d'en avoir un qui fournit une interface utilisateur et un code standard pour une NavigationView et une navigation.

THX

La structure et les modèles de "shell" d'application les plus courants doivent être disponibles sous forme de modèles afin que les développeurs puissent être opérationnels rapidement. Les applications propriétaires de Microsoft devraient être des exemples dans ces mises en page et agir comme les meilleures pratiques en termes de comportement, de cohérence et d'adhésion aux normes de conception d'interface utilisateur pour Fluent Design et WinUI.

@shaggygi @mdtauk
Pour "la structure et les modèles de "shell" les plus courants de l'application" et "En ce qui concerne les modèles, ce serait bien d'en avoir un qui fournit une interface utilisateur et un code passe-partout pour une NavigationView et une navigation". il y a le Windows Template Studio qui est maintenu et développé à la fois par Microsoft et la communauté. Pour citer son introduction :

Windows Template Studio (WTS) est une extension Visual Studio 2017 et 2019 qui accélère la création de nouvelles applications Universal Windows Platform (UWP) à l'aide d'une expérience basée sur un assistant. Le projet UWP qui en résulte est un code bien formé et lisible qui intègre les dernières fonctionnalités de Windows 10 tout en mettant en œuvre des modèles éprouvés et les meilleures pratiques.

@Felix-Dev y aura-t-il éventuellement des modèles WPF en plus de l'UWP ?

@shaggygi Il y a peut-être de bonnes nouvelles pour vous ! Voir ce fil de discussion : Bien qu'apparemment rien ne soit garanti à ce stade, l'idée de fournir des modèles spécifiquement pour les projets WPF est apparemment explorée. Comme indiqué dans le fil lié, il y a eu une session d'aperçu non publique appelée "Windows Template Studio - WPF Edition" hébergée lors de la Build 2019.

Nous utilisons C++/WinRT. Nous n'utilisons pas le concepteur ou la liaison xaml pour le moment. Mais nous allons créer des contrôles au moment de l'exécution et les styliser éventuellement via UWP xaml. Nous aurons également besoin de boîtes de dialogue et de fenêtres enfants sans mode avec des îlots xaml, y compris des fenêtres d'accueil/flottantes, etc.

J'ai essayé d'écrire du XAML pour mon application C++ et l'expérience a été douloureuse.

J'ai dû ajouter de nombreuses propriétés de projet qui ne sont pas documentées et quelques autres hacks pour tout générer correctement et le conditionner correctement.

Par exemple:

• Lors de la création d'un projet dans lequel stocker mes pages XAML, j'ai dû ajouter <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> et <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> , deux propriétés de projet qui ne sont absolument pas documentées et qui ne sont découvertes qu'en inspectant le nouveau code source du terminal.
• J'ai eu un cryptique "Impossible de créer une nouvelle vue car la fenêtre principale n'a pas encore été créée" jusqu'à ce que je crée et utilise une classe App, ce qu'il n'y a aucun moyen de faire dans VS, sauf de créer une page normale et d'entrer dans les propriétés du XAML dans VS et le changer en une définition d'application, puis ajuster le MIDL, le code source et le fichier XAML.
• J'ai ajouté le package NuGet Microsoft.Toolkit.Win32.UI.XamlApplication pour créer ma classe d'application et je n'ai pas pu la charger avant d'avoir également ajouté Microsoft.VCRTForwarders , encore une fois, j'ai trouvé cela lors de l'inspection de la source du terminal, il n'y a aucune indication sur l'un ou l'autre package nulle part.
• Les PRI n'étaient pas fusionnés en un seul jusqu'à ce que j'ajoute quelque chose dans le fichier .wapproj, donc il n'a pas pu trouver ma ressource XAML.
• Le XBF ne fonctionnait pas jusqu'à ce que j'ajoute <DisableEmbeddedXbf>false</DisableEmbeddedXbf> ce qui désactive étonnamment le XBF intégré au lieu de l'activer. La seule erreur que j'ai eue était une erreur d'analyse XAML sans rien m'indiquant que les fichiers XBF ne fonctionnaient pas.
• maxVersionTested dans mon manifeste d'application a été totalement ignoré jusqu'à ce que je change tout en minuscules, même si les instructions indiquent d'utiliser la version camel case : https://github.com/MicrosoftDocs/windows-uwp/issues/1781 #issuecommentaire -511173811

De plus, C++/WinRT était également un emmerdeur :

• Chaque fois que j'exécutais une construction incrémentielle, j'avais un [msg]redefinition [context]: MyClass pour mes classes personnalisées qui m'empêchaient de construire et ne disparaissaient pas jusqu'à ce que j'exécute une construction propre qui, en raison des en-têtes C++/WinRT, prend des années. Ce problème a en quelque sorte disparu comme par magie à mi-chemin.
• Maintenant, lorsque j'exécute des versions propres, j'obtiens une erreur concernant les en-têtes manquants. Appuyez une deuxième fois sur le bouton de construction pour le faire fonctionner à nouveau.
• J'ai dû écrire ma propre classe AppT<> cause d'un mauvais codegen de C++/WinRT. L'application Terminal et l'exemple d'îlots XAML font de même, comme s'il s'agissait de quelque chose que les utilisateurs devaient faire à la place du problème racine en cours de résolution.
• Changer quoi que ce soit dans les fichiers MIDL entraîne des erreurs de construction jusqu'à ce que je fasse une construction propre.

Même dans ce cas, cela ne fonctionne toujours pas non compressé même lors de l'ajout de activatableClass à mon manifeste d'application (quelque chose à propos de ne pas pouvoir trouver la ressource XAML, comme lorsque je n'avais pas fusionné les PRI), ce qui est important pour que mon application prenne en charge.

Migration

L'automatisation pour les étapes 1 à 3 est vraiment utile, d'autant plus que le renommage des espaces de noms sur des centaines de fichiers prend beaucoup de temps et est sujet à des erreurs. En plus de cela, un analyseur compatible serait bien, tout comme le framework .net > .net core, qui crée un rapport sur la compatibilité de la base de code actuelle et note tous les changements possibles nécessaires.

Outillage

Comme d'autres l'ont déjà dit, un éditeur plus riche en fonctionnalités serait bien. La plupart du temps ici au travail, XAML est fait à la main et utilise principalement le concepteur comme guide sur le squelette approximatif de l'apparence de l'application. Intellisense et les refactorisations intelligentes seraient vraiment utiles, des choses QoL comme CTRL + R + R pour renommer des choses (par exemple, les propriétés de dépendance ou même la balise) par exemple, surtout lorsque vous avez tendance à avoir beaucoup de UserControls et aussi GoTo Implémentation et références. Le support de l'analyseur Roslyn serait également très bon.

Pour développer les améliorations de l'espacement des noms. Ce serait bien s'il était possible d'avoir des contrôles personnalisés sans préfixe plus faciles à faire sans ajouter un nouveau XmlnsDefinition s à l'espace de noms par défaut, cela désencombre le balisage imo et n'aurait besoin de préfixes que lorsqu'il y a des contrôles ambigus trouvés comme comment les classes fonctionnent, cela s'intégrerait également bien avec l'implémentation de GoTo. Normalement, le nom du contrôle et peut-être le survol pour afficher l'espace de noms complet serait suffisant pour savoir d'où il vient.

Principalement sur l'outillage, ce serait bien s'il se comporte comme l'éditeur C# pour rendre les refactorisations moins fragiles ou compliquées et faciliter la navigation dans le balisage. En dehors de cela, comme pour le langage XAML lui-même, réduire la verbosité serait également un bon exemple, le style tel que discuté n ° 62 et n ° 279.

Pour développer les améliorations de l'espacement des noms. Ce serait bien s'il était possible d'avoir des contrôles personnalisés sans préfixe plus faciles à faire sans ajouter un nouveau XmlnsDefinition s à l'espace de noms par défaut, cela désencombre le balisage imo et n'aurait besoin de préfixes que lorsqu'il y a des contrôles ambigus trouvés comme comment les classes fonctionnent, cela s'intégrerait également bien avec l'implémentation de GoTo. Normalement, le nom du contrôle et peut-être le survol pour afficher l'espace de noms complet serait suffisant pour savoir d'où il vient.

J'aimerais penser que la version WinUI 3.0 du contrôle Page éliminerait la nécessité d'utiliser un préfixe pour ces contrôles. Je suppose que ce serait une chose au niveau du SDK.

Est-il possible de ne pas modifier les espaces de noms lors de l'utilisation de WinUI ?

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 plus rapides, avec tous les avantages des deux et aucun des problèmes.

Je ne pense pas qu'il soit nécessaire de fournir un outil de portage. C'est un changement unique, assez facile avec Find&Replace, et le nombre d'instances va être assez faible.

Également rencontré plus de problèmes:

• Après avoir ajouté des ressources à la classe App , mon XAML n'a pas pu le trouver jusqu'à ce que j'ajoute ceci, encore une fois trouvé à partir de l'application Terminal et sans trop d'idées sur ce qu'il fait vraiment :
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• La construction se brisera complètement au hasard avec une erreur similaire à cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication et le seul moyen de récupérer la construction du projet est de faire une construction propre
• Je ne peux pas exécuter l'application en définissant directement le vcxproj pour l'exe principal en tant que projet de démarrage, je dois démarrer manuellement la sortie appx non emballée dans bin\x64\Debug\AppX , puis injecter un débogueur à partir de VS, ou définir le package d'application comme processus de démarrage.

Éléments connexes sur le bureau Windows : .NET Community Standup - 25 juillet 2019 si vous

LONGTEMPS WinForms, développeur WPF ici avec une certaine expérience UWP. Voici mes 2 centimes :

Migration

• Un outil pour migrer les applications UWP existantes vers WinUI est indispensable.
• Un outil pour convertir les contrôles WinForms ou WPF en contrôles WinUI dans une application existante serait plus que génial. Par convertir les contrôles, j'entends changer les références dans le conteneur aux contrôles individuels.
• Un outil pour migrer Xamarin Forms vers WinUI pour permettre le rétroportage d'une application mobile vers Windows.

Outillage

• L'éditeur XAML actuel est affreux ! Il doit utiliser le canevas de l'éditeur de texte normal et fournir des fonctionnalités Roslyn à appliquer au modèle d'objet XAML pour une meilleure intellisense et des refactorisations.
• Jusqu'à ce que Visual Studio soit en 64 bits, l'éditeur XAML doit être une application 64 bits autonome en coulisses. Je dois constamment redémarrer VS 2017 et VS 2019 pour arrêter les erreurs de mémoire insuffisante lorsque je travaille avec beaucoup de XAML.

Modèles

• Nous avons besoin de ces modèles de projet

  • NavigationView WinUI
  • NavigationView WPF
  • Ruban WinUI
  • Ruban WPF
  • Ruban WinForms

• Nous avons besoin de ces modèles de page/fenêtre

  • Page du contrôleur multimédia
  • Navigateur
  • Fenêtre de dialogue
  • Fenêtre sans bordure
  • Fenêtre flottante

• Nous avons besoin de modèles de contrôle

  • Vue grille de données encapsulée
  • Vue de données enfant encapsulée

Ces deux derniers fonctionneraient ensemble pour créer des fenêtres maître-détail faciles.

tous ces modèles et pages, etc. sont déjà en cours de réalisation dans le projet Windows Template Studio, pourquoi ne pas suivre le même chemin au lieu de tout recréer ?

Fichier de projet de style SDK
L'un des éléments les plus importants que j'aimerais voir - comme beaucoup d'autres l'ont également mentionné - est la prise en charge du nouveau format de fichier de projet SDK Style pour les applications UWP et "Desktop XAML".

Migration entre les modèles d'application UWP et Desktop XAML
Si nous commençons à créer une application "Desktop XAML", à quelle distance sera-t-elle d'une application UWP ? Sera-t-il trivial de le transformer plus tard en application UWP si nous nous rendons compte que nous sommes restés dans les contraintes du bac à sable UWP ? Ou si nous commençons à créer une application UWP et réalisons que nous avons besoin de plus, sera-t-il facile de la transformer en une application « Desktop XAML » ?

Je suis avec le support de Template Studio.

Je suis avec le support de Template Studio.

Template Studio prend-il en charge les projets XAML C++ ?

Ce que Template Studio fait devrait faire partie du WinUI SDK IMO

Ce que Template Studio fait devrait faire partie du WinUI SDK IMO

Devrait faire partie de Visual Studio IDE IMO ! ??

les gars, le fait est que Windows Template Studio fait tout en un pour la création de projets UWP, donc gardez cela à l'esprit s'il manque quelque chose comme la prise en charge de xaml c++, nous devrions envisager de l'ajouter à Windows Template Studio, je pense que ce sera plus rapide et plus efficace si toutes les nouvelles innovations des projets uwp restent dans un seul projet.

Qu'il y ait une méthode pour utiliser la couche inférieure de la pile de WinUI 3 directement sans XAML ou même MVVM. Ceci est particulièrement utile pour les logiciels C++ existants qui ont déjà une sorte d'architecture MV-quel que soit dans leur base de code. Ils veulent juste quelque chose de mieux que HWND + GDI.

Et, s'il vous plaît, faites croire aux gens que WinUI 3 n'est pas un jouet, il peut vraiment supporter des logiciels sérieux .

@be5invis Je suis tout à fait d'accord. La seule solution pour le moment est XamlDirect, mais elle s'adresse davantage aux développeurs de middleware.

Vous pouvez déjà créer manuellement du contenu avec Xaml Islands. Il suffit de faire fonctionner un DesktopWindowXamlSource et de l'attacher à une fenêtre, puis de créer et d'organiser/disposer des contrôles dans le code.

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

@MarkIngramUK Ils peuvent avoir besoin de quelque chose de plus "complet", comme remplacer CreateWindow par des fonctions WinUI.

Pour des raisons de conception, j'aimerais vraiment que les futurs modèles WinUI WPF prennent en charge l'extension du contenu d'une page dans la barre de titre, comme celui des applications UWP actuelles. À l'heure actuelle, avec la solution d'îlots XAML existante, nous hébergeons simplement des contrôles dans une fenêtre WPF/WinForms plutôt que dans une vue moderne.

@LucasHaines La liste des langages que nous prévoyons de prendre en charge avec WinUI 3.0 : C#, C++/WinRT, Visual Basic. Nous explorons la prise en charge de F#.

Cela montre que vous vous trompez, pas seulement pour F# mais pour tous les langages .Net. Vous commencez par penser aux modèles et aux fichiers .xaml, ce qui revient à construire une maison et à mettre en place des tapis et des rideaux sans avoir terminé la structure.

Vous devriez pouvoir installer WinUI dans n'importe quel projet .Net Standard 2.0/.Net Core 3.0/.Net 5 en tant que package Nuget. Ensuite, vous avez accès à toutes les classes définies à l'intérieur. Vous pouvez ensuite référencer de tels projets à partir d'un projet WinUI (qui peut être uniquement en C#). Cela permet de créer des vues WinUI dans n'importe quel langage .Net. Découvrez comment Xamarin.Forms le fait .

Les classes sont déjà disponibles pour une utilisation en F# (puisqu'il s'agit de composants Windows Runtime, utilisables par tous les langages .NET)

Vous pourrez créer manuellement une mise en page. Vous pouvez même le faire via Python en utilisant Py/WinRT pour tous les soins WinUI.

@sylveon Quelles classes spécifiquement ? je serais intéressé...

Tous. L'API publique de WinUI n'est constituée que de composants Windows Runtime.

@LucasHaines La liste des langages que nous prévoyons de prendre en charge avec WinUI 3.0 : C#, C++/WinRT, Visual Basic. Nous explorons la prise en charge de F#.

Cela montre que vous vous trompez, pas seulement pour F# mais pour tous les langages .Net. Vous commencez par penser aux modèles et aux fichiers .xaml, ce qui revient à construire une maison et à mettre en place des tapis et des rideaux sans avoir terminé la structure.

Vous devriez pouvoir installer WinUI dans n'importe quel projet .Net Standard 2.0/.Net Core 3.0/.Net 5 en tant que package Nuget. Ensuite, vous avez accès à toutes les classes définies à l'intérieur. Vous pouvez ensuite référencer de tels projets à partir d'un projet WinUI (qui peut être uniquement en C#). Cela permet de créer des vues WinUI dans n'importe quel langage .Net. Découvrez comment Xamarin.Forms le fait .

Ce sujet/question concerne l'outillage. Oui, les bibliothèques peuvent être directement référencées à partir de n'importe quel langage capable de les consommer, mais il y a un flou des définitions entre l'outillage et le support du langage.
Prenant Xamarin.Forms comme exemple. Cela ne fournit que des outils pour C# et dans une moindre mesure F#. Il est possible de créer des applications avec VB.Net et Xamarin.Forms, mais ce n'est pas _officiellement pris en charge_ car il n'y a pas d'outils et seulement une documentation limitée pour le faire.

De plus, comme WinUI est spécifique à Windows, il ne peut pas être référencé dans n'importe quel projet .Net Standard 2.0/.Net Core 3.0/.Net 5.
Il existe également un besoin de prise en charge du niveau projet/compilateur/empaquetage pour certains scénarios.

Excellente équipe de travail sur la version 2.2 . Une chance que nous puissions obtenir une brève mise à jour sur l'état de la v3.0 ?

Je vois cela mentionné plusieurs fois mais aucune direction claire dans un sens ou dans l'autre. Étant donné que WinUI 3.0 aura désormais tous les contrôles, l'exigence d'espace de noms pour référencer les contrôles de la bibliothèque WinUI DOIT être supprimée. Cela encombre beaucoup XAML, entrave considérablement la migration et rompt la compatibilité simple avec des éléments tels que la plate-forme UNO et Avalonia.

Veuillez supprimer le besoin de xmlns:mux="using:Microsoft.UI.Xaml.Controls" de XAML. Je comprends que le code derrière doit encore changer. Il pourrait également y avoir une configuration pour cela quelque part dans le projet.

Veuillez supprimer le besoin de xmlns:mux="using:Microsoft.UI.Xaml.Controls" de XAML.

Cela ne sera pas requis dans le _markup_ XAML, mais la modification des espaces de noms dans le code-behind serait toujours requise.

Si vous souhaitez utiliser les contrôles Windows (s'ils ne sont pas supprimés du système d'exploitation) - Vous devriez avoir à déclarer l'espace de noms en XAML

Si vous souhaitez utiliser les contrôles Windows (s'ils ne sont pas supprimés du système d'exploitation) - Vous devriez avoir à déclarer l'espace de noms en XAML

Avec WinUI 3.0, ce n'est pas un scénario - vous ne pouvez pas mélanger et faire correspondre les contrôles du système d'exploitation avec les contrôles WinUI 3.0. Cela ne fonctionne qu'avec WinUI 2.x pour le moment, car ces contrôles sont des modules complémentaires au système d'exploitation (et nous avons beaucoup de cas délicats où nous avons expédié le type aux deux endroits comme NavigationView et TreeView provoquant une ambiguïté).

Si vous souhaitez utiliser les contrôles Windows (s'ils ne sont pas supprimés du système d'exploitation) - Vous devriez avoir à déclarer l'espace de noms en XAML

Avec WinUI 3.0, ce n'est pas un scénario - vous ne pouvez pas mélanger et faire correspondre les contrôles du système d'exploitation avec les contrôles WinUI 3.0. Cela ne fonctionne qu'avec WinUI 2.x pour le moment, car ces contrôles sont des modules complémentaires au système d'exploitation (et nous avons beaucoup de cas délicats où nous avons expédié le type aux deux endroits comme NavigationView et TreeView provoquant une ambiguïté).

Bon à entendre. Il sera plus facile de déprécier cela du système d'exploitation. J'espère que l'application Paramètres, le Shell et d'autres parties du système d'exploitation passeront également à WinUI 3.0.

Et espérons que les ports des outils d'administration, Wordpad, etc. vers XAML réutiliseront le même code autant que possible !

@jevansaks Ok,

@mdtauk Il ne sera pas nécessaire de faire la distinction entre les contrôles hérités « OS » et les nouveaux contrôles de plate-forme « WinUI 3.0 » en XAML. Tout se déplace vers WinUI 3.0 et les contrôles du système d'exploitation ne reçoivent plus de mises à jour de fonctionnalités comme vous le savez. Après WinUI 3.0, si un développeur souhaite toujours cibler les contrôles hérités, il doit les développer avec des kits de développement logiciel plus anciens et des versions de Visual Studio. Le maintien de la possibilité de référencer deux bibliothèques de contrôle d'interface utilisateur Microsoft/Windows à partir de XAML ne serait qu'un obstacle pour les raisons indiquées précédemment. En outre, avec le découplage de WinUI, le développement peut enfin passer à une voie durable consistant à "autoriser" des changements comme celui-ci - ce qui n'est même pas une rupture.

Edit : J'ai oublié de rafraîchir avant de répondre, la plupart de ces informations sont redondantes maintenant.

@robloo Je suis heureux que cela remplace véritablement les versions précédentes d'UWP Xaml. J'espère également que le système d'exploitation pourra y accéder pour les applications de la boîte de réception et le shell.

J'espère également qu'il y aura beaucoup de vidéos de développeurs détaillant le processus de migration vers WinUI 3.0 - et comment travailler avec WinUI 3.0 avec le même cycle de vie que les applications Win32. Plus besoin de réhydrater, de meilleures façons d'enregistrer l'état de la page et la navigation, etc.

Il pourrait être utile (selon les applications qui prévoient de passer à WinUI 3.0) de fournir des exemples de prise de Wordpad et de déplacement de code vers une nouvelle interface utilisateur intégrée à WinUI - ainsi que de prendre une application de boîte de réception comme Groove Music, et de déplacer cela sur à WinUI 3.0

Pour WinUI 3, il doit y avoir une certaine cohérence en ce qui concerne le placement des fonctions d'application dans le langage de conception.

À cet égard, les paramètres de l'application.

Où puis-je trouver les paramètres de l'application ? Dois-je cliquer sur l'engrenage dans le coin supérieur droit ? En bas à gauche ? Dois-je cliquer sur l'avatar du profil en haut à droite et appuyer sur les paramètres ? Dois-je cliquer en haut à gauche ? En bas à gauche? Dois-je aller dans Edition > Préférences ?

Cela dépend vraiment de si vous utilisez NavigationView...

De : shaheedmalik [email protected]
Envoyé : jeudi 12 septembre 2019 15:48:12
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja Sharp [email protected] ; Commentaire [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Expérience et outils des développeurs WinUI 3.0 - Input Needed (#1045)

Pour WinUI 3, il doit y avoir une certaine cohérence en ce qui concerne le placement des fonctions d'application dans le langage de conception.

À cet égard, les paramètres de l'application.

Où puis-je trouver les paramètres de l'application ? Dois-je cliquer sur l'engrenage dans le coin supérieur droit ? En bas à gauche ? Dois-je cliquer sur l'avatar du profil en haut à droite et appuyer sur les paramètres ? Dois-je cliquer en haut à gauche ? En bas à gauche? Dois-je aller dans Edition > Préférences ?

-
Vous recevez ceci parce que vous avez commenté.
Répondre à cet e - mail directement, vue sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , ou couper le fil https: // GitHub. com/notifications/unsubscribe-auth/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

Comment pouvons-nous vous aider à être plus efficace ou plus performant en ce qui concerne les modèles et les composants dans Visual Studio ?

Cela ne devrait pas nécessiter d'efforts importants et d'attributs de configuration de projet non documentés pour faire fonctionner les îles WinUI/XAML avec C++/WinRT dans Visual Studio.

Je ne saurais trop insister sur ce point, mais la chose la plus importante pour moi est que WinUI rend plus que Windows.

Dès que j'ai vu le Surface Duo, je me suis demandé quelle serait l'histoire du développement multiplateforme maintenant que Microsoft sort un appareil Android. Xamarin.Forms ne le coupe pas pour un certain nombre de raisons évidentes. Il est temps que Microsoft adopte pleinement une boîte à outils multiplateforme (comme la plate-forme UNO mais finie et stable) dont nous savons tous qu'elle a été demandée sous diverses formes depuis des années. J'espère que Microsoft a quelques plans non-dits pour les développeurs ici.

Satya a déclaré "Nous ne voulions pas simplement créer de l'expérience et un seul appareil, mais cela couvre tous les appareils de notre vie." Si vous voulez que les développeurs vous accompagnent pour cette balade comme Panos l'espère, c'est la meilleure façon de le faire. Sinon, vous demandez aux développeurs d'écrire deux interfaces utilisateur distinctes pour couvrir «l'expérience» entre Surface Duo et le reste de la famille. Je ne pense pas que ce soit une demande juste pour les développeurs au sein d'une "famille" d'appareils.

Le rendu est différent sur chaque plate-forme, c'est-à-dire "l'aspect et la convivialité natifs".

Je ne comprends pas. S'il vous plaît ne le faites pas, la dernière chose que je veux que Fluent Design fasse est de provoquer plus d'incohérences pas moins.

EDIT : commentaire d'origine supprimé

Satya a déclaré "Nous ne voulions pas simplement créer de l'expérience et un seul appareil, mais cela couvre tous les appareils de notre vie." Si vous voulez que les développeurs vous accompagnent pour cette balade comme Panos l'espère, c'est la meilleure façon de le faire. Sinon, vous demandez aux développeurs d'écrire deux interfaces utilisateur distinctes pour couvrir «l'expérience» entre Surface Duo et le reste de la famille. Je ne pense pas que ce soit une demande juste pour les développeurs au sein d'une "famille" d'appareils.

C'est EXACTEMENT pourquoi j'étais découragé que le Duo soit Android.

Les modèles doivent être open source pour supprimer tous les problèmes qui se posent.

Quand j'utiliserai WinUI avec WPF, et quand je créerai un nouveau contrôle avec du code comme :
c# public class MyControl : UserControl { ... }
Il utilisera WinUI.UserControl ou WPF.UserControl ?
Aurons-nous besoin de choisir et comment y faire face ?

Et intéressant, si les outils XAML doivent être unifiés, aurons-nous la possibilité de créer une sorte de fichiers xaml partagés ?
Quelque chose comme:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Devrait-il s'agir d'une sorte de dialecte partagé avec un espace de noms racine spécial ? (comme les projets partagés dans Visual Studio). Cela pourrait ressembler à du xaml conditionnel.

Il utilisera WinUI.UserControl ou WPF.UserControl ?
Aurons-nous besoin de choisir et comment y faire face ?

Cela devrait se produire automatiquement dans le XAML où vous définissez

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Cela indique au compilateur que c'est UWP.

public class MyControl : UserControl { ... }

C'est en fait incorrect. Tu devrais déclarer comme ça

public partial class MyControl { }

Aucun héritage n'est nécessaire car il est géré par le fichier .g.cs qui spécifie l'héritage ainsi que le framework utilisé.

À propos des modèles, je serais plus heureux s'il y avait plus qu'un modèle Hello World. Ce que je veux dire, c'est que Microsoft devrait sauvegarder certains frameworks périphériques reconnus nécessaires pour fonctionner avec les applications clientes

@weitzhandler J'adorerais voir ça aussi !!

Les projets de style SDK pour les projets C# et Cpp/WinRT devraient également être indispensables

Je pense qu'il devrait y avoir des modèles pour tous les modèles d'applications Win32 et Inbox courants. Une courte liste du haut de ma tête:

• Ruban
• Menu principal
• Interface de document à onglets
• Vue de navigation
• Commande/Barre d'outils
• Vue de navigation supérieure
• Hub/Galerie (je sais que c'est légèrement obsolète)
• Treeview/MasterDetails (Explorateur de fichiers, RegEdit, Application d'administration)

Mais il devrait également y avoir des modèles d'éléments pour les boîtes de dialogue, les pages, les pages de paramètres, etc.

Comment pouvons-nous vous aider à être plus efficace ou plus performant en ce qui concerne les modèles et les composants dans Visual Studio ?

Travaillez avec l'extension C++ pour VSCode/Visual Studio. Je souhaite également voir VS Code comme un éditeur pris en charge qui offre une expérience similaire à Visual Studio. WinUI est censé être OSS, tout comme VS Code, donc je pense que c'est faisable.

Des outils tels que Template10 et Windows Template Studio sont des signes de manque de fonctionnalités de base. Avec WinUI3, il devrait y avoir des fonctionnalités en place pour ce que font ces outils. Je parie que beaucoup de développeurs font cet échafaudage de base encore et encore... il devrait faire partie du framework. Aucun outil supplémentaire ne devrait être nécessaire. Peut-être devriez-vous même devoir désactiver l'échafaudage MVVM pour les rares cas où vous voudriez vous en passer.

Après avoir travaillé avec ASPNET Core, il me manque l'injection de dépendance. Cette fonctionnalité est présente nativement dans ASPNET Core. Cela fonctionne, sans que vous fassiez quoi que ce soit de plus. Et vous pouvez ajouter ou modifier des services si facilement si vous le souhaitez. Mais pour UWP aujourd'hui, vous devez le construire vous-même ou utiliser quelque chose comme WTS pour commencer, mais on a toujours l'impression qu'il est collé par la suite. WinUI3 avec une injection de dépendance native appropriée serait très utile.

Je ne pense pas que la présence de systèmes de modèles montre un manque de fonctionnalités de base, je pense que cela met en évidence la qualité des communautés de soutien qui assembleraient ces systèmes de modèles.

Des outils tels que Template10 et Windows Template Studio sont des signes de manque de fonctionnalités de base.

Je vois des choses comme ça comme une extension des fonctionnalités de base. Bien sûr, des choses comme celle-ci pourraient être apportées en interne, mais il incombe alors davantage à l'équipe principale de les maintenir et de les soutenir. Comme l'équipe de base en fait plus, cela a tendance à signifier qu'elle est plus dispersée et que tout prend donc plus de temps. Si Msft pense qu'ils ont un budget pour apporter des choses comme ça dans l'équipe principale, j'aimerais en parler avec quelqu'un ;)

Juste quelques réflexions sur le style simplifié et les modèles de contrôle, comme faciliter l'ajout d'un comportement personnalisé pour les styles et les contrôles intégrés. Un exemple parfait ici est le style Button , lorsque nous devons remplacer l'ensemble du modèle de contrôle pour changer la couleur du survol ou utiliser le rayon de la bordure. Définir certains d'entre eux directement, comme dans css , empêchera de créer des kilomètres de code XAML

@AntiPasha Avez-vous entendu parler du style Ligthweight ? Avec lui, vous pouvez facilement changer la couleur du survol sans avoir à recréer tout le style :

Changer la couleur de survol d'un bouton serait alors simplement :

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

Une propriété Control.CornerRadius a également été ajoutée dans le SDK 17763 et l'équipe WinUI introduit également des ressources remplaçables pour ajouter facilement une personnalisation à l'échelle de l'application ou de la page sans avoir à modifier le style des contrôles : https://github.com/microsoft/microsoft-ui- xaml-specs/blob/user/chigy/roundedcorner/active/RoundedCorner/roundedcorner.md#customization -options

Et intéressant, si les outils XAML doivent être unifiés, aurons-nous la possibilité de créer une sorte de fichiers xaml partagés ?
Quelque chose comme:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Devrait-il s'agir d'une sorte de dialecte partagé avec un espace de noms racine spécial ? (comme les projets partagés dans Visual Studio). Cela pourrait ressembler à du xaml conditionnel.

@Tirraon c'est un exemple vraiment intéressant, mais je pense que lorsque nous parlons d'outils d'unification, il est préférable de commencer dans l'état d'esprit que les plates-formes vont exister comme elles le font aujourd'hui, et nous n'essayons pas de créer un autre standard Xaml équivalent.

Nous pouvons utiliser l'espace de noms par défaut pour différencier à quelle plate-forme "de niveau supérieur" le fichier xaml appartient, ainsi, par exemple, nous pourrions avoir les espaces de noms par défaut suivants pour chaque plate-forme XAML (ce sont principalement des hypothèses, alors prenez-les avec un grain de sel ):

wpf : xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp : xmlns="http://github.com/microsoft/microsoft-ui-xaml"
avalonie : xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno : xmlns="https://github.com/unoplatform/uno"
xamarin.forms : xmlns="https://github.com/xamarin/Xamarin.Forms"

Donc, pour mélanger WinUI avec WPF en utilisant Xaml Islands, vous avez un balisage qui ressemble à ceci :

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

Qu'est-ce que tu penses?

@stevenbrix
Dans votre exemple pour UWP, les deux boutons seront rendus, n'est-ce pas ?
Je veux dire, par exemple, lorsque xmlns=".../xaml/presentation" est un espace de noms de niveau supérieur et que UserControl wutg StackPanel est disponible à la fois dans uwp et wpf, le deuxième bouton ne serait-il pas également disponible sur les deux plates-formes ?

quand on parle d'outillage fédérateur, il vaut mieux partir dans l'état d'esprit que les plateformes vont exister comme aujourd'hui

Oui, je suis tout à fait d'accord avec ça.

Dans votre exemple pour UWP, les deux boutons seront rendus, n'est-ce pas ?
Je veux dire, par exemple, lorsque xmlns=".../xaml/presentation" est un espace de noms de niveau supérieur et que UserControl wutg StackPanel est disponible à la fois dans uwp et wpf, le deuxième bouton ne serait-il pas également disponible sur les deux plates-formes ?

@Tirraon , l'exemple que j'ai donné concerne uniquement l'application WPF qui utilise les îles Xaml pour moderniser progressivement leur application. Il n'est pas destiné à un balisage "standard" utilisé entre les applications WPF et WinUI, cela a-t-il du sens ?

Actuellement, les auteurs d'applications souhaitant utiliser les îles Xaml doivent créer des contrôles utilisateur pour chaque île. Ils référencent ensuite le type via une chaîne dans leur balisage WPF, plutôt que d'incorporer naturellement des éléments WinUI dans le balisage WPF.

Je suis sur mon téléphone en ce moment, mais je peux avoir un avant et un après plus concret de ce que je propose une fois que je suis près de mon PC.

@stevenbrix
Oh, maintenant je t'ai, merci.

@stevenbrix
Oh, maintenant je t'ai, merci.

@Tirraon super ! Content que nous soyons sur la même longueur d'onde ☺️

Désolé si mon idée semblait sortir du champ gauche, nous avons discuté au début de la façon dont nous pourrions potentiellement unifier les outils, dans le but d'améliorer le scénario de l'île Xaml. Pensez-vous qu'il y a de la valeur dans quelque chose comme ça?

FWIW, je pense vraiment qu'il y a du mérite dans quelque chose comme ce que vous proposez. Mais j'essaie de me concentrer sur quelque chose que nous pouvons faire dans le laps de temps WinUI3/.NET5.

Découvrez comment rendre WinUI Xaml dans un pipeline qui traduit la sortie en un canevas natif et reçoit les entrées d'un système de messagerie natif. Comme WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

L'implémentation de tous les adaptateurs n'est pas nécessaire au lancement, uniquement ceux qui sont nécessaires pour prendre en charge Windows 10.

De : Steven Kirbach [email protected]
Envoyé : jeudi 7 novembre 2019 09:13:46
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja Sharp [email protected] ; Commentaire [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Expérience et outils des développeurs WinUI 3.0 - Input Needed (#1045)

@stevenbrix https://github.com/stevenbrix
Oh, maintenant je t'ai, merci.

@Tirraon https://github.com/Tirraon super ! Content que nous soyons sur la même longueur d'onde ☺️

Désolé si mon idée semblait sortir du champ gauche, nous avons discuté au début de la façon dont nous pourrions potentiellement unifier les outils, dans le but d'améliorer le scénario de l'île Xaml. Pensez-vous qu'il y a de la valeur dans quelque chose comme ça?

FWIW, je pense vraiment qu'il y a du mérite dans quelque chose comme ce que vous proposez. Mais j'essaie de me concentrer sur quelque chose que nous pouvons faire dans le laps de temps WinUI3/.NET5.

-
Vous recevez ceci parce que vous avez commenté.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 ou désabonnement https://github.com/ notifications/unsubscribe-auth/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

Oui s'il vous plaît, le scénario de l'île XAML est horrible en ce moment

@sharpninja
Vous devriez jeter un oeil à Uno
https://platform.uno/
Il va également prendre en charge WinUI 3.0 pour chaque plate-forme
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
Je n'ai pas vraiment d'expérience avec les îles Xaml et je travaille généralement avec du simple UWP. Mais il faut absolument que j'y regarde de plus près.
Ma proposition n'était pas liée aux îles Xaml elles-mêmes, mais plutôt à WinUI en général, car elle fonctionnera sur plusieurs plates-formes.

Ma proposition n'était pas liée aux îles Xaml elles-mêmes, mais plutôt à WinUI en général, car elle fonctionnera sur plusieurs plates-formes.

@Tirraon ,

J'ai brièvement parlé avec @jeromelaban et compagnie de ce que vous proposez exactement, et il y a certainement un intérêt. Il n'y a pas encore de plan ou d'engagements concrets, car nous n'en sommes qu'au tout début des discussions. Ce type de contribution est formidable et nous aide à mieux comprendre la valeur qu'il apporte à nos clients 😄

Par le scénario de l'îlot XAML, j'entends celui du C++. Voir mes messages précédents dans ce fil pour la liste des problèmes que j'ai rencontrés.

Oui s'il vous plaît, le scénario de l'île XAML est horrible en ce moment

Par le scénario de l'îlot XAML, j'entends celui du C++. Voir mes messages précédents dans ce fil pour la liste des problèmes que j'ai rencontrés.

@sylveon, je vois vos commentaires (liens ci-dessous), et oui, cela semble assez terrible. Désolé que vous subissiez cela, je suis convaincu que nous allons l'améliorer.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

Une grande partie de la douleur que vous traversez est liée au système de projet sonore, et je sais que c'est quelque chose qui est sur les radars de beaucoup de gens (bien que je sois assez détaché). Avez-vous vu cette vidéo que certains membres de notre équipe ont réalisée sur les outils XAML ? Ce lien devrait démarrer la vidéo YouTube au point où @michael- hawker et

Il y a beaucoup de choses qui contribueront à rendre l'expérience de l'île Xaml facile et naturelle à utiliser. L'aspect auquel je fais référence est qu'actuellement, la façon dont vous incluez un contenu d'île de UWP dans WPF est la suivante (à partir de la vidéo ci-dessus):

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

Je pense que nous pouvons faire mieux que cela et fournir quelque chose comme ceci :

  <Grid>
   <uwp:SamplePage />
  </Grid>

@stevenbrix

J'ai brièvement parlé avec @jeromelaban et compagnie de ce que vous proposez exactement, et il y a certainement un intérêt. Il n'y a pas encore de plan ou d'engagements concrets, car nous n'en sommes qu'au tout début des discussions. Ce type de contribution est excellent et nous aide à mieux comprendre la valeur qu'il apporte à nos clients

Il y a tellement, tellement d'intérêt ! (Cette conversation apparaît partout) Si WinUI post 3.0 passait à des implémentations multiplateformes, vous auriez beaucoup de support pour les développeurs. Il suffit de regarder la discussion sur #1461. À court terme, utiliser la technologie Uno Platform pour convertir XAML/C# en HTML/WASM afin que les applications UWP s'exécutent sur toutes les plates-formes serait incroyable. À plus long terme, je suis préoccupé par l'impact sur les performances de l'exécution dans Electron ou dans un navigateur et il y a de la place pour une architecture plus efficace.

En bout de ligne, je sais que tout le monde est occupé sur WinUI 3.0 en ce moment. Mais quand cela sera terminé, ce serait formidable si nous connections @jeromelaban , @marb2000 , @jevansaks et d'autres pour trouver le meilleur moyen de rendre UWP partout. Ce serait également une discussion communautaire très intéressante pour un futur appel.

WinUi est le seul chemin sain d'esprit qui permet à Neo et Duo de survivre

De : robloo [email protected]
Envoyé : jeudi 7 novembre 2019 12 h 00 min 07 s
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja Sharp [email protected] ; Mentionnez [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Expérience et outils des développeurs WinUI 3.0 - Input Needed (#1045)

@stevenbrix https://github.com/stevenbrix

J'ai brièvement parlé avec @jeromelaban https://github.com/jeromelaban et compagnie de ce que vous proposez exactement, et il y a certainement un intérêt. Il n'y a pas encore de plan ou d'engagements concrets, car nous n'en sommes qu'au tout début des discussions. Ce type de contribution est excellent et nous aide à mieux comprendre la valeur qu'il apporte à nos clients

Il y a tellement, tellement d'intérêt ! (Cette conversation apparaît partout) Si WinUI post 3.0 passait à des implémentations multiplateformes, vous auriez beaucoup de support pour les développeurs. Il suffit de regarder la discussion sur #1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . À court terme, utiliser la technologie Uno Platform pour convertir XAML/C# en HTML/WASM afin que les applications UWP s'exécutent sur toutes les plates-formes serait incroyable. À plus long terme, je suis préoccupé par l'impact sur les performances de l'exécution dans Electron ou dans un navigateur et il y a de la place pour une architecture plus efficace.

En bout de ligne, je sais que tout le monde est occupé sur WinUI 3.0 en ce moment. Mais quand cela sera terminé, ce serait formidable si nous connections @jeromelaban https://github.com/jeromelaban , @marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks et d'autres à trouver le meilleur moyen de rendre UWP partout. Ce serait également une discussion communautaire très intéressante pour un futur appel.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 ou désabonnement https://github.com/ notifications/unsubscribe-auth/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi est le seul chemin sain d'esprit qui permet à Neo et Duo de survivre

J'ai tendance à être d'accord, mais j'obtiens la même interface utilisateur à partir d'une application Windows, fonctionnant sur Android et le Surface Duo. Avec une intervention minimale du développeur - c'est le Saint Graal.

Si WinUI a une chance d'être une plate-forme de développement principale et de donner à Windows une chance de ne pas devenir un simple réceptacle des applications d'autres plates-formes à long terme. (Ce n'est pas toujours une mauvaise chose, quand il s'agit de grandes applications établies, mais pour LoB et les prochaines grandes applications...)

Je crée mon propre langage orienté application et je souhaite prendre en charge l'utilisation de WinUI avec XAML et mon langage pour le code-behind. Ce serait bien si l'outillage offrait à un langage la possibilité de générer du code pour le XAML. Ce qui serait encore mieux, ce serait si le générateur de code XAML construisait IL comme une classe partielle qui pourrait être complétée en utilisant n'importe quel langage. Cela signifierait que le générateur de code produirait un assembly IL compilable.

Je crée mon propre langage orienté application et je souhaite prendre en charge l'utilisation de WinUI avec XAML et mon langage pour le code-behind. Ce serait bien si l'outillage offrait à un langage la possibilité de générer du code pour le XAML. Ce qui serait encore mieux, ce serait si le générateur de code XAML construisait IL comme une classe partielle qui pourrait être complétée en utilisant n'importe quel langage. Cela signifierait que le générateur de code produirait un assembly IL compilable.

Il existe XAML Direct, mais il est actuellement pris en charge par C# et C++.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Ce n'est pas ce que je veux dire. Je veux dire que la sortie de l'outil de génération de code est IL, pas C# ou C++. De cette façon, mon compilateur peut transformer le XAML en IL, puis hériter de cette classe.

@sharpninja Ce serait également bénéfique s'il peut également générer du LLVM Bytecode au lieu du simple code C++.

De cette façon, nous pouvons le combiner avec MIDL et XLang pour générer une bibliothèque COM et des fichiers WinMD à utiliser dans tous les scénarios pris en charge par XLang.

Avec mon chapeau C++, ce que j'aimerais voir concernant les outils WinUI pour C++, serait que Microsoft rattrape enfin ce que C++ Builder fait depuis le milieu des années 90.

Fournir des outils RAD réels pour le développement basé sur C++.

C++/CLI a échoué à court, bien qu'avec les formulaires il y ait eu quelques solutions de contournement.

C++/CX semblait être le cas, mais cela nécessitait un peu plus d'efforts que ce dont C++ Builder est capable.

Maintenant, C++/WinRT est peut-être la norme C++17, mais l'expérience globale pour les développeurs de bureau ressemble à une rétrogradation, avec l'augmentation du passe-partout qu'il faut écrire manuellement, une attention supplémentaire à la façon dont les types COM dépassent la limite de l'ABI et le manque de concepteur Support.

J'utilise donc toujours C++/CX pour le moment, car je n'ai pas l'impression de gérer tout le passe-partout requis par le compilateur MIDL et le support COM ABI.

De l'autre côté, avec mon chapeau .NET, j'aimerais que les bibliothèques C++ uniquement comme DirectX soient enfin exposées en tant que composants WinUI, certains adorent Blend, et me souvenant que F# est également censé être un langage .NET de Microsoft.

J'ai eu beaucoup de mal à essayer de passer à WinUI. Il existe un certain nombre de bibliothèques propriétaires et tierces qui n'utilisent pas WinUI pour le moment et leurs dépendances deviennent problématiques. Par exemple, le SDK Comportements.

C'est une idée que j'ai eue en parlant de StatusBar dans le Discord de la communauté UWP ..

Dans Visual Studio, faites en sorte que la boîte à outils inclue des entrées pour les contrôles WPF qui manquent dans UWP et lorsque ces entrées sont sélectionnées, affichez une fenêtre contextuelle expliquant comment simuler le contrôle traditionnel.

Cette idée vient d'un désir de faciliter la transition pour les personnes venant de WPF (ou d'autres frameworks) où elles s'attendent à voir certains contrôles, et ne pas trouver ces contrôles peut trouver que c'est une expérience discordante. Comment sait-on que CommandBar peut être utilisé comme StatusBar ? Je pense que nous devons rendre aussi simple que possible pour les gens de passer à WinUI. Cela pourrait servir à combler certaines lacunes sans avoir à développer réellement tous les contrôles manquants.

ÉDITER:
Et pour être complet, voici autre chose que j'ai dit à propos de la barre d'état .. montrant simplement comment quelqu'un pourrait aborder UWP (ou WinUI) s'il ne le connaît pas ..

Re: StatusBar - Je pensais du point de vue des utilisateurs de frameworks traditionnels essayant UWP - et voyant qu'il n'a pas de StatusBar - toujours un aliment de base dans de nombreuses applications. Oui, CommandBar pourrait même être mieux. Mais les gens ne savent pas ce qu'est une CommandBar ou pourraient deviner que c'est autre chose. Quelqu'un au-dessus m'a même suggéré d'ajouter une grille, de la mettre en bas, d'en faire une rangée et d'ajouter divers contrôles pour afficher des éléments. Il semble donc que même les concepteurs Xaml existants ne connaissent pas CommandBar. Quoi qu'il en soit, peut-être que vous avez raison, peut-être que CommandBar est mieux, mais Paul Thurrot ne l'a pas utilisé dans son application de bloc-notes UWP, il a utilisé une grille. Il semble donc que la CommandBar ne soit pas communiquée en remplacement de la StatusBar. Les développeurs occasionnels (ou nouveaux) recherchent toujours la barre d'état et ne la trouvent pas. Je sais que Paul Thurrot n'est pas un développeur, mais vous comprenez ce que je veux dire.

Ce serait formidable si des extraits de code étaient également injectés dans le fichier xaml avec un cas d'utilisation normal.

De : Gavin-Williams [email protected]
Envoyé : mardi 18 février 2020 19:05:39
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja Sharp [email protected] ; Mentionnez [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Expérience et outils des développeurs WinUI 3.0 - Input Needed (#1045)

C'est une idée que j'ai eue en parlant de StatusBar dans le Discord de la communauté UWP ..

Dans Visual Studio, faites en sorte que la boîte à outils inclue des entrées pour les contrôles WPF qui manquent dans UWP et lorsque ces entrées sont sélectionnées, affichez une fenêtre contextuelle expliquant comment simuler le contrôle traditionnel.

Cette idée vient d'un désir de faciliter la transition pour les personnes venant de WPF (ou d'autres frameworks) où elles s'attendent à voir certains contrôles, et ne pas trouver ces contrôles peut trouver que c'est une expérience discordante. Comment sait-on que CommandBar peut être utilisé comme StatusBar ? Je pense que nous devons rendre aussi simple que possible pour les gens de passer à WinUI. Cela pourrait servir à combler certaines lacunes sans avoir à développer réellement tous les contrôles manquants.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 ou désabonnement https://github.com/ notifications/unsubscribe-auth/AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

L'histoire du développeur devrait inclure une sorte de liste de comparaison.

Concepts intrinsèques aux applications Win32, donc barres d'état, barres d'outils, menus, pinces, onglets, etc. dans une liste et les équivalents WinUI sur l'autre.

La page elle-même comprenant des exemples de code des deux, pour montrer comment l'interface utilisateur d'une application existante pourrait être déplacée vers WinUI.

Questions ouvertes)
Serait-il avantageux de fournir un outil de migration qui automatise les étapes 1 à 3 ?

Oui. Je prends en charge 1 application Windows Forms "héritée" (l'héritage signifie aucun budget à réécrire) et 2 ou 3 applications WPF héritées. L'application WinForms est peut-être bloquée, mais un outil pour aider à porter rapidement les applications WPF vers WinUI 3 serait génial !

MSIX est la méthode de packaging moderne pour toutes les applications. Pour WinUI dans Win32 devrions-nous prendre en charge ClickOnce ? Pour quelles autres méthodes d'emballage devrions-nous inclure un support ? Surtout pour WinUI dans Win32

Nous utilisons actuellement ClickOnce pour publier des applications sur les bureaux de nos utilisateurs. Certains modèles de mises à jour automatisées seraient toujours souhaités.

@JeffSchwandt

Ces étapes concernaient la conversion de projets WinUI utilisant des versions antérieures (1-2) vers la version 3.

La conversion d'une application WPF en une application WinUI n'est pas particulièrement réalisable de manière automatisée (sans un effort énorme, mais même dans ce cas, ce serait extrêmement sujet aux erreurs).

J'espère que c'est le bon fil pour poster cette demande.

Rust a désespérément besoin d'un cadre d'interface utilisateur approprié en ce moment. Ce serait bien si WinUI pouvait prendre en charge Rust à l'avenir avec un SDK natif et quelques outils.

J'espère que c'est le bon fil pour poster cette demande.

Rust a désespérément besoin d'un cadre d'interface utilisateur approprié en ce moment. Ce serait bien si WinUI pouvait prendre en charge Rust à l'avenir avec un SDK natif et quelques outils.

Bonne nouvelle, Rust/WinRT est en cours de développement, ce qui permettra aux applications Rust d'utiliser les API WinRT comme WinUI ! Jetez un œil à https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks Hé, merci pour la réponse ! Oui, je sais que Kenny fonctionne sur Rust/WinRT, mais je me demande si WinRT est la seule couche API que WinUI prendra en charge ? Je ne sais pas comment cela correspondrait au fait que l'utilisation de l'API WinRT à partir des applications de bureau est devenue disponible uniquement dans Windows 10 1903, tandis que WinUI vise à prendre en charge les anciennes versions de Windows 10.

Rust/WinRT (comme C++/WinRT) devrait fonctionner jusqu'à Windows 7. WinRT lui-même a toujours fonctionné sur les applications de bureau/win32. Seules certaines API avaient des exigences de stockage/uwp/packaging (pas WinRT dans son ensemble). Tant que WinUI n'a pas ces exigences, vous pourrez utiliser WinUI à partir d'applications de bureau via C++/WinRT et Rust/WinRT sur n'importe quelle plate-forme prise en charge.

Les applications de bureau WinUI doivent prendre en charge les vignettes dynamiques et la mise à jour des vignettes - avec de bons exemples simples et des outils SDK pour créer des vignettes plus facilement que les applications UWP aujourd'hui.

Je ne sais pas comment cela correspondrait au fait que l'utilisation de l'API WinRT à partir des applications de bureau est devenue disponible uniquement dans Windows 10 1903

WinUI Desktop est actuellement conçu pour WinUI 3.0, et cela devrait permettre aux applications Win32 simples d'utiliser le niveau inférieur de WinUI (le plan actuel est réduit à 1803).

L'interface utilisateur Windows doit prendre en charge au moins les principaux frameworks MVVM - MVVM Light, Prism et Caliburn. Malheureusement, votre problème documenté avec les modifications apportées à INotifyPropertyChanged et INotifyCollectionChanged cassant ObservableCollectioncasse certainement MVVM Light, et probablement les deux autres frameworks aussi. Je pensais que tu devrais savoir.

Malheureusement, votre problème documenté avec les modifications apportées à INotifyPropertyChanged et INotifyCollectionChanged interrompant ObservableCollection casse certainement MVVM Light, et probablement les deux autres frameworks également. Je pensais que tu devrais savoir.

Merci @terrycox ! Nous en sommes conscients et cela sera traité par WinUI 3.0 RTM, et idéalement dans une version préliminaire avant cela ;)

@terrycox L'interface utilisateur Windows doit prendre en charge au moins les principaux frameworks MVVM - MVVM Light, Prism et Caliburn. ... votre problème documenté

Oui, cela devrait résoudre les problèmes documentés, mais il n'est pas nécessaire d'avoir une bibliothèque .Net UI, y compris WinUI, pour prendre en charge un framework MVVM. Il doit uniquement prendre en charge les objets qui représentent des éléments d'interface utilisateur. Un .Net MVVM ou un framework réactif est un moyen de générer et de modifier des objets .Net représentant une interface utilisateur basée sur des objets représentant des données. Ni l'un ni l'autre n'a besoin de connaître l'autre. N'importe quel framework peut être combiné avec n'importe quelle bibliothèque d'interface utilisateur.

mais il n'y a pas besoin d'une bibliothèque .Net UI, y compris WinUI, pour prendre en charge un framework MVVM.

Mais des choses comme les événements et les interfaces dont les UIElements sont conscients sont nécessaires et c'est ce qui a été cassé.

De : Charles Roddie [email protected]
Envoyé : mercredi 25 mars 2020 14:28:46
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja Sharp [email protected] ; Mentionnez [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Expérience et outils des développeurs WinUI 3.0 - Input Needed (#1045)

@terrycox https://github.com/terrycox L'interface utilisateur Windows doit prendre en charge au moins les principaux frameworks MVVM - MVVM Light, Prism et Caliburn. ... votre problème documenté

Oui, cela devrait résoudre les problèmes documentés, mais il n'est pas nécessaire d'avoir une bibliothèque .Net UI, y compris WinUI, pour prendre en charge un framework MVVM. Il doit uniquement prendre en charge les objets qui représentent des éléments d'interface utilisateur. Un .Net MVVM ou un framework réactif est un moyen de générer et de modifier des objets .Net représentant une interface utilisateur basée sur des objets représentant des données. Ni l'un ni l'autre n'a besoin de connaître l'autre. N'importe quel framework peut être combiné avec n'importe quelle bibliothèque d'interface utilisateur.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 , ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

L'outillage Dotnet cli doit être utilisé avec a. SDK de base net.
Des commandes telles que dotnet new et dotnet build devraient suffire, aucune dépendance dure de l'installation de Visual Studio. S'il vous plaît, rejoignez pleinement l'ère .Net Core !

• Ce sera bien si le concepteur xaml est rapide. Le concepteur XAML actuel est lent et renvoie toujours une erreur indiquant qu'une exception s'est produite et que cela ne fonctionnera pas. Veuillez corriger cela et fournir un concepteur robuste.

• actuellement uwp n'a pas d'API capable de détecter l'écran de verrouillage. Ce serait bien si nous disposions d'API capables de détecter l'écran de verrouillage et de donner des valeurs booléennes comme valeurs de retour. Nous devrions également pouvoir afficher des animations et des badges après verrouillage ou déverrouillage.
  - API d'écran de verrouillage existante

• Mon problème expliqué

Dans le sens du commentaire de

J'aimerais voir un modèle d'application qui crée une application .NET 5 avec l'interface utilisateur WinUI 3.0 qui fait référence à une application hôte de magasin .NET 5. Cela permettrait de réduire le nombre d'installations redondantes de .NET 5.0

Dans une application de bureau WinUI, comment passer de muxc.Window.ThisPtr à un hWnd à la fenêtre Win32 native ?

Je viens d'essayer les nouveaux modèles de mai 2020 pour WinUI 3 Preview 1 for Desktop car j'aime cette idée.

Mais j'ai une question. Avec WinUI comme plate-forme d'interface utilisateur native sur Windows, je suis surpris du manque de communication pour qu'il fasse également partie de Windows 10 ?

Mon application Hello World résultante faisait environ 120 Mo. Bien sûr, l'espace est bon marché, mais je n'avais pas de dépendances ici. De cela, WinUI a consommé une quantité considérable d'espace, à peu près autant que le .NET 5 inclus lui-même. C'est uniquement pour la version x64. Incluez x86 dans un package multiplateforme et doublez cette taille. Ajoutez quelques autres dépendances et nous pourrions facilement envisager une application de 300 Mo à emballer pour la distribution.

Pourquoi WinUI 3 ne fait-il pas simplement partie de l'édition Windows de .NET 5 ? Cela fait-il partie de l'effort de modularisation de .NET Core ? Mais sinon, où est la place pour cela ? Vraiment dans le dossier de chaque application ? En tant qu'interface utilisateur officielle de Windows 10...?

Ou fera-t-il partie de Windows 10 à l'avenir ? Si WinUI était davantage traité comme une bibliothèque système et que .NET 5 commencerait à être livré avec Windows plus tard, nous examinerions plutôt des applications relativement petites. Mais j'espère que c'est exactement l'histoire de Windows 10X au moins, et peut-être aussi de Windows 10 non-X plus tard ? En excluant ces deux bibliothèques ainsi que la DLL du pont Windows 10 SDK C#/WinRT, la taille de l'application chute à 1 à 5 Mo.

@ryandemopoulos a déclaré sur Discord que WinUI serait livré sous forme de package de cadre, de sorte que les applications utilisant le Store ou MSIX pour la distribution n'auront pas à porter leur propre version de WinUI, car elles partageront toutes la même copie.

Faire de WinUI une partie de Windows lui-même irait à l'encontre du découplage de WinUI du système d'exploitation.

« Disponible de manière fiable et pas dans la taille de l'application » est la préoccupation. J'espère que .NET 5 est distribué de la même manière.

@lmcdougald Je vous invite à ouvrir un problème sur .NET Core Installer et à demander à .NET 5 d'utiliser également Framework Packaging pour la maintenance.

@jonasnordlund il y a une autre discussion #2500 où nous parlons du déploiement de WinRT Runtime. Peut-être y trouverez-vous une réponse. :)

@ marb2000 J'ai ouvert un problème, mais je suis honnêtement déconcerté. N'est-ce pas considéré comme essentiel pour toute application qui fournirait Windows 10X ?

Voici une compilation de plusieurs fonctionnalités, dont certaines ne sont pas directement WinUI, mais leur absence a un impact direct sur l'expérience de tout développement de client .NET - clients UWP inclus, et en particulier les clients d'application LoB.

• La priorité absolue pour moi est que vous alimentiez la plate-forme Uno. Pour moi, c'est ce qui rend UWP pertinent, j'aurais fait un compromis sur XF ou une autre technologie si Uno n'était pas là. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• API abstraite de gestion des identités côté client à utiliser à partir de ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• Prise en charge complète des annotations de données, des validations et des titres de l'interface utilisateur, des longueurs de chaîne, des attributs requis, des champs en lecture seule, des filigranes, etc. etc. etc. (https://bit.ly/3gcMJ3a)
• Améliorez OData pour qu'il devienne une alternative appropriée à ce qu'étaient les services RIA. Par exemple : prise en charge de la génération d'attributs, des implémentations d'interface, des types génériques, des documents XML (https://github.com/OData/odata.net/issues/1746)
• Apportez toutes les fonctionnalités manquantes de WPF
• x:Bind devrait également avoir toutes les fonctionnalités de Binding , telles que les étendues ou les liaisons imbriquées (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• Redémarrage à chaud (https://github.com/microsoft/ProjectReunion/issues/44)
• Plus que de simples modèles Hello World. Comme ceux qui prennent en charge la connexion utilisateur, MVVM, le routage, les projets x-plat (tels que Uno-Platform), etc. En d'autres termes, veuillez donner plus de pouvoir à WTS.
• Fonctionnalités de mise en page de l'éditeur XAML WYSIWYG comme dans WinForms, telles que l'amarrage, l'espacement, etc. - cela semble être terminé ! ??

Merci pour votre compilation @weitzhandler , très pratique.

L'équipe WinUI entretient d'excellentes relations avec l'équipe produit Uno (non Microsoft), l'équipe Xamarin Forms/MAUI et React Native. Nous collaborons activement avec eux et nous leur souhaitons un avenir plein de succès.

À propos des fonctionnalités WPF manquantes, pouvez-vous lister vos principales, s'il vous plaît ? Combler l'écart entre WPF et WinUI est l'un de nos objectifs. Il faudra cependant plusieurs versions.

A propos de modèles plus complexes. Le Window Template Studio a cette mission.

J'ai fait un problème pour essayer de rassembler les domaines où WinUI manque par rapport à WPF # 719 @weitzhandler @ marb2000

A propos de modèles plus complexes. Le Window Template Studio a cette mission.

@marb2000 pourrions-nous intégrer Window Template Studio dans notre VSIX ? Ou peut-être vice-versa ? Utilisez simplement Window Template Studio comme véhicule pour expédier tous les modèles WinUI3 (et Project Reunion) à l'avenir ?

A propos de modèles plus complexes. Le Window Template Studio a cette mission.

@marb2000 pourrions-nous intégrer Window Template Studio dans notre VSIX ? Ou peut-être vice-versa ? Utilisez simplement Window Template Studio comme véhicule pour expédier tous les modèles WinUI3 (et Project Reunion) à l'avenir ?

👀 @crutkas @sibille

Je suggère de passer du temps avec C++ Builder (VCL/FMX) et Qt Creator/Design studio, pour apprendre ce qui est possible avec C++ et les outils modernes.

Idéalement, WinUI offrirait des outils similaires à ceux que ces produits proposent déjà aujourd'hui pour les interfaces graphiques multiplateformes écrites en C++.

Ce qui m'importe, c'est l'expérience de développement .NET et le fait d'avoir une expérience similaire pour les cas d'utilisation que je suis obligé d'utiliser C++, qui pour une raison quelconque ne sont pas mis à notre disposition.

C++ Builder et QtCreator réalisent une telle expérience, et il serait bien que les développeurs .NET se sentent chez eux lorsqu'ils doivent passer quelques jours à écrire du code C++/WinRT.

Pourquoi parler des développeurs .NET ? L'expérience C++ XAML est tout simplement mauvaise, peu importe que vous soyez un développeur C++ ou .NET.

Je pense que ce sera formidable s'ils ouvrent la voie pour permettre l'exécution du même XAML sur le bureau, le Web (Edge), le mobile et l'IoT.

Quand pourrons-nous utiliser WinUI 3 dans un projet c++ sans C#, Xaml ou concepteur ?
y a-t-il également des nouvelles sur la date de l'open sourcing du noyau c++ de WinUI 3 ?

Edit: Je suppose que j'ai eu une réponse à ma première question, il semble qu'il y ait un modèle de projet c++ WinUI 3 dans WinUI 3.0 Preview 1 :

Après avoir installé l'extension .vsix, vous pouvez créer un nouveau projet WinUI 3.0 en recherchant "WinUI" et en sélectionnant l'un des modèles C# ou C++ disponibles.

Le cas d'utilisation sur lequel j'aimerais que WinUI s'améliore est celui de la création de petits outils basés sur une interface graphique pour le personnel de support informatique de première ligne, qui sont souvent écrits en PowerShell. Ce serait formidable de pouvoir créer ce genre d'outils dans Visual Studio Code. Même une option de développement VSCode basée sur C# serait un grand pas. Visual Studio complet semble plutôt lourd et complexe pour ce cas.

Actuellement, les environnements d'entreprise utilisent plutôt des outils comme ceux-ci :

• https://poshgui.com/ (assistant Web XAML)
• Sapien PowerShell Studio 2020 (propriétaire)
• Admin Script Editor (ASE) (un projet maintenant abandonné)

D'autres modèles couramment utilisés « utiliser Visual Studio pour le XAML » sont décrits ici :

• Créer une interface graphique simple pour un script PowerShell
• Comment créer une interface graphique PowerShell pour vos scripts

Ma question s'inscrit dans le contexte de la question @mqudsi qu'il a posée en mai, mais personne n'a répondu.

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

Comme il s'agit d'une application de bureau, nous ne pouvons pas utiliser ICoreWindowInterop et j'ai essayé des swags aléatoires tels que new HandleRef(this, ThisPtr) où 'ceci' est de type Microsoft.UI.Xaml.Window mais continue de voir l'errno pour Invalid Window Handle. Une fois que j'ai enfin obtenu ce hwnd, je peux essayer d'utiliser plus de COM pour changer le style de la fenêtre et partager avec les autres afin qu'ils ne ressentent pas la douleur que je ressens en ce moment :).

Pour toute personne intéressée, c'est l'approche rapide que j'ai utilisée pour récupérer le hWnd pour la fenêtre principale afin que je puisse la rendre sans bordure. La solution complète pour l'équivalent WPF de WindowStyle = None est ici .

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

À l'heure actuelle, il ne semble pas y avoir de moyen facile à trouver / documenté pour obtenir le hWnd lorsque votre WinUI est dans un processus de bureau, c'est pourquoi je me suis tourné vers l'approche que j'ai utilisée. Semble fonctionner assez bien.

Je pense que les termes UWP et Universal Windows devraient peut-être disparaître. Les termes portent un bagage malheureux qui conduit les développeurs à se détourner.

Peut-être pourrions-nous remplacer le modèle WinUI (Universal Windows) par WinUI (Win64) ? Vous avez alors l'option Desktop ou Store ?

Win64 est déroutant - cela impliquerait que l'API Win32 ne prend en charge que 32 bits, et qu'inversement UWP ne prend en charge que 64 bits, les deux étant faux.

Le nom Win32 à lui seul confond déjà une tonne de débutants, nous n'avons pas besoin de Win64 pour aggraver les choses.

@VagueGit quelque chose que j'ai appris, c'est que choisir le bon nom et créer l'histoire est l'une des choses les plus compliquées. Mieux que de remplacer un nom, nous (Microsoft) devrions fournir le bon produit (et l'histoire) pour vous aider à réussir. UWP est une terminologie bien connue sous le nom de Win32, nous devons donc continuer à les utiliser.

Voici notre approche (très simplifiée) :

WinUI peut être utilisé dans deux "types" d'applications qui ciblent différents appareils :

• Votre application cible de nombreux appareils avec de nombreuses entrées et facteurs de forme. Ensuite, utilisez UWP. UWP a été créé pour cela ; par conséquent, vous devez répondre à des exigences telles que le modèle d'emballage, le magasin, le modèle d'application, le conteneur de sécurité, etc.
• Votre application cible uniquement Desktop et nécessite un accès complet au système d'exploitation. Utilisez Win32 ou Desktop (c'est ainsi que Visual Studio appelle WPF, WinForms, MFC, apps).

WinUI dans les applications UWP et WinUI dans les applications de bureau (ou l'

@marb2000 Nommer les choses est difficile, d'accord. Mais certains noms sont malheureusement toxiques et devraient être laissés pour compte. C'est pourquoi de temps en temps les produits sont rebaptisés. UWP en est un, mais ce n'est que mon point de vue ... et tous ceux à qui je parle. Mais voilà.

Nous avons une application UWP que nous souhaitons migrer vers WinUI. Nous n'utilisons pas l'API Win32, nous ciblons uniquement le bureau et nous ne voulons pas utiliser le magasin. Comment cela convient-il?

@marb2000 Nommer les choses est difficile, d'accord. Mais certains noms sont malheureusement toxiques et devraient être laissés pour compte. C'est pourquoi de temps en temps les produits sont rebaptisés. UWP en est un, mais ce n'est que mon point de vue ... et tous ceux à qui je parle. Mais voilà.

Nous avons une application UWP que nous souhaitons migrer vers WinUI. Nous n'utilisons pas l'API Win32, nous ciblons uniquement le bureau et nous ne voulons pas utiliser le magasin. Comment cela convient-il?

A qui s'adresse l'appli exactement ?

En tant que consommateur qui fait tout son possible pour utiliser les applications UWP, si l'application n'est pas dans le magasin, je ne vais probablement pas la toucher, et encore moins la voir.

Ne vous inquiétez pas @shaheedmalik, nous ne vous demanderons pas d'y toucher :-). Nous écrivons des applications professionnelles. Win32 et UWP. Nous avons une application UWP qui est dans le magasin depuis quelques années mais n'est pas visible dans le magasin. Nous avons une clientèle d'affaires établie depuis 30 ans. Ils sont satisfaits de notre application UWP mais mécontents de l'expérience en magasin, nous la sortons donc du magasin.

Nous savons donc qu'il existe un marché pour les applications professionnelles Win64 et nous pensons que nous sommes parmi les rares développeurs commerciaux à avoir fourni des applications Win64 pour lesquelles les clients professionnels paieront. Je sais qu'il y a quelques développeurs sur ce fil qui empruntent la voie universelle Windows/multi-plateforme, mais ils sont assez rares. D'après mon expérience, la plupart des développeurs commerciaux ciblent un facteur de forme spécifique.

Donc, du point de vue d'une société de développement qui a beaucoup investi dans UWP et a fait un succès commercial d'UWP, peut-être des modèles pour WinUI (Desktop) et WinUI (Store) ? Il vous suffit de suivre les médias techniques pour avoir une idée de la mauvaise qualité de UWP en tant que plate-forme de développement.

@VagueGit
« Nous avons une application UWP que nous voulons migrer vers WinUI. Nous n'utilisons pas l'API Win32, nous ciblons uniquement le bureau et nous ne voulons pas utiliser le magasin. Comment cela convient-il ? »

Vous souhaitez donc migrer un UWP vers WinUI 3 et le déployer en dehors du Store ? Une question naïve : avez-vous essayé le sideload de MSIX ? Une raison autre que le magasin qui vous empêche d'utiliser UWP ?

@VagueGit
"Nous savons donc qu'il existe un marché pour les applications professionnelles Win64."

Une question, Win64 représente beaucoup de choses. par exemple, les applications se compilent pour x64. Que signifie Win64 pour vous ?

@marb2000 UWP prend mal en charge les rapports commerciaux. Nous pensons que le changement de marque pourrait aider à lancer le développement d'outils tiers tels que les rédacteurs de rapports. Nous avons eu un jeu avec le chargement latéral, mais ce n'était pas possible pour nous avant 20H1, car le chargement latéral n'était pas activé par défaut.

Nous pensons que Win64 est la voie à suivre sur Windows. Micro$ a dans le passé tenté de présenter Win32 comme héritage sans succès et revient maintenant sur cette position. Mais finalement Win32 doit disparaître, à notre avis (je dis cela après 30 ans de développement Win32 moi-même). Nous avons réussi à surmonter la plupart des limitations d'UWP pour fournir une application commerciale que les entreprises achèteront. Nous craignons qu'une autre itération d'UWP ait une traction limitée sans changement de marque.

Comme le montre la confusion de @ marb2000 , le terme Win64 est déjà (mal) utilisé. Je l'ai également signalé plus tôt.

Je suis d'accord qu'un changement de marque pourrait être nécessaire, mais Win64 est un moyen terrible de le faire. Jusqu'à ce qu'il y ait quelque chose d'officiel, vous devez utiliser le terme UWP pour être compris par tout le monde.

@sylveon UWP est considéré par tout le monde comme un échec. Nous l'aimons mais peu d'autres le font. C'est pourquoi le rebranding est important. Que pensez-vous de WinUI (Deskop) ou de WinUI (Store) comme modèles de projet ?

WinUI (Store) n'est pas bon car vous pouvez également expédier des applications Win32 dans le magasin ou expédier des applications UWP en dehors du magasin. WinUI (Desktop) est bon cependant.

@sylveon WinUI (Store) n'exclut pas d'autres projets qui ciblent le magasin. Cela signifie simplement que vous voulez commencer avec l'ensemble des capacités qui permettent la publication via le magasin.

C'est déjà assez pour embrouiller les débutants.

Ceci n'est pas destiné à s'adresser à une personne en particulier dans ce fil, mais plutôt à ma propre opinion en tant que développeur d'applications de bureau/propriétaire d'entreprise.

Je ne suis jamais pris dans ce que quelque chose est nommé. Je ne me soucie que de ses fonctionnalités et de sa prise en charge.

Je dirais qu'il y a aussi beaucoup de développeurs (moi inclus) qui sont excités quand nous utilisons des termes comme MAUI, mais sont immédiatement déçus quand nous réalisons que c'est toujours la même base de code. Le changement de marque suggère « hé, regardez, nous construisons cette toute nouvelle chose qui commence à partir d'une base de code entièrement différente de celle qui vous a bloqué de xyz ». Ce que j'adore voir, c'est une énorme liste de fonctionnalités qui ont changé les difficultés que j'ai eues ou que quelqu'un d'autre a eues.

Les plateformes se développent au fil du temps comme n'importe quel produit ou marque. Je trouve du réconfort dans les marques et les noms qui existent depuis des décennies car cela implique automatiquement LTS. Bien que je réalise que les changements de nom sont parfois une nécessité, ils rappellent également aux développeurs l'abandon (Silverlight). Il existe de nombreux modèles automobiles qui ont connu des années de problèmes, mais qui ont fini par devenir des marques appréciées et respectées. Il y a beaucoup à dire avec familiarité, même si vous n'aimez pas les expériences précédentes, car vous savez à quoi vous attendre. Tant que les problèmes sont résolus, c'est vraiment ce qui compte.

Je pense qu'il y a au moins deux publics qui doivent être pris en compte ; développeurs et utilisateurs de produits finaux. En tant que développeur/propriétaire d'entreprise, si j'ai un client qui a besoin d'une application, et qu'il a été aigri par des noms de technologies sous-jacentes, c'est mon travail de lui inculquer la confiance que le produit représenté par le nom a mûri et ce qui les concernait dans le passé a été mis à jour. D'un autre côté, si je dis "regardez, il y a cette nouvelle grande chose appelée WinUI ou MAUI" et qu'ils possèdent déjà des produits WPF ou UWP ou Xamarin que nous avons développés pour eux, une réponse prévisible de leur part est "oh super, maintenant nos applications sont écrits dans 2, 3 ou 4 technologies différentes ». C'est là que je dois ensuite les vendre. Étant donné que tous les clients sont différents, je vais rencontrer des réticences, que vous laissiez le nom tel quel ou que vous le changiez.

Ce qui est important en fin de compte (pour moi), c'est que nous ayons les outils dont nous avons besoin pour écrire des applications attrayantes et riches en fonctionnalités qui ont LTS. Je suis excité quand je vois un produit arriver à échéance et je peux lire la nouvelle fonctionnalité et la liste de résolution des problèmes lorsque le produit est publié. J'adore NetCore/Net5 (changement de nom LOL) depuis 2016. (Au fait, essayer de dire à mes clients que .Net5 est ce que nous prévoyons de cibler un an après les avoir convaincus de passer à NetCore n'est pas facile non plus !)

Pour le moment, je veux juste avancer rapidement jusqu'à ce que je puisse écrire une application de bureau avec le dialecte XAML et obtenir les mêmes performances de rendu qu'UWP/WinUI (sans le bac à sable UWP). Pour cette raison et en raison de la sortie de l'aperçu de septembre, je vais commencer à tester l'Avalonia. J'adore les similitudes WPF en entendant parler des performances de rendu via SkiaSharp.

Ce sera passionnant dans quelques années lorsque les options de développement de l'interface utilisateur se seront stabilisées. Ils peuvent nommer les modèles de projet comme ils le souhaitent, cela ne changera pas mon opinion sur le manque de fonctionnalités.

Je vous apprécie tous.

Je reçois ce que jtbrower dit dans son e-mail. Son entreprise comme la nôtre est l'une des rares à avoir emprunté avec succès le chemin du xaml. Nous n'avons pas besoin d'être convaincus des avantages.

Mais aussi bon que cela puisse être, xaml était un désastre pour Micro$. Les développeurs sont restés majoritairement avec WinForms ou sont entièrement passés au développement Web. Depuis UWP, l'exode des développeurs s'est aggravé.

Pour que les technologies xaml soient durables, Micro$ doit gagner ces millions de développeurs qu'ils n'ont pas réussi à intégrer. Pour ces développeurs, pour les fournisseurs d'outils et pour les médias technologiques, UWP est une impasse. Une autre itération d'UWP ne les gagnera pas.

@VagueGit mais les développeurs sont assez désireux de connaître un produit renommé comme le même. Ils connaissent MAUI sous le nom de Xamarin Forms. En fait, ils semblent aller jusqu'à dire que MAUI était un nom volé. Je ne pense pas que vous puissiez motiver un développeur typique avec un changement de nom. Nous voulons tous des fonctionnalités, n'est-ce pas ? Ne préféreriez-vous pas que UWP autorise plusieurs fenêtres ou autorise une confiance totale ? S'ils faisaient les deux, nous pourrions tous cibler UWP et peut-être conserver le bac à sable pour les applications de magasin. Je rêve juste à haute voix de ce qui me rendrait vraiment excité ! Caractéristiques!!

Tout à fait d'accord avec toi jtbrower. J'apprécie également que vous m'aidiez et j'espère que d'autres critiqueront leurs idées. Mais comment signaler aux développeurs et aux fournisseurs d'outils qu'il existe deux UWP différents, Store et Desktop ?

Donc, par tous les moyens, ceux qui veulent continuer sur le chemin UWP peuvent commencer avec le modèle UWP Store, mais ceux qui veulent un bureau 64 bits, pas un bac à sable et une confiance totale ... eh bien, ce n'est pas UWP, n'est-ce pas?

UWP est considéré sur le marché comme paralysé. Tous, sauf nous, les purs et durs, ont abandonné UWP lorsque Micro$ lui-même s'est retiré de la création de ses propres applications dans UWP.

Le marché des développeurs ne surveille pas les développements d'UWP. Le bureau 64 bits, sans bac à sable et avec une confiance totale, est bien plus qu'un changement de nom ; c'est un paradigme différent. Mais s'il s'appelle toujours UWP, il passera inaperçu pour ceux qui ont radié UWP.

@VagueGit Je suis heureux que vous ayez rencontré le succès avec UWP. Le nommage est difficile, et le fait que nous l'appelions la "plate-forme Windows universelle" et que ce ne soit pas vraiment tenable par la grande majorité des développeurs Windows le rend, eh bien, pas très "universel". Un résumé précis de Project Reunion consiste à résoudre ce problème et à rendre chaque aspect d'UWP vraiment accessible à tous les développeurs Windows.

Je suis d'accord que UWP a une mauvaise réputation, si vous tapez la phrase "UWP is" dans un moteur de recherche, la première suggestion automatique que Bing ou Google vous donnera est "UWP is dead". Cependant, je pense que @marb2000 a raison de continuer à utiliser le nom, malgré les bagages qu'il transporte.

Ceci étant dit...

Aujourd'hui, de nombreux aspects des projets Desktop pourront utiliser différentes parties de ce que nous avions l'habitude de définir comme "UWP":

1. La pile d'interface utilisateur (alias WinUI3)
2. Emballage MSIX
3. Ressources MRT

Une fois que CoreApplication est levé, la seule différence entre UWP et Desktop sera vraiment le modèle de bac à sable que vous choisissez pour votre application et les appareils que vous pouvez cibler.

Nous avons discuté de la possibilité de modifier les modèles de projet et d'avoir une expérience semblable à celle d'un assistant qui décrit cela avec plus de précision.

@JeanRoca est le PM qui dirige cela et peut avoir plus d'informations qu'il peut partager

J'aime l'idée du modèle WinUI Desktop. Plus approprié que Win32 et tourné vers l'avenir. C'est le modèle avec lequel nous commencerions alors que Win32 suggérait une contrainte 32 bits. Nous espérons que WinUI Desktop obtiendra une certaine influence dans les médias et parmi les développeurs.

Lorsqu'une application UWP est publiée en dehors du magasin, le package est .appinstaller. Si nous mettons à niveau cette application vers Win UI Desktop, le package d'installation passe d'appinstaller à msix.

En supposant que nous gardions les mêmes détails dans le package de l'application et que nous utilisions la version de manière appropriée, Windows reconnaîtra-t-il qu'il s'agit d'une nouvelle version de la même application et conservera-t-il les données locales, ou l'installera-t-il en tant qu'application différente ?

D'après ma compréhension, WinUI 3.0 ne sera jamais consommé à partir de .NET Framework <= 4.8. Donc, si nous parlons de WinUI, nous parlons soit de .NET Native, soit de .NET 3.1/5+ (ou d'un autre ensemble de liaisons).

Avez-vous des suggestions sur la façon d'avancer / de poser des questions sur l'empaquetage du framework pour .NET 5 (ou je suppose 6 à ce stade) ? J'ai ouvert un problème et je n'ai eu aucune réponse. L'intégration de .NET 5 dans l'application est un échec.

@stevenbrix

Une fois que CoreApplication est levé, la seule différence entre UWP et Desktop sera vraiment le modèle de bac à sable que vous choisissez pour votre application et les appareils que vous pouvez cibler.

Malheureusement, une autre grande différence est que les développeurs .NET sont obligés de passer au C++ pour des API comme DirectX, dont l'équipe refuse clairement de les rendre compatibles UWP malgré le fait qu'elles soient basées sur COM.

Et dans le processus, revenez aux jours de productivité de l'écriture manuelle de MIDL avec une belle expérience de type bloc-notes et de la copie de fichiers, apparemment l'équipe Windows ne peut pas laisser tomber l'expérience de développement ATL, au lieu de fournir une expérience de type NET pour les flux de travail C++. C++/CX devenait trop proche de C++ Builder, il a donc dû être tué au nom de trucs ISO, qu'avec de la chance, nous pourrions les obtenir en C++23 et en 2025 en VS.

Je doute que quiconque se soucie d'UWP d'ici là, à moins qu'une expérience de développement appropriée ne soit mise en place pour éliminer tous ces actes répréhensibles.

Nous lancer également des problèmes GitHub concernant l'équipe à laquelle donner des commentaires est un moyen très rapide de perdre tout intérêt. Apparemment, je m'en soucie trop.

Les API DirectX ne peuvent pas être modifiées pour la compatibilité WinRT car cela constituerait une rupture d'API significative pour les consommateurs existants, et cela ne peut tout simplement pas se produire.

Il existe plusieurs wrappers gérés disponibles pour DirectX, comme TerraFX qui est une liaison 1:1 brute ou Vortice qui est un wrapper d'API plus de style C#.

Quant à CX, il a dû disparaître. Les extensions de langage spécifiques au compilateur sont mauvaises et mal vues. Il entrave considérablement la portabilité du code, est souvent à la traîne en termes de prise en charge du standard C++ et nécessite une intégration verticale complète à partir des bibliothèques existantes. L'alternative, WRL, était très difficile à utiliser et trop verbeuse. Il n'est donc pas surprenant que beaucoup de gens (y compris la division DX) n'aient pas voulu écrire d'API WinRT.

C++/WinRT est une bien meilleure solution, c'est dommage qu'il ait dû ramener IDL (mais un mal nécessaire actuellement). L'équipe C++ a fait un bien meilleur travail de support des standards qu'auparavant, il ne serait donc pas surprenant que nous obtenions des métaclasses avant la finalisation de C++23, ce qui devrait améliorer radicalement l'UX du développeur.

@sylveon

Ne soyez pas surpris que la communauté de développement Windows ignore tout ce qui sort de Redmond avec une telle justification de la baisse de productivité.

La même chose se produisait avec CX... il était en grande partie inutilisé parce que les développeurs C++ n'aiment pas les extensions de langage propriétaire.

En supposant que nous gardions les mêmes détails dans le package de l'application et que nous utilisions la version de manière appropriée, Windows reconnaîtra-t-il qu'il s'agit d'une nouvelle version de la même application et conservera-t-il les données locales, ou l'installera-t-il en tant qu'application différente ?

@VagueGit , c'est une excellente question. En fin de compte, la technologie d'installation des applications UWP et Desktop est la même. J'ai l'impression que la réponse est oui ? Je pense qu'à partir de SDK plus récents, même les applications UWP ont l'extension .msix (je peux me tromper, alors ne me citez pas). Je suis sûr que vous pourriez essayer cela localement et le découvrir? @adambraden pour fyi.

Avez-vous des suggestions sur la façon d'avancer / de poser des questions sur l'empaquetage du framework pour .NET 5 (ou je suppose 6 à ce stade) ? J'ai ouvert un problème et je n'ai eu aucune réponse. L'intégration de .NET 5 dans l'application est un échec.

@lmcdougald Je pense savoir à quel problème vous faites référence (mais je ne le trouve pas). Il y en aura un, mais j'imagine que ce sera dans le délai .net6. Tout le monde est conscient que c'est quelque chose qui doit être fait.

Et dans le processus, revenez aux jours de productivité de l'écriture manuelle de MIDL avec une belle expérience de type bloc-notes et de la copie de fichiers, apparemment l'équipe Windows ne peut pas laisser tomber l'expérience de développement ATL, au lieu de fournir une expérience de type NET pour les flux de travail C++. C++/CX devenait trop proche de C++ Builder, il a donc dû être tué au nom de trucs ISO, qu'avec de la chance, nous pourrions les obtenir en C++23 et en 2025 en VS.

Nous lancer également des problèmes GitHub concernant l'équipe à laquelle donner des commentaires est un moyen très rapide de perdre tout intérêt. Apparemment, je m'en soucie trop.

@pjmlp J'apprécie votre honnêteté et votre passion. Je suis tout à fait d'accord pour dire que l'expérience C++ actuelle est médiocre. Nous avons fait pas mal de choses pour que l'expérience C++ ressemble davantage à .NET, mais comme @sylveon l'a mentionné, elles ont un coût. Nous avons finalement décidé que si nous voulions consacrer des efforts d'ingénierie à l'amélioration du C++, nous devions le consacrer à la diffusion du standard C++. Il est regrettable que les méta-classes soient une issue, et nous discutons des moyens d'améliorer l'expérience dans l'intervalle, car je suis d'accord avec vous que nous ne pouvons pas attendre aussi longtemps.

Merci pour la réponse - je me contente de "tout le monde est conscient que c'est quelque chose qui doit être fait" et je vais vivre avec un binaire gonflé pendant environ un an.

@stevenbrix et @VagueGit - vous devriez toujours pouvoir utiliser un fichier d'installation d'application pour vos packages msix. le fichier appinstaller n'est rien de plus qu'un fichier json fournissant l'uri à vos packages. Étant donné que vous avez mentionné les scénarios d'entreprise, vous pouvez personnaliser les URI de l'installateur d'applications de manière appropriée pour les emplacements internes, ou les rendre également différents pour l'accès externe, le tout en fonction de votre CDN. Concernant la gestion des versions - oui pour les applications packagées si l'identité du package est la même, l'installation d'une nouvelle version aura alors accès aux données d'application existantes.

@stevenbrix @VagueGit Je répondrai avec les informations que j'ai actuellement sur l'expérience de l'assistant. Je suis encore très nouveau dans ce rôle alors n'hésitez pas à prendre tout ce que je dis avec un grain de sel. Cela étant dit, mon équipe dirige actuellement les efforts dans Windows Template Studio . Cette application vous permet actuellement de créer une nouvelle application WPF ou UWP à partir de modèles existants dans notre assistant avec les pages et les frameworks que vous désirez.

L'objectif et le plan actuel de cette application à l'avenir sont d'unifier et d'améliorer l'expérience de développement pour tous les utilisateurs. Nous développons actuellement des modèles pour les applications de bureau avec WinUI 3. Vous pouvez trouver le problème de suivi ici . Nous envisageons également de faire de même pour UWP afin que nos utilisateurs puissent facilement migrer leurs projets le moment venu. Nous ne savons pas encore exactement comment cela va se dérouler, mais notre objectif sera d'unifier et de simplifier au maximum l'expérience. J'espère que cela pourra aider!

La même chose se produisait avec CX... il était en grande partie inutilisé parce que les développeurs C++ n'aiment pas les extensions de langage propriétaire.

Ils les adorent sur clang, GCC, Intel. xlCC, PGI, CUDA, C++ Builder et la pléthore de plateformes embarquées.

De toute évidence, CX a été tué en raison de politiques qui ne peuvent pas accepter un environnement RAD C++ provenant de Microsoft, et nous font plutôt tous faire MDIL/ATL avec une expérience de type bloc-notes à la place.

Je les évite à tout prix quel que soit le compilateur. Surtout quand cette extension propriétaire est un langage complètement différent en soi.

Je les évite à tout prix quel que soit le compilateur. Surtout quand cette extension propriétaire est un langage complètement différent en soi.

Alors pourquoi coder par rapport à une interface utilisateur propriétaire comme WinUI, utilisez plutôt des normes ouvertes comme X Windows.

... comme si c'était utilisable sous Windows. J'évite les extensions de compilateur car je souhaite multicibler les compilateurs (Clang et MSVC) pour la validation de la conformité aux normes et je souhaite utiliser des normes C++ plus récentes.

Mon code utilise C++20. De nombreuses extensions de langage ne prennent pas en charge C++17 ou l'ont reçu très tard. Cette situation se répétera avec C++20 (ou s'aggravera puisque C++20 a beaucoup plus de nouveautés que 17). Par exemple, vous ne pouvez pas mélanger C++20 ( /std:c++latest ) et CX ( /ZW ), vous obtiendrez une erreur de compilation indiquant que les deux commutateurs sont incompatibles.

Il a fallu attendre cette année pour que NVCC prenne en charge le C++17 côté périphérique. Pas un bon coup d'oeil.

Je ne veux pas me retrouver dans un coin où l'extension de langue que j'utilise n'est pas utilisable avec une norme plus récente, mais j'ai également besoin d'une nouvelle fonctionnalité standard.

Pour les raisons ci-dessus, je les évite. Si nous régressons l'expérience du développeur WinUI C++ vers une extension de langage, je passerai à un autre framework GUI.

@sylveon Vous parfaitement portable C++20 pour WinUI est complètement inutile en dehors de Windows, allez vous amuser avec Qt sans extensions aussi.

Parce que rien d'autre ne vaut la peine d'être utilisé pour les utilisateurs de bureau C++.

Merci d'avoir confirmé que la politique insensée est ce qui a tué CX.

Suggestion d'être amical les uns envers les autres. Je ne peux pas commenter les arguments techniques du c++ et je ne jugerai pas qui a raison.
Le fait est que des phrases comme go have fun with X ne créent pas ici une ambiance conviviale et collaborative. @stevenbrix et autres, veuillez intervenir si nécessaire.

Merci @hansmbakker ️

@pjmm et @sylveon J'apprécie la conversation passionnée et honnête, c'est formidable d'avoir des clients comme vous qui se soucient de vous.

Les deux points sont extrêmement valables, et je pense que le monde est assez grand pour que vous ayez tous les deux raison.

@pjmlp, nous ne sommes pas satisfaits de l'expérience actuelle du c++ et reconnaissons que nous devons faire quelque chose avant les métaclasses c++. Nous avons eu des discussions sur c++/winrt sans idl, et @kennykerr et @Scottj1s ont fait une discussion sur le Build à ce sujet. La plupart des problèmes que nous avons rencontrés étaient liés à l'intégration avec WinUI, car notre compilateur nécessite des métadonnées. Nous voulons revoir ce flux de travail pour voir si nous pouvons avoir une histoire cohérente qui améliorera l'expérience globale des développeurs. Au lieu de ramener C++/Cx, une version sans idl de c++/winrt vous intéresserait-elle ?

Juste pour définir les attentes, je ne m'attendrais pas à voir beaucoup de progrès ici en 2020.

Je serais très intéressé par un C++/WinRT sans IDL.

L'expérience IDE n'est pas la meilleure non plus. Par exemple, nous ne pouvons pas créer un rappel d'événement à partir de l'éditeur XAML comme nous le pouvons avec C# (la liste déroulante Créer un nouveau rappel ne fait rien). Naviguer vers la définition à partir de l'éditeur XAML ne fonctionne pas non plus.

D'autres problèmes avec celui-ci sont les divers bogues du compilateur XAML que j'ai remplis dans ce référentiel, ce qui m'oblige à nécessiter des solutions de contournement qui ne sont pas requises dans d'autres langues prises en charge.

@stevenbrix , j'aimerais ajouter ma voix à C++/WinRT sans IDL (et je ne veux certainement pas voir un retour à C++/CX). Nous écrivons des logiciels multiplateformes et nous compilons à la fois avec MSVC et LLVM (y compris sous Windows), donc le C++ conforme aux normes est très important pour nous.

@stevenbrix ,

@pjmlp, nous ne sommes pas satisfaits de l'expérience actuelle du c++ et reconnaissons que nous devons faire quelque chose avant les métaclasses c++. Nous avons eu des discussions sur c++/winrt sans idl, et @kennykerr et @Scottj1s ont fait une discussion sur le Build à ce sujet. La plupart des problèmes que nous avons rencontrés étaient liés à l'intégration avec WinUI, car notre compilateur nécessite des métadonnées. Nous voulons revoir ce flux de travail pour voir si nous pouvons avoir une histoire cohérente qui améliorera l'expérience globale des développeurs. Au lieu de ramener C++/Cx, une version sans idl de c++/winrt vous intéresserait-elle ?

Juste pour définir les attentes, je ne m'attendrais pas à voir beaucoup de progrès ici en 2020.

Ce qui montre à quel point toute cette idée avec C++/WinRT était mauvaise au départ, nous l'imposant sans aucune considération pour notre baisse de productivité.

Pour mettre cela en perspective, développeur de longue date dont l'expérience de développeur Windows remonte à Windows 3.0, et de nos jours, C++ est principalement pertinent pour être utilisé avec des applications basées sur .NET, jamais seul.

Les outils Borland étaient mon pain et mon beurre jusqu'à ce que, pour diverses raisons connues des anciens développeurs Windows, la voie à suivre consistait à migrer vers les compilateurs Microsoft.

Visual C++ n'a jamais été _Visual_ en tant que C++ Builder, pas même avec C++/CLI, étant donné son manque d'intégration avec Forms et la compilation AOT.

C++/CX semblait que Microsoft l'avait enfin compris, 25 ans plus tard, nous aurions les mêmes workflows de productivité qu'en utilisant Delphi/C++ Builder les uns à côté des autres.

Au lieu de cela, ce que nous avons obtenu comme un mouvement politique pour tuer C++/CX sans aucun égard pour notre baisse de productivité agitant la responsabilité des fonctionnalités manquantes à ISO C++ et WG 21, comme si tout ce que l'équipe Visual C++ nous enlève sera accepté par le GT 21.

Et même si les fonctionnalités nécessaires seront finalement adoptées par ISO C++, sera-ce 2023, 2026,....? Et puis il y a tout l'intérêt de savoir quand ces fonctionnalités seront réellement mises à la disposition des développeurs Windows, il suffit de regarder la prise en charge des modules. Nous mettons des années interminables pour atteindre la parité avec ce que C++/CX nous offre depuis la sortie de Windows 8 en 2012.

Donc, étant donné que d'ici 2020, nous ne verrons aucune amélioration, nous parlons déjà de 9 ans ici, alors excusez-moi si j'ai tendance à être un peu énervé par la façon dont tout cela a été géré, en plus des autres problèmes que nous avons pour faire face à l'échec de l'UWP, à la Réunion, au redémarrage de l'écosystème .NET, alors qu'on nous demande de coder comme si c'était en 2000 avec une expérience de bloc-notes MIDL et une soupe de modèles sans fin comme ATL.

Alors oui, soit une version C++/WinRT sans IDL, soit au moins une expérience IDL avec prise en charge complète d'Intellisense/Intelicode et sans avoir à copier manuellement les fichiers. Cependant, cela n'enlèvera pas l'expérience de type ATL au code C++ lui-même.

Du point de vue du développement .NET/C++, je ne me soucie pas du voyage dans le temps dans le passé des frameworks Microsoft, mais plutôt de ce à quoi cela pourrait ressembler si le point de vue du C++ RAD était pris plus au sérieux, malheureusement avec la façon dont le C++/ L'histoire de WinRT a été gérée, et tout ce qui se passe maintenant avec le rétropédalage d'UWP, je me demande où sont passés "développeurs, développeurs, développeurs".

Donc désolé si cela semble encore un peu rageur, mais c'est ce que je ressens à propos de ma baisse de productivité lorsque je dois quitter .NET pour passer en C++, au nom d'une certaine pureté ISO que la plupart des compilateurs C++ ne font pas de toute façon.

Le C++ est toujours d'actualité en mode autonome. De nombreuses applications sont écrites en C++ brut sans aucun code managé en cours d'exécution. En fait, l'ensemble du runtime UWP et du framework XAML/WinUI est en C++ natif. Une application UWP écrite en C++ n'a (heureusement) aucun langage managé impliqué.

Je dirais que si vous ressentez le besoin de passer au C++ dans .NET, vous devriez vous demander pourquoi et essayer de résoudre ces problèmes directement dans .NET. Performance? Utilisez les types span, stackalloc et vecteur intrinsèques. DirectX, API natives ou COM ? Utilisez une liaison comme TerraFX. Interagir avec une bibliothèque C++ uniquement ? Réimplémentez ce dont vous avez besoin dans .NET.

.NET est mieux sans C++, et C++ est mieux sans .NET.

Je ne pense pas que la modélisation dans cppwinrt soit si mauvaise. Ce qui m'agace le plus, c'est le besoin de génération de code et l'horrible temps de compilation qu'il produit.

@sylveon Easy, en raison des API que l'équipe Windows refuse de rendre disponibles en tant qu'UWP et qu'aucune liaison tierce ne compte, tout le monde n'a pas la chance d'avoir un service juridique qui laisse tout passer, sans considération de licence et de futurs problèmes de support.

Borland (maintenant Embarcadero) et The Qt Company ont montré comment le faire, c'est à Microsoft de décider dans quelle mesure ils souhaitent conserver la plate-forme.

Essayez de voir jusqu'où vous irez avec ISO C++ dans les interfaces graphiques macOS, iOS, Android, ChromeOS.

De toute façon, s'arrêter là, c'est inutile.

@pjmlp, nous avons des applications multiplateformes avec des millions de lignes d'ISO C++ qui fonctionnent très bien sur iOS/macOS/Windows. C++ est le seul langage à utiliser lorsque vous vous souciez des performances et/ou de la durée de vie de la batterie. Les extensions C++ ne sont pas bonnes pour nous car nous utilisons plusieurs compilateurs (qui évidemment n'implémentent pas les extensions les uns des autres).
Nous avons déjà utilisé C++/CLI et c'est vraiment pénible. Des restrictions telles que les membres de classe n'autorisant que des pointeurs C++ bruts rendent difficile le stockage de pointeurs intelligents. Le temps de compilation est long (les changements de caractère unique nécessitent 5 minutes de temps de fusion MD).
C++ inclut nécessite un wrapping pour changer le pragma managé/non managé
Le compilateur est une version différente pour C++/CLI par rapport à C++ (et on m'a dit lors de la construction que le compilateur C++/CLI ne prendrait pas en charge plus tard que C++17, ce qui pose un problème lors de l'inclusion d'en-têtes de bibliothèques utilisant C++ 20 fonctionnalités).
Ce que j'essaie de dire, c'est de ne pas avoir plusieurs efforts concurrents. Tenez-vous en à la norme et travaillez avec cela. Microsoft fait partie du comité C++, ils aident à faire avancer la norme, cela devrait être l'objectif, pas les extensions propriétaires, verrouillées.

Pourrions-nous avoir un compilateur xaml, tel que xaml.exe pour compiler des fichiers xaml, similaire à midl.exe, cl.exe ou link.exe ? Il serait très utile de créer un pipeline automatique pour l'application Winui.

Parfois, nous ne voulons pas utiliser Visual Studio pour faire le développement, peut-être en utilisant n'importe quel éditeur que nous voulons, mais garder un pipeline de construction séparé. Il semble que l'application winui xaml soit une partie spéciale et il semble qu'il n'y ait pas encore d'outil en ligne de commande pour le compiler.

Ceci est requis pour des scénarios tels que cmake : https://github.com/microsoft/ProjectReunion/issues/58

Pourrions-nous avoir un compilateur xaml, tel que xaml.exe pour compiler des fichiers xaml, similaire à midl.exe, cl.exe ou link.exe ? Il serait très utile de créer un pipeline automatique pour l'application Winui.

@sammi est-ce que #1433 résume une solution plausible à ce que vous recherchez ?

Pourrions-nous avoir un compilateur xaml, tel que xaml.exe pour compiler des fichiers xaml, similaire à midl.exe, cl.exe ou link.exe ? Il serait très utile de créer un pipeline automatique pour l'application Winui.

@sammi est-ce que #1433 résume une solution plausible à ce que vous recherchez ?

@jtbrower , c'est exactement la fonctionnalité que je recherche, merci !

Certes, c'est un aperçu, et cela signifie que je ne devrais pas m'attendre à grand-chose, mais WinUI 3 Preview 2 a été décevant pour moi.

Mon plus grand besoin est dans le domaine de la conception XAML. J'ai été assez surpris par le fait que le concepteur XAML ne fonctionnait pas du tout, et jusqu'à présent, je n'ai trouvé aucune information claire sur le moment où cela fonctionnera.

Oui, je suis d'accord que le concepteur XAML actuel de Visual Studio est très lent et qu'il se bloque lorsque l'on change des choses en temps réel qui ne devraient vraiment pas le casser. Par exemple, changer Height="*" en "Auto" ou un 100. (la fenêtre d'erreur crache environ 10 erreurs - des gribouillis à gogo, et vous devez reconstruire le projet)

Pour être clair -- je n'utilise pas vraiment le concepteur pour concevoir -- je veux juste avoir une idée si ma mise en page ressemble à ce que je l'avais imaginée avant de passer par le processus de construction. Si c'est plus simple, si le concepteur était juste "Affichage uniquement", et qu'il se mettait à jour au fur et à mesure que je modifiais le XAML (sans planter), ce serait bien pour moi, car je n'utilise pas l'interface graphique pour modifier le XAML .. ou très rarement . Vraiment, ce que WindowsCommunityToolkit fait avec la source XAML qui permet à l'utilisateur de modifier la source et de voir la sortie en temps réel est suffisant pour mes besoins.

Cela dit, WinUI a une excellente idée : découpler tous ces éléments "faciles" du système d'exploitation et laisser le travail du développeur évoluer beaucoup plus rapidement, et nous pouvons regrouper les dépendances avec l'application pour éviter d'avoir à mettre à niveau 1 milliard d'appareils afin qu'ils puissent exécuter nos nouveaux produits formidables.

J'espère que Project Reunion finira également par séparer totalement l'interface graphique du conteneur de l'application. Une expérience utilisateur de type UWP sans bac à sable/limites serait un grand pas en avant.

Mais quand pouvons-nous avoir un concepteur XAML qui fonctionne à nouveau... s'il vous plaît ?

Je pense que le rechargement à chaud a principalement déprécié cet objectif "en lecture seule" du concepteur XAML.

Mais nous parlons ici des outils WinUI. Le rechargement à chaud et l'arborescence visuelle en direct ne fonctionnent pas non plus pour WinUI.

Ce que je voulais dire avec le concepteur View Only était "Je pourrais me contenter de ça si c'était quelque chose que nous pouvions mettre dans un prochain aperçu"

Je peux me tromper (ET DITES-moi si je me trompe), mais pour le moment, la seule façon de voir votre interface utilisateur dans WinUI est de la créer et de l'exécuter.

Mais nous parlons ici des outils WinUI. Le rechargement à chaud et l'arborescence visuelle en direct ne fonctionnent pas non plus pour WinUI.

Ce que je voulais dire avec le concepteur View Only était "Je pourrais me contenter de ça si c'était quelque chose que nous pouvions mettre dans un prochain aperçu"

Je peux me tromper (ET DITES-moi si je me trompe), mais pour le moment, la seule façon de voir votre interface utilisateur dans WinUI est de la créer et de l'exécuter.

Hé @ericleigh007, avez-vous eu l'occasion de consulter notre dernière version WinUI 3 Preview 3 ? Nous avons récemment ajouté de nombreuses améliorations d'outils telles que IntelliSense, Hot Reload, Live Visual Tree et Live Property Explorer. Vous pouvez consulter les notes de version ici et obtenir le dernier aperçu ici . Vos avis m'intéressent donc n'hésitez pas à me contacter !

@JeanRoca Malheureusement, rattraper son retard avec l'expérience de développement C++/CX n'était pas l'une de ces améliorations d'outils. Ne vous attendez pas à beaucoup d'amour des développeurs pour WinUI lorsque l'outil C++ proposé donne l'impression de revenir à 2000, en écrivant des fichiers IDL dans le bloc-notes (sans aucun support d'éditeur) et en copiant manuellement les fichiers.

Cela me fait rester autant que possible dans .NET, ou simplement continuer à utiliser C++/CX malgré les avertissements pour passer à C++/WinRT.

Merci pour la mise à jour; J'essaierai ça aujourd'hui et je ferai un rapport. ??

Envoyé depuis Mail https://go.microsoft.com/fwlink/?LinkId=550986 pour Windows 10

De : JeanRoca [email protected]
Envoyé : mercredi 18 novembre 2020 04:41
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Eric [email protected] ; Mentionnez [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Expérience et outils des développeurs WinUI 3.0 - Input Needed (#1045)

Mais nous parlons ici des outils WinUI. Le rechargement à chaud et l'arborescence visuelle en direct ne fonctionnent pas non plus pour WinUI.

Ce que je voulais dire avec le concepteur View Only était "Je pourrais me contenter de ça si c'était quelque chose que nous pouvions mettre dans un prochain aperçu"

Je peux me tromper (ET DITES-moi si je me trompe), mais pour le moment, la seule façon de voir votre interface utilisateur dans WinUI est de la créer et de l'exécuter.

Hé @ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df1%ea71%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df91%ea71%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df91%ea71%7C%af640773 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jha7IQJyg%2BKEZKwBvAkLEZ0c1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jha7IQJyg%2BKEZKwBvAkLEZ0c%FGz2SU10i Nous avons récemment ajouté de nombreuses améliorations d'outils telles que IntelliSense, Hot Reload, Live Visual Tree et Live Property Explorer. Vous pouvez consulter les notes de version ici https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160082691% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE% 3D et réservé = 0 et arriver le dernier aperçu https://eur05.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fdocs.microsoft.com% 2Fen-nous% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc%3D&réservé=0 . Vos avis m'intéressent donc n'hésitez pas à me contacter !

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729402012 & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3D et réservé = 0 , ou désabonnement https: //eur05.safelinks.protection.outlook .com /? url = https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&réservé=0 .

-Il n'y a pas d'éditeur/méthode wysiwyg qui fonctionne avec winui3 c++ (desktop) pour le moment, non ?

Microsoft parvient également à s'aliéner les utilisateurs C++/CX ? Tout ça ne s'annonce pas bien du tout. Quiconque a adopté la technologie Microsoft poussait il y a quelques années pour UWP, que ce soit .net ou c++, est maintenant en difficulté sans le soutien de Microsoft.

Il semble que WinUI 3 ne s'occupe que des applications de bureau écrites en WPF - mais ils vont rapidement se rendre compte qu'UWP n'a pas encore toutes les fonctionnalités de WPF et WinUI moins de fonctionnalités. Tout le monde va être frustré, ce qui est un mauvais endroit pour démarrer WinUI 3.

@robloo En tant que personne qui prônait l'UWP, ils m'ont perdu, c'est WPF et Win32 jusqu'à ce qu'ils résolvent le problème.

C++/WinRT était une décision politique, et on nous a dit de simplement l'avaler et d'attendre qu'ISO C++ fournisse finalement la prise en charge de la réflexion et des métaclasses, pour que l'équipe Visual Studio reproduise l'expérience C++/CX.

Comme mentionné, même l'édition de fichiers IDL n'est pas différente de l'utilisation du Bloc-notes brut.

Le fait que nous, dans .NET, devions supporter que Microsoft ne mette pas tous les composants UWP à notre disposition, était en quelque sorte supportable avec C++/CX offrant une expérience similaire à C++/CLI. Maintenant, avec C++/WinRT, nous revenons à ATL.

Ensuite, à la lecture des discussions sur les enjeux réunionnais et de la feuille de route de mise à jour, il est clair qu'ils mettront plusieurs années à rectifier le tir.

WPF et Win32 sont peut-être anciens, mais ils sont là et fonctionnent, sans avoir encore une autre réécriture et perte de fonctionnalités.

-Il n'y a pas d'éditeur/méthode wysiwyg qui fonctionne avec winui3 c++ (desktop) pour le moment, non ?

Le concepteur XAML fonctionne en quelque sorte, mais il n'a pas été vraiment conçu pour l'édition wysiwyg au départ. Le rechargement à chaud (qui fonctionne désormais dans l'aperçu 3) fonctionne mieux.

L'arbre visuel en direct et la vue des accessoires en direct fonctionnent très bien dans l'aperçu 3. Quand le concepteur est-il prévu pour être disponible ?

Vous avez également remarqué que le concepteur de bureau (WPF) (pas UWP) fonctionnait auparavant en 2.4 (ou quelque chose du genre), mais maintenant mes tests ne le voient plus fonctionner? Est-ce que je manque quelque chose avec l'état actuel du concepteur ?

Désolé, je suis en retard à la fête. @wjk a réussi avec son premier point.

1. MSIX, c'est bien beau, mais j'utilise toujours le bon vieux MSI pour installer des applications plus complexes qui nécessitent des fonctionnalités que MSIX ne prend pas en charge. Je suis également méfiant à l'idée d'utiliser MSIX en raison du coût des certificats Authenticode requis.

J'apprécie vraiment l'attrait de MSIX, mais ce mandat de signature de certificat est un compromis pour moi. J'ai besoin d'un assistant d'installation adapté à SCM que je peux utiliser pour créer une expérience d'installation de bureau classique. Pourquoi ne pas utiliser les améliorations de MSIX et créer une nouvelle version du programme d'installation MSI sans le Microsoft Store et les exigences de certification pour une expérience de développement plus moderne ? C'est peut-être ce que signifie la fonctionnalité « Prend en charge le déploiement non MSIX » répertoriée dans la feuille de route actuelle ? Si c'est le cas, je suppose que je suis coincé à attendre la 3.x, à moins que par miracle, cela en fasse une version antérieure. J'attends cela avec impatience car les projets d'installation VS sont tragiquement obsolètes et pas du tout conviviaux pour le contrôle de source. ??

@Chiramisu Je suis d'accord avec le sentiment, mais je suis également confus - qu'en est-il de l'expérience de chargement latéral + AppInstaller n'est pas suffisant ?

@Chiramisu Avez-vous essayé WiX ? Je l'utilise pour tous mes installateurs basés sur MSI, et cela fonctionne très, très bien. Il existe également une extension Visual Studio , vous pouvez donc avoir des projets WiX qui automatisent les différentes commandes de compilation.

@robloo En tant que personne qui prônait l'UWP, ils m'ont perdu, c'est WPF et Win32 jusqu'à ce qu'ils résolvent le problème.

C++/WinRT était une décision politique, et on nous a dit de simplement l'avaler et d'attendre qu'ISO C++ fournisse finalement la prise en charge de la réflexion et des métaclasses, pour que l'équipe Visual Studio reproduise l'expérience C++/CX.

Comme mentionné, même l'édition de fichiers IDL n'est pas différente de l'utilisation du Bloc-notes brut.

Le fait que nous, dans .NET, devions supporter que Microsoft ne mette pas tous les composants UWP à notre disposition, était en quelque sorte supportable avec C++/CX offrant une expérience similaire à C++/CLI. Maintenant, avec C++/WinRT, nous revenons à ATL.

Ensuite, à la lecture des discussions sur les enjeux réunionnais et de la feuille de route de mise à jour, il est clair qu'ils mettront plusieurs années à rectifier le tir.

WPF et Win32 sont peut-être anciens, mais ils sont là et fonctionnent, sans avoir encore une autre réécriture et perte de fonctionnalités.

Juste pour que je puisse suivre, pouvez-vous m'indiquer de quelle édition IDL vous parlez avec C++/WinRT ? D'après ce que j'ai vu de la syntaxe co_await et d'autres syntaxes C++ 17, la complexité semble avoir augmenté considérablement par rapport à C++/CX.

MME? N'est-il pas possible que, à moins que quelqu'un ne crée de très bons wrappers autour de cela, que C++/WinRT basé sur les capacités de C++ 17 soit trop complexe et trop différent des conceptions actuelles ? C++/CX ne pourrait-il pas être conservé suffisamment pour qu'un "excellent wrapper" soit créé pour C++ 17 afin de rendre C++/WinRT raisonnablement simple à utiliser et vers lequel migrer ?

(maintenant quelqu'un va créer un lien vers un article qui montre comment cela est fait, et je vais me sentir stupide)

@lmcdougald, je n'ai pas encore essayé. Il convient de noter que mon projet particulier est toujours sur .NET Framework 3.5. Je sais je sais. Je n'ai pas encore été autorisé à le mettre à jour, donc je suis coincé avec quelle technologie Installer fonctionnera avec cet ancien cadre. ??

@wjk J'ai examiné cela dans le passé, mais non, je ne l'ai pas encore essayé. Bien que compte tenu de ce qui précède, il semble que ce soit la seule technologie qui puisse fonctionner pour mon projet existant, tel quel. Avez-vous utilisé cela pour des applications WinForms basées sur un ancien cadre par hasard ? Malheureusement, je suis un développeur solitaire, je dois donc exercer des préjugés extrêmes sur la façon dont je passe mon temps et je n'ai pas la liberté d'expérimenter de nouvelles technologies.

Gentiment

@Chiramisu Oui, WiX fonctionne avec les anciennes versions du .NET Framework, et oui, il fonctionne également avec les applications winforms. Comme il crée des fichiers MSI bruts, WiX peut tout installer, dans n'importe quel langage de programmation. Pour ce qui est de l'apprentissage, je commencerais par les tutoriels de base . J'aimerais également souligner comment détecter si .NET est installé et comment exécuter NGEN sur des fichiers à l'aide de WiX , puisque vous utilisez ces technologies dans votre application. L'extension Visual Studio est également livrée avec un certain nombre de modèles de projet, pour vous donner le bon squelette de code à ajouter. (Remarque : n'utilisez pas le modèle Bootstrapper, car il s'agit d'un sujet beaucoup plus avancé.) J'espère que cela vous aidera !

@Chiramisu Je suis tellement confus par ce que vous recherchez - il me semble que vous recherchez des outils de packaging pour votre projet actuel et non pour un projet WinUI 3.0.

Il convient de noter que .NET Framework 3.5 peut être empaqueté dans un MSIX. Vous pouvez créer un package MSIX pour votre application existante avec un projet de package dans VS 2019, puis effectuer une longue transition en toute transparence, mais c'est beaucoup de travail :

WinUI 3.0 ne prendra jamais officiellement en charge .NET 3.5 et ne prendra probablement jamais en charge .NET Framework, quelle que soit la version. Je commencerais votre modernisation en visant à passer à .NET 4.6 (ou idéalement à une version supérieure, 4.8 serait l'idéal) sans changer votre projet d'emballage existant. Si cela se passe bien, je commencerais alors à transférer les fonctionnalités vers une bibliothèque partagée .NET Standard que vous référencerez à partir de votre application .NET 4.6+ mise à jour.

Une fois que l'application .NET 4.6 est stable et testée, vous pouvez l'échanger en tant que mise à jour automatique pour votre projet d'empaquetage MSIX. Après l'étape .NET Standard, vous pouvez créer un chef de projet qui utilise presque le même code que .NET Core 3.1 (ou 5, mais j'ai l'impression que le statut LTS signifie probablement quelque chose pour votre organisation). Encore une fois, testez puis basculez le MSIX pour utiliser cette version.

Passer à WinUI à partir de WinForms à ce stade est une question d'apprentissage de WinUI et de réimplémentation de l'interface. Encore une fois, créez un nouveau chef de projet, implémentez + référencez la bibliothèque .NET Standard, testez, puis basculez le package pour utiliser cette version.

C'est ainsi que je procéderais à la modernisation sans créer de projets très divergents à un moment donné. Je donnerais la priorité à la configuration de l'emballage MSIX et des étapes standard .NET 4.6 + .NET, car celles-ci vous apporteront beaucoup plus d'outils d'aide et de connexion au cycle de développement .NET moderne. Passer rapidement à .NET 5 semble être une mauvaise idée pour votre organisation à court terme, étant donné que son cycle de vie est de 1/10e depuis que .NET 3.5 existe.

Juste pour que je puisse suivre, pouvez-vous m'indiquer de quelle édition IDL vous parlez avec C++/WinRT ? D'après ce que j'ai vu de la syntaxe co_await et d'autres syntaxes C++ 17, la complexité semble avoir augmenté considérablement par rapport à C++/CX.

MME? N'est-il pas possible que, à moins que quelqu'un ne crée de très bons wrappers autour de cela, que C++/WinRT basé sur les capacités de C++ 17 soit trop complexe et trop différent des conceptions actuelles ? C++/CX ne pourrait-il pas être conservé suffisamment pour qu'un "excellent wrapper" soit créé pour C++ 17 afin de rendre C++/WinRT raisonnablement simple à utiliser et vers lequel migrer ?

(maintenant quelqu'un va créer un lien vers un article qui montre comment cela est fait, et je vais me sentir stupide)

Étant donné que le C++ normal n'a pas les capacités d'extraire les métadonnées de type requises pour créer un fichier .winmd, vous devez écrire vos classes WinRT dans un fichier .idl, au-dessus de .hpp et .cpp.

co_await est beaucoup moins complexe que d'écrire .then([=](Foo^ thing) { }) partout, c'est très similaire à la syntaxe await de C#.

Voici un exemple (idl + hpp + cpp) du projet Runtime Component par défaut :

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

Voici un petit exemple de co_await :

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

Salut,

Nous lisons vos commentaires et prenons des notes sur les points douloureux.

@ericleigh007 XAML Designer était sorti car après avoir recueilli les commentaires des clients, les principaux problèmes du client concernaient l'amélioration de la boucle interne du développeur. Hot Reload et Live Visual Tree étaient en tête. La barre d'outils intégrée à l'application est une autre au-dessus qu'elle n'a pas pu faire l'aperçu 3. Vous avez raison de ne pas savoir quand le concepteur XAML le sera; nous devons mettre à jour la feuille de route des fonctionnalités . Selon le plan d'ingénierie actuel, il sort du 3.0 RTM, il est donc post-3.0.

@pjmlp Je sympathise avec votre peinture sur C++/WinRT et la nécessité d'ajouter les IDL. C++/CX est bien meilleur dans cet aspect. L'amélioration de l'expérience C++/WinRT est un autre sujet que nous devons aborder. Des outils tels que Live Visual Tree et Hot Reload fonctionnent à la fois sur C# et C++, mais il y a des choses spécifiques qui n'affectent que C++ et doivent être abordées séparément. Selon le plan d'ingénierie actuel, la résolution du problème IDL est hors du 3.0 RTM.

@robloo , nous ne prenons pas en charge les applications de bureau écrites en WPF. C++/WinRT est un premier citoyen de l'écosystème WinUI. C'est ce que nous utilisons pour écrire WinUI, nous mettons donc en place nos propres outils et langages.

@Chiramisu Permettez-moi d'expliquer ce que signifie "prend en charge le déploiement non MSIX". Aujourd'hui, vous devez installer et exécuter une application Desktop WinUI 3 à l'aide de MSIX. Cette capacité consiste à supprimer ce besoin. Pour exécuter une application Desktop WinUI 3, il vous suffit de doubler un .EXE, et c'est tout. Pour installer votre application, vous pouvez simplement faire une xcopy (pas besoin de signer quoi que ce soit). Fondamentalement, vous pourrez utiliser d'autres systèmes d'emballage et d'installation comme WiX.

@ marb2000 Merci d'avoir reconnu le problème. Ce que moi et beaucoup d'autres développeurs Windows ne comprenons pas, c'est pourquoi vous (comme dans la gestion de WinDev) avez décidé que c'était une bonne idée de forcer brutalement C++/WinRT sur nous avec des outils inférieurs, même revenir à MFC se sent mieux, au moins nous sommes ne copiez pas manuellement les fichiers.

En ce moment, je me concentre sur ASP.NET, WFP et Win32, continuez à suivre les trucs UWP dans l'espoir que Microsoft se rende finalement compte que nous en avons marre de réécrire des applications et d'être entraînés sur des configurations manuelles, comme dans l'UAP => UWP transition, .NET Framework vers .NET Core, ou oui C++/CX => C++/WinRT.

Il s'agit plutôt d'un retour d'information, en tant que membre vocal de la communauté des développeurs Windows qui se sent un peu déçu par les réécritures continues depuis l'introduction de Windows 8.

@pjmlp Je ne sais pas pourquoi vous critiquez C++/WinRT qui n'est qu'un wrapper C++ (conforme à la norme) autour des API Windows. Il est possible d'écrire des applications avec C++/WinRT sans avoir besoin d'outillage (et de fichiers IDL, etc.).

@pjmlp Je ne sais pas pourquoi vous critiquez C++/WinRT qui n'est qu'un wrapper C++ (conforme à la norme) autour des API Windows. Il est possible d'écrire des applications avec C++/WinRT sans avoir besoin d'outillage (et de fichiers IDL, etc.).

C'est exactement le problème, aucun support d'outillage par rapport à l'expérience de développement de C++/CX dans Visual Studio.

Pas de support d'édition pour les fichiers IDL, pas même la coloration syntaxique, encore moins intelisense. Et puis on se fait dire de copier manuellement, ou de fusionner, les unités de traduction générées !

C'est comme faire de l'ATL à l'époque.

Je me fiche de la compatibilité ISO C++, UWP est de toute façon Windows uniquement et il n'y a pas de compilateurs C++ sans extensions de langage.

Je ne vois pas comment quiconque peut voir cela comme un progrès, à part les gars de WinDev qui étaient les seuls utilisateurs de WRL.

@pjmlp ,

Je me fiche de la compatibilité ISO C++, UWP est de toute façon Windows uniquement et il n'y a pas de compilateurs C++ sans extensions de langage.

Pour ceux d'entre nous qui écrivent de grandes applications multiplateformes C++, être conforme aux normes est un gros problème. Les restrictions de C++/CX étaient terribles (pas de variables membres qui ne sont pas des pointeurs bruts, chapeaux ! ( ^ ) etc). Nous avons actuellement une grande bibliothèque d'interopérabilité C++/CLI, et les problèmes sont trop nombreux pour être listés.

Pas de support d'édition pour les fichiers IDL, pas même la coloration syntaxique, encore moins intelisense. Et puis on se fait dire de copier manuellement, ou de fusionner, les unités de traduction générées !

Encore une fois, vous confondez C++/WinRT et outillage. Ce sont 2 choses distinctes. C++/WinRT est un wrapper C++ autour des API WinRT. IDL est pour la génération de code, et oui, je suis d'accord, c'est horrible, c'est tellement mauvais que je ne l'utilise pas.

J'écris une application Windows uniquement et je me soucie toujours de la conformité aux normes car cela me permet d'utiliser un compilateur différent dans les cas où MSVC échoue.

@MarkIngramUK

Encore une fois, vous confondez C++/WinRT et outillage. Ce sont 2 choses distinctes. C++/WinRT est un wrapper C++ autour des API WinRT. IDL est pour la génération de code, et oui, je suis d'accord, c'est horrible, c'est tellement mauvais que je ne l'utilise pas.

Je code pour les plates-formes Microsoft depuis MS-DOS 3.3, j'ai ajouté C++ à ma boîte à outils en 1992 avec Turbo C++ 1.0, j'ai utilisé la plupart des produits Borland et Microsoft en ce qui concerne le développement C++. Vous n'avez pas besoin de cours sur ce qu'est C++/WinRT.

Ce que ce n'est certainement pas, c'est une correspondance avec l'expérience des développeurs C++ Builder et Qt (avec Qt Designer), que C++/CX a montré la promesse de rattraper son retard, 25 ans plus tard.

Mais apparemment, la plupart des gens ici veulent juste Visual C++ 6.0 avec ATL 3.0, et le reste d'entre nous devrait simplement s'en tenir à l'expérience de bureau .NET 5, WPF et Win32, car nous sommes une minorité qui ne mérite pas d'être considérée, sinon C++/WinRT n'aurait jamais été poussé comme il était.

Soyons honnêtes, C++/WinRT a maintenant presque 4 ans, et Microsoft n'était même pas en mesure de fournir un support même pour la coloration syntaxique et l'intelisense ?

Quelque chose que certains d'entre nous ont conçu dans Notepad ++ (mise en évidence de la syntaxe), vraiment ?

Cela montre clairement où sont les priorités, et ce n'est pas de cette façon que WinUI sera adopté, trop de réécritures depuis Windows 8.

@pjmlp , encore une fois, vous parlez de mauvaises choses. C++/WinRT n'est que C++, il a donc une coloration syntaxique et il prend en charge intellisense. Tout comme n'importe quel autre code C++ que vous avez.

L'intégration IDE pourrait être meilleure, comme vous l'avez mentionné, la mise en évidence de la syntaxe IDL et des trucs comme suggérer de créer une implémentation par défaut dans .hpp et .cpp à partir de l'IDL (comme la façon dont actuellement une fonction déclarée sans définition dans un en-tête vous invite avec des gribouillis verts à créer un), mais revenir à C++/CX est un net downgrade IMO. Cela demanderait trop d'efforts pour intégrer toutes les bibliothèques et le code partagé que j'utilise avec C++/CX, et m'obligerait à rétrograder mon projet de C++20 à C++17 (que je ne veux pas abandonner, 20 me donne trop de bonnes choses).

C++/WinRT est également beaucoup moins intrusif que C++/CX lorsque les programmes veulent simplement consommer des classes WinRT, pas les créer.

Qt et C++ Builder acquièrent leur expérience dans le C++ principalement conforme aux normes (notez que Qt a quelque chose de similaire à IDL, nommé Qt MOC). Si ceux-ci le peuvent, VS le peut aussi. Cela nécessite juste plus d'amour de la part de quelqu'un dans DevDiv.

Et comme vous l'avez mentionné précédemment @sylveon , nous sommes libres de construire avec d'autres compilateurs (nous construisons actuellement avec MSVC et Clang/LLVM). Avec C++/CX ou d'autres extensions MS, ce serait impossible.

@MarkIngramUK et @sylveon

J'en ai fini avec ce fil, il est assez clair que les commentaires comme le mien ne sont pas les bienvenus pour améliorer l'expérience et les outils des développeurs WinUI.

Amusez-vous avec votre C++/WinRT conforme aux normes.

pouvez-vous modifier ceci pour corriger la faute de frappe "pas de restauration". Je pense que c'est censé être "maintenant..."

@pjmlp Je pense que je comprends EXACTEMENT ce que vous voulez dire.

Il y a environ un an, j'ai abandonné l'idée de porter mon code UWP C++/CX vers C++/WinRT. L'incitation au portage était de pouvoir utiliser Clang pour compiler mon application UWP car MSVC++ contient un bogue que j'ai signalé il y a environ 18 mois, mais ils ne semblent tout simplement pas intéressés à le corriger.

Cependant, il s'est ensuite avéré que Visual Studio ne prend pas en charge la création d'applications UWP à l'aide de Clang. Génial, donc l'avantage "ISO C++ uniquement" de C++/WinRT est passé par la fenêtre. Ajoutez à cela le fait que porter une base de code C++/CX sur C++/WinRT, c'est comme voyager 20 ans en arrière.

J'ai essentiellement renoncé à porter nos applications Android/iOS sur Windows. Il n'est tout simplement pas possible pour un petit magasin comme nous de gérer le clusterfuck qu'est le développement d'applications Windows en plus du développement pour Android/iOS.

@MarkIngramUK Il semble que vous ne

Maintenant, après mon coup de gueule, voici ma contribution :

Prise en charge de WinUI 3 avec C++/CX. Une fois que l'outillage pour C++/WinRT est acceptable pour les entreprises qui n'ont pas les ressources pour construire leur propre outillage, il peut être possible de passer à C++/WinRT. Maintenant, ce n'est certainement pas le cas.

@pjmlp Je pense que je comprends EXACTEMENT ce que vous voulez dire.

Il y a environ un an, j'ai abandonné l'idée de porter mon code UWP C++/CX vers C++/WinRT. L'incitation au portage était de pouvoir utiliser Clang pour compiler mon application UWP car MSVC++ contient un bogue que j'ai signalé il y a environ 18 mois, mais ils ne semblent tout simplement pas intéressés à le corriger.

Cependant, il s'est ensuite avéré que Visual Studio ne prend pas en charge la création d'applications UWP à l'aide de Clang. Génial, donc l'avantage "ISO C++ uniquement" de C++/WinRT est passé par la fenêtre. Ajoutez à cela le fait que porter une base de code C++/CX sur C++/WinRT, c'est comme voyager 20 ans en arrière.

J'ai essentiellement renoncé à porter nos applications Android/iOS sur Windows. Il n'est tout simplement pas possible pour un petit magasin comme nous de gérer le clusterfuck qu'est le développement d'applications Windows en plus du développement pour Android/iOS.

@MarkIngramUK Il semble que vous ne

Maintenant, après mon coup de gueule, voici ma contribution :

Prise en charge de WinUI 3 avec C++/CX. Une fois que l'outillage pour C++/WinRT est acceptable pour les entreprises qui n'ont pas les ressources pour construire leur propre outillage, il peut être possible de passer à C++/WinRT. Maintenant, ce n'est certainement pas le cas.

Par curiosité, quel était le bug signalé il y a 18 mois ? Avez-vous un lien vers lui quelque part?

salut Miguel,
___ édité pour corriger le terrible état des choses après avoir répondu à partir d'Outlook pour Android___

J'ai eu une idée qui pourrait clarifier vos objectifs pour les aperçus et les versions puisque vous avez dit que la plate-forme Winrt est ce que vous utilisez pour développer WINUI.

prenez cet article, qui appelle un tas si l'écriture IDL et la copie manuelle des fichiers et modifiez-le pour qu'il corresponde à l'état vers lequel vous travaillez dans les outils

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

Si ce n'est pas ici, on pourra peut-être en discuter ailleurs.

d'ailleurs vous m'avez convaincu sur le concepteur XAML, notamment avec des outils sur l'existence comme XAML studio. (si seulement il était également capable de charger du code derrière pour pouvoir charger avec succès XAML qui utilise IValueConverter ...

Comme mentionné dans mon article précédent, la conformité au standard C++17 de C++/WinRT en soi n'est dans la plupart des cas aucune incitation à migrer une base de code C++/CX vers C++/WinRT car vous êtes obligé de compiler avec le compilateur Visual C++ de Microsoft De toute façon. Si vous pouviez changer le compilateur, cela changerait complètement.

Mais Visual Studio ne prend pas en charge la désactivation du compilateur pour les composants Windows Runtime. C'est un mystère pour moi pourquoi cela n'est pas pris en charge, en particulier parce qu'il est pris en charge pour les applications de bureau, comme indiqué dans cet article de blog . La prise en charge de Clang devrait vraiment être étendue pour les composants Windows Runtime.

Nous utilisons Clang pour compiler notre base de code pour Android et iOS. Pouvoir utiliser Clang pour compiler notre base de code pour Windows serait en fait une très très bonne raison de migrer loin de C++/CX. La demande de fonctionnalité Visual Studio pour cela existe déjà mais rien n'a été fait jusqu'à présent par l'équipe Visual Studio.

Vous êtes conforme à la norme C++, vous avez la prise en charge de Clang dans Visual Studio pour les applications de bureau. Alors, veuillez effectuer la dernière étape et fournir une véritable raison de migrer hors de C++/CX en fournissant la prise en charge de Clang pour les composants Windows Runtime.

La conformité aux normes est utile pour les consommateurs - comme vous le mentionnez, les producteurs sont collés à MSVC. Il existe un moyen de "forcer" clang-cl (c'est effectivement ce que fait déjà l'ensemble d'outils LLVM ) en définissant la propriété CLToolExe sur un chemin vers clang-cl dans le fichier .vcxproj . Je ne sais pas si cela fonctionne bien dans les projets UWP, mais cela vaut la peine d'essayer.

Une fois que les outils de production XAML et C++/WinRT seront déverrouillés dans les projets de bureau, ce sera également moins un problème pour moi.

@ackh J'ai un projet UWP à construire sous Clang 11 :

Voici ce que j'ai fait :

• Déchargez le projet et ajoutez la directive suivante comme première directive sous <Project>

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• Remplacez <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> par <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Remplacez <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> par <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Juste en dessous, ajoutez <ModuleOutputFile />
• Recharger le projet
• Construire

Il présente cependant quelques écueils :

• Certains avertissements concernant les arguments inutilisés s'affichent : vous pouvez probablement les corriger en modifiant/supprimant les arguments inutilisés.
• Pour une raison quelconque, Clang émet un fichier objet 64 bits en 32 bits, il suffit peut-être d'ajouter -m32 à la CLI.
• Étant donné que Clang n'implémente pas encore complètement les coroutines, vous ne pourrez pas les utiliser.
• VS effectue une reconstruction complète à thread unique chaque fois que vous exécutez l'application plutôt que de manière incrémentielle et/ou parallèle.

Je suggérerais d'ouvrir un problème sur https://github.com/microsoft/ProjectReunion pour attirer l'attention à ce sujet.

@sylveon Merci beaucoup d'avoir posté ces instructions. Je vais essayer cela à un moment donné, mais j'espère toujours que Visual Studio le prendra en charge immédiatement.