Qu'en est-il simplement de .ui ?

Cette distinction pourrait-elle également être utile pour les cas non insulaires, ou serait-elle plus déroutante ?

Ou si c'est principalement pour aider à distinguer par exemple WPF et WinUI Xaml dans la même solution, alors qu'en est-il d'une convention comme .winui.xaml ou .island.xaml ? Cela faciliterait probablement l'utilisation des outils existants.

Serait-ce pour les scénarios XAML Islands ou partout? Pour tous les autres scénarios, je ne vois pas quelle en serait la valeur, au-delà de créer de la confusion et d'obliger les gens à migrer (et probablement à briser la rétrocompatibilité pour de nombreux outils comme les anciennes versions de VS). Une convention comme "whatever.winui.xaml" serait probablement moins destructrice, mais je ne la vois toujours utile que dans le cadre d'une île, pas partout ailleurs.

Changer le titre étant donné que je ne veux pas limiter la discussion aux seules îles XAML.

Je dis continuez à utiliser .xaml. La portée (et le nom) de WinUi peut changer pour inclure d'autres plates-formes à côté de Windows (peut-être via UnoPlatform ?). Que se passe-t-il si le nom du projet change ?

Je penche plus pour NON. Microsoft fait trop de renommages de produits et services parfois au détriment du produit/service ou de ses utilisateurs (avis). C'est encore un autre changement de nom.

Serait-ce pour les scénarios XAML Islands ou partout? Pour tous les autres scénarios, je ne vois pas quelle en serait la valeur, au-delà de créer de la confusion et d'obliger les gens à migrer (et probablement à briser la rétrocompatibilité pour de nombreux outils comme les anciennes versions de VS). Une convention comme "whatever.winui.xaml" serait probablement moins destructrice, mais je ne la vois toujours utile que dans le cadre d'une île, pas partout ailleurs.

Partout

Je pense que XAML devrait rester .xaml mais si quelque chose de nouveau devait apparaître pour remplacer ou être utile aux côtés de XAML traditionnel, alors une extension .winui pourrait être utile pour cela. #804 :)

Cette demande me rend complètement confus... J'ai dû lire ce numéro deux fois pour comprendre ce qui se passait... Cela va VRAIMENT fragmenter l'écosystème xaml plus que les différents dialectes ne l'ont jamais fait...

À court de mots en ce moment...

@liquidboy eh bien, c'est au moins un commentaire clair en faveur de ne pas faire ce changement :) Merci d'avoir prêté votre voix.

J'aime l'idée de @jesbis , peut-être pourrions-nous ajouter un *.islands.xaml qui aide à distinguer plus facilement la différence entre les fichiers XAML qui s'exécutent dans un contexte d'îles et non.

Curieux : serait-il préférable d'avoir .islands.xaml qui ne s'applique qu'aux fichiers XAML dans une île, ou simplement d'utiliser .winui.xaml comme extension globale partout ? Je ne sais pas laquelle je préfère parmi ces deux idées.

Mon vote est pour ".islands.xaml" ou similaire comme modèle recommandé (mais pas strictement appliqué) dans les îles, et partout ailleurs, les fichiers .xaml sont toujours des fichiers .xaml. De cette façon, nous évitons d'impacter inutilement les personnes qui n'utilisent pas les îles.

Ma plus grande préoccupation vient de l'ensemble de l'outillage. Je n'ai aucun problème avec les différentes extensions, mais cela signifie que chaque outil qui s'appuie sur l'extension de fichier .xaml devra être mis à jour (je pense à des choses comme R #, XamlStyler , etc.). Le support de l'outillage autour de xaml donne déjà l'impression d'être en difficulté, et il semble que cela l'aggraverait probablement.

Mon 0,02 $

Peut-être que le titre du problème devrait être changé en quelque chose comme :
Les fichiers XAML inclus pour les îles Xaml doivent-ils avoir une extension de fichier différente avec les projets WinUI 3 ?

Je suis fortement en faveur du maintien de .xaml là-dedans. Peut-être que vous allez .ui.xaml ou .xaml.ui mais la technologie est forte et elle garde l'aide disponible. De l'autre côté, xaml a malheureusement une certaine stigmatisation après les pièges de performance wpf, silverlight et windows phone, donc un nom de fichier plus propre pourrait aider à tourner le coin. J'aime toujours xaml, mais nous n'avons pas besoin de plus de confusion sur les noms de technologie à moins que ce ne soit clairement pensé.

Je pense que c'est une bonne idée de l'avoir simplement en tant que .ui car si winui devient un jour multiplateforme (comme beaucoup de choses Windows), ce sera plus adapté.

Cela signifie qu'il sera à l'épreuve du temps.

Les fichiers de code auront une extension .ui.cs qui est explicite et facile à lire.

.winui.xaml

Cela signifie donc que nous aurons des fichiers .winui.xaml.cs ? beurk..

Utilisez le format json. Nous sommes en 2020.

JSON est dur et pas très convivial à utiliser.

Utilisez le format json. Nous sommes en 2020.

Le format JSON est destiné à être lu par les ordinateurs, pas par les humains. C'est difficile à lire et ça n'a pas l'air sympa.

Je pense que le .winui fera abandonner le débutant. Parce que nous penserons que nous devrions apprendre une nouvelle langue. Et maintenant nous avons WinForms et WPF et UWP et SL et ASP et ASP.NET Core. Il faut passer de plus en plus de temps à l'apprendre mais pas à en hériter. Je ne pense pas qu'il faille toujours faire de la nouvelle technologie.

Désolé, moi et beaucoup de mes amis n'aimons pas apprendre de nouvelles choses. Si nous ne nous attendons pas à être la minorité, que nous devrions rendre la technologie peut être héritée et peut être réutilisée et compatible.

À mon avis, une solution plus élégante pour "quel XAML est qui" serait de dépendre de l'espace de noms xmlns par défaut, comme le suggère @grokys dans ce commentaire : https://github.com/AvaloniaUI/AvaloniaVS/issues/95# issuecomment -541078633

Nous ne l'avons pas fait avec UWP, mais nous pouvons peut-être le changer pour WinUI.

À mon avis, une solution plus élégante pour "quel XAML est qui" serait de dépendre de l'espace de noms xmlns par défaut, comme le suggère @grokys dans ce commentaire : AvaloniaUI/AvaloniaVS#95 (comment)

Nous ne l'avons pas fait avec UWP, mais nous pouvons peut-être le changer pour WinUI.

Vous pourriez introduire l'équivalent d'un Doctype, comme avec HTML ?

Vous pourriez introduire l'équivalent d'un Doctype, comme avec HTML ?

Peut-être, mais nous ne devrions pas avoir à le faire. L'espace de noms par défaut devrait être ce qui distingue chaque plate-forme différente (ils le font dans le code-behind après tout)

Le support de l'outillage autour de xaml donne déjà l'impression d'être en difficulté, et il semble que cela l'aggraverait probablement.

@keboo, cela me touche très fort, et c'est quelque chose que je pousse fort pour que nous corrigions et que nous fassions bien.
Le fait que nous soyons dans un monde où nous ne pouvons pas les distinguer (pour le scénario des îles) est le produit de l'évolution de l'outillage au fil des ans. Tout est complètement séparé et il est presque impossible de rationaliser les différences entre les différents dialectes. Je veux changer cela et commencer à faire de l'analyse et de la compilation XAML quelque chose qui peut être facilement partagé entre tous les dialectes XAML, où dans cet exemple, WinUI et WPF utilisent le même moteur fondamental. L'outil doit être plug-able comme déclaré par l'espace de noms par défaut et peut être personnalisé si nécessaire. À mon avis, nous ne devrions rien avoir de plus que cela pour que ce scénario fonctionne correctement. Bien qu'il s'agisse d'un énorme effort, pour moi, c'est la bonne chose à faire pour nous tous.

@stevenbrix La plate-forme comprendrait actuellement quand XAML est utilisé dans une situation d'île, mais ce que j'ai lu dans la demande de ce problème, est un moyen pour le développeur de dire et de comprendre comment le fichier .xaml sera consommé dans un WinUI 3.0 projet.

Quant à l'outillage XAML en général, il nécessite une refonte totale de l'expérience de conception à l'OMI. Expression Blend était la dernière fois que la conception et le développement XAML se sont sentis au premier plan.

En raison de la nature de XAML, il s'agit à la fois d'une forme écrite et d'une forme visuelle. La conception visuelle XAML a pris du recul pour apporter Intellisense à une bonne qualité. S'il pouvait y avoir une expérience de conception XAML robuste, performante et facile à prototyper et à peaufiner, cela pourrait revigorer la communauté.

Une approche de plugin, qui ne nécessite pas beaucoup de travail pour les fournisseurs de contrôle ou de boîte à outils, tout en offrant un bon temps de conception, une palette d'outils, une expérience de propriété d'élément - pourrait être très utile. À mesure que XAML évolue vers d'autres facteurs de forme non traditionnels, le flux de travail de conception doit être pris en compte. Vues à deux volets (Neo et Duo), surfaces XAML hébergées sans fenêtre, intégrations Shell, projets de framework mixtes (îlots xaml, mélanges GDI et WinUI), Hololens Spatial 3D, Rotating Surface Hubs, etc.

Mais peut-être que le balisage déclaratif n'est plus le moyen idéal de le gérer. Ou peut-être devrait-il y avoir plus de séparation entre le contenu XAML et le style XAML ? Comme avec HTML et CSS ?

WinUI semble être une bonne occasion non seulement de conserver les choses telles qu'elles sont, mais aussi de planifier les prochaines décennies à venir.

Non, je ne vois pas l'intérêt. Cela ne résout rien.
Au contraire, cela crée des problèmes avec les éditeurs qui connaissent déjà l'extension xaml.
Je travaille avec wpf, uwp et les formulaires xaml tous les jours et je n'ai jamais été confus à cause de l'extension.

L'intérêt de Xaml n'est-il pas qu'il soit plus facile pour l'outillage ? Les outils ne peuvent-ils pas comprendre cela sans s'appuyer sur l'ancienne idée des extensions de fichiers ?

Je veux dire généralement, si rien ne change dans le cadre de l'interface utilisateur, c'est-à-dire que c'est toujours XAML, ne le faites pas.

S'il s'agissait d'un tout nouveau framework d'interface utilisateur, je ne verrais pas de problème.

Je ne sais pas non plus pourquoi vous voudriez différencier les composants XAML pour les îles avec le islands.xaml proposé. Ferait-il quelque chose de différent dans l'outillage ou est-ce juste pour la lisibilité d'une solution ?

Ma première pensée est que je n'aime absolument pas cette idée. Mais peut-être que je ne vois pas les vrais problèmes que cela peut résoudre, et peut-être que je ne comprends pas.

S'il y a un fichier contenant xaml, je veux que ce soit un fichier .xaml. Dans le passé, il ne m'est jamais venu à l'esprit que je souhaitais qu'un fichier UWP .xaml soit nommé différemment d'un fichier WPF .xaml.

La prochaine chose est qu'un nom de framework dans une extension de fichier ne semble pas être une bonne idée, car les noms de framework peuvent changer, et XAML est 4ever XAML.

Donc, mon avis est le suivant : restez définitivement avec .xaml.

Mais quelles sont les options avec une extension de fichier .xaml ?
Une autre extension de fichier .islands.xaml ? Cela signifierait que l'extension de fichier est utilisée non seulement pour décrire le format, mais aussi le contenu d'un fichier. Mhm... Mais l'avantage de celui-ci est que vous pouvez le rendre facultatif pour un développeur. S'ils veulent l'utiliser, ils peuvent appeler leurs fichiers .islands.xaml et l'outil le récupérera avec différentes icônes, etc.

Un autre espace de noms par défaut est également une option valide. Mais cela signifierait pour l'outillage qu'il doit examiner chaque fichier .xaml pour savoir de quel type de fichier il s'agit. Et cela signifierait également que les dialectes XAML sont à nouveau un peu divergés à cause d'un autre espace de noms racine.

Mais maintenant une pensée complètement différente:

Si j'ai bien compris, tous ces changements ne sont vraiment utiles que pour le cas de l'île XAML où vous mélangez des plates-formes dans la même solution, n'est-ce pas ? Parce que si vous utilisez simplement WinUI, vous savez que chaque fichier XAML utilise WinUI. Je ne sais pas si les îles XAML seront un scénario principal pour WinUI ou non. Dans le passé, lorsque WPF a été introduit, nous avions également l'interopérabilité WPF et WinForms, et pour être honnête, j'ai rarement vu des développeurs utiliser des contrôles WPF dans leurs applications WinForms. Au lieu de cela, ils ont continué à utiliser WinForms dans WInForms et ils ont démarré de nouveaux projets avec WPF au lieu de WinForms. Et peut-être que la même chose pourrait être vraie pour WinUI 3, et je pense que ce sera le cas. XAML Islands est un excellent moyen de moderniser, mais d'après mon expérience, les développeurs ne le feront que s'ils ont vraiment besoin d'un contrôle de WinUI dans leur application WPF/WinForms. Sinon, ils continuent sur l'ancienne pile et démarrent de nouvelles applications sur la nouvelle pile. Notez que cela ne doit pas être la vérité, c'est juste mon expérience. :-)

Cela signifie que nous parlons de changer un nom de fichier pour un scénario qui pourrait ne pas être le scénario principal de la plate-forme. Et je suppose que c'est pourquoi je pense que ça n'en vaut pas la peine. Que se passe-t-il si un développeur WPF/UWP/Silverlight/Windows Phone crée un nouveau projet WinUI 3 ? Ils penseront

Pourquoi diable ont-ils changé l'extension de fichier .xaml en ... ?

Veuillez ne pas supprimer l'extension de fichier .xaml.

S'il vous plaît, ne changez pas d'extension !

Il y a de nombreuses années, nous avons commencé à utiliser l'extension .paml dans Avalonia, mais nous sommes finalement revenus à .xaml cause des problèmes qu'elle a causés : il existe déjà des outils dans les IDE pour gérer XAML (peu importe à quel point , au moins c'est quelque chose !).

Si nous voulons nous attendre à ce que chaque dialecte XAML ait sa propre extension de fichier, alors chaque projet qui veut utiliser XAML devra écrire 100% de l'outillage à partir de zéro - même des choses comme l'outillage pour renommer les fichiers vont avoir besoin à réécrire à chaque fois pour renommer également les classes codebehind etc.

Comme @stevenbrix l'a mentionné ci-dessus, il existe un moyen parfaitement efficace de savoir quel dialecte de XAML utilise un fichier, quel est l'espace de noms par défaut en haut du fichier. Dans un premier temps, faites en sorte que l'outillage respecte cela.

Ouvrez ensuite le service de langage XAML, fournissez une API pour interagir avec un concepteur et tout le monde peut en bénéficier ;)

Jolie s'il-vous-plaît ;)

Une raison de plus de ne pas le faire : UWP est déjà aux prises avec des problèmes d'adoption. Le renommer le vend comme une autre technologie, plutôt que "c'est plus ou moins la même chose que wpf".
Il y a déjà des problèmes plus importants avec les changements de rupture de WinUI 3.0 qui vont considérablement nuire à l'écosystème uwp existant. N'ajoutez pas encore une autre chose qui est différente.
C'est toujours xaml, juste en frappant différents ensembles d'API, tout comme c# est toujours c# même si je l'utilise pour différents frameworks d'interface utilisateur. Le code et les API que je peux utiliser changent, mais c'est toujours le même langage.

Je vote non, je ne vois aucun avantage, juste ajouté de la confusion.

Une raison de plus de ne pas le faire : UWP est déjà aux prises avec des problèmes d'adoption. Le renommer le vend comme une autre technologie, plutôt que "c'est plus ou moins la même chose que wpf".
Il y a déjà des problèmes plus importants avec les changements de rupture de WinUI 3.0 qui vont considérablement nuire à l'écosystème uwp existant. N'ajoutez pas encore une autre chose qui est différente.
C'est toujours xaml, juste en frappant différents ensembles d'API, tout comme c# est toujours c# même si je l'utilise pour différents frameworks d'interface utilisateur. Le code et les API que je peux utiliser changent, mais c'est toujours le même langage.

@dotMorten Ha, j'ai eu la même pensée avec C #. Si nous appelons les fichiers $ .xaml .winui , nous devrions appeler les fichiers $ .cs .wincode pour le rendre cohérent. :-)

Peut-être qu'il me manque encore quelque chose, mais pour moi, cela crée plus de confusion et je n'en vois pas les avantages réels.

Mes 2 cents, restez avec _.xaml_, s'il vous plaît.
Veuillez unir les choses plutôt que de les diverger.

Que faire si vous souhaitez partager de petits extraits XAML entre WPF et WinUI ? Je suppose qu'il doit y avoir CERTAINS chevauchements, non ? Cela rendrait les projets partagés moins utiles... ou y a-t-il vraiment une énorme différence ? S'il s'agit principalement du même code XAML similaire, conservez la même extension. Si le format est PLUPART différent du XAML de transition, il peut être un peu plus acceptable de modifier l'extension. La vraie question est alors de savoir à quel point le format est-il proche de l'original ?

XAML est également utilisé dans Xamarin qui cible non seulement Windows mais iOS, Android, macOS...

Remplacer .xaml par .winui créera une situation où Xamarin conservera .xaml pour les fichiers XAML (pourquoi utiliser .winui pour iOS ou Android ?) et les cibles Windows comme UWP/WPF... passeront à .winui pour les fichiers XAML .

TL;DR un format de fichier/convention deux noms (.winui pour Windows, .xaml pour Xamarin), pour moi c'est déroutant.

L'extension devrait être .xaml car la syntaxe du contenu est xaml, une autre extension ne ferait que créer de la confusion.
Je vote pour quelque chose comme .winui.xaml

restez avec ".xaml" , c'est puissant

Je dois dire que Microsoft a un problème de nommage pathologique !

Et celui-ci les surpasse vraiment tous.

Non

Si vous avez besoin d'avoir UWP XAML et WPF XAML dans le même fichier de projet, utilisez plutôt un nouveau Custom Tool .

De cette façon, l'outil détectera si le fichier XAML utilise UWP XAML ou WPF XAML et les enverra au bon compilateur via des cibles msbuild.

Une meilleure façon encore est de standardiser le langage XAML, afin que nous puissions développer un compilateur, un format binaire et une bibliothèque de framework communs.

C'est comme ça que je ferais !

Puisque vous demandez, non ne le faites pas.

Si les outils ne peuvent pas lire le fichier pour voir la différence, alors le pire cas devrait être une convention non requise de ".winui.xaml" ou similaire. Encore une fois la clé étant NOT-REQUIRED . Seuls les fichiers d'extension xaml devraient fonctionner correctement, mais il manque peut-être des outils améliorés.

Bien que je comprenne l'idée derrière cela, je pense que c'est une mauvaise solution.
Tout d'abord, WinUI est le nom commercial du framework, pas le format de fichier. Que se passe-t-il si quelqu'un décide que la version 4 doit changer le nom en UniversalUI ou autre chose ? Vous finiriez par un nom de framework différent de l'extension de fichier, différent du format de fichier. Cela pourrait être un cauchemar.

Deuxièmement, cela pourrait rompre la compatibilité avec les outils et la documentation existants. Les futurs développeurs n'ont pas pu savoir clairement que les fichiers WinUI sont en xaml en interne, ils ne trouveraient donc pas les documents xaml comme pertinents.

Troisièmement, cela fragmenterait davantage les langages d'interface utilisateur utilisés dans les produits Microsoft. Je pense vraiment que nous devons aller plus vers une norme en Xaml, donc le produit n'est pas si important. C# est le même pour Xamarin, Net Core, Windows 10 ou WPF, pourquoi XAML doit être différent ?

Laissez les gens organiser leurs projets et organiser le code afin qu'il ne soit pas déroutant pour eux.

Utilisez le format json. Nous sommes en 2020.

@rickydatta Même en 2020, le Web utilise HTML au lieu de JSON pour définir les interfaces utilisateur. Il existe de nombreuses raisons pour lesquelles les langages de balisage comme HTML et XAML sont parfaits pour définir les interfaces utilisateur. JSON est idéal pour plusieurs choses, mais pas pour définir des interfaces utilisateur. Lorsque vous utilisez JSON pour une interface utilisateur et que vous essayez de créer des fonctionnalités telles que la liaison de données, les références de ressources statiques, etc., vous verrez que cela devient assez illisible. Mais c'est hors sujet ici, alors laissons ça. Si vous voulez JSON, veuillez créer un nouveau problème et voyons comment la communauté y réagit. :-)

J'ai vraiment essayé d'éviter de commenter ici car la plupart de cela a déjà été dit, mais j'ai cédé. Désolé. Je suis faible.

Ne fais pas ça.

Si vous souhaitez apporter un changement, il doit y avoir un ensemble clair d'avantages qui l'emportent sur les inconvénients.

Quels sont les bénéfices potentiels?

• Cela éviterait toute confusion possible pour les personnes qui ont des fichiers .xaml qui contiennent entièrement des contrôles WinUI et certains fichiers .xaml qui n'en contiennent pas.
• Aidez à activer les outils pour déterminer comment travailler avec le contenu potentiellement différent des fichiers .xaml.

C'est ça.
J'ai relu l'intégralité de ce fil trois fois et je ne vois aucun autre avantage potentiel répertorié ici.

Quels sont les inconvénients potentiels ?

• Cela introduirait la confusion.
  -- "C'est quoi cette nouvelle extension ?" « De quoi ai-je besoin pour l'ouvrir ? "En quoi est-ce différent de ...?" "Pourquoi l'ont-ils changé?"
  -- Quelle extension utilisez-vous pour un fichier qui ne contient que quelques contrôles WinUI, lorsque vous mélangez des éléments UWP XAML et WinUI3 existants ? Ou cette suggestion implique-t-elle que cette capacité va disparaître ? (Voyez, juste en faisant la suggestion de changer une extension de fichier, vous introduisez déjà plus de confusion et de FUD. Si des choses comme les extensions de fichiers peuvent encore changer, je devrais peut-être attendre de regarder WinUI, à quelque titre que ce soit, jusqu'à ce qu'il soit plus stable . Plusieurs personnes m'ont dit d'enquêter sur Flutter. Peut-être qu'un avenir meilleur pour moi se trouve là.)
  -- Ma compréhension de l'un des arguments de vente des îles Xaml dans les applications WPF existantes était que cela signifiait la possibilité de réutiliser les compétences et les connaissances existantes en travaillant avec XAML. Ce changement suggère qu'il ne s'agit pas seulement de XAML, c'est donc une autre chose qui doit être apprise, tout comme un autre obstacle potentiel à l'adoption.)

• C'est inutile.
  -- Si les utilisateurs souhaitent scinder des fichiers au sein d'une solution, ils peuvent déjà le faire de plusieurs manières : différents projets ; différents répertoires ; préfixes ou suffixes sur les noms de fichiers ; utiliser plusieurs/sous-extensions ; ou imbriquer des fichiers dans l'explorateur de solutions VS. Il n'est pas clair en quoi une nouvelle extension ou obliger tout le monde à utiliser plusieurs/sous-extensions est préférable à l'une de ces options.
  -- [Par défaut] Les espaces de noms dans le fichier indiquent déjà aux outils quel dialecte XAML est utilisé et ce qui devrait être possible avec lui. (Il peut y avoir un problème autrement non documenté dans ce domaine, ce qui signifie que ce n'est pas possible, mais si c'est le cas, alors plus d'informations sont nécessaires pour savoir pourquoi changer l'extension de fichier est la meilleure solution pour ce problème.)

• Il ignore l'histoire.
  -- J'ai déjà travaillé avec des solutions contenant des projets ciblant WPF, Silverlight et Windows Phone. Ils utilisaient tous différents dialectes XAML, mais je ne me suis jamais trompé sur ce qui était utilisé ou sur ce que je pouvais faire dans un fichier. J'ai travaillé avec des solutions qui contiennent XAML pour UWP et Xamarin.Forms, mais je n'ai pas rencontré la confusion prévue dans l'hypothèse derrière ce problème. J'ai également parlé à de nombreux autres développeurs avec des solutions similaires, et je n'ai jamais entendu quelqu'un d'autre dire que l'utilisation d'extensions différentes les aiderait.
  -- De toutes les critiques que j'ai entendues sur l'existence de différents dialectes de XAML, la confusion basée sur la dénomination des fichiers n'en a jamais été une.
  -- Les développeurs n'aiment généralement pas que vous leur disiez comment ils doivent nommer et structurer les fichiers et les projets sans très bonne raison. Il peut être bien préférable de documenter les conseils et les pratiques recommandées/suggérées pour des scénarios tels que le travail avec des projets contenant des fichiers au contenu similaire.
  -- L'une des principales raisons pour lesquelles l'utilisation plus large de plusieurs extensions sur un fichier n'a jamais décollé est que l'explorateur de fichiers (ou tout ce qui répertorie le contenu du système de fichiers, y compris les sélecteurs et les boîtes de dialogue fournis par le système d'exploitation) peut apporter plus de confusion lorsqu'ils ( sont configurés pour - qui est la valeur par défaut) masquer les extensions de fichiers connues. Cela peut faire ressembler MyClass.winui.xaml à MyClass.winui , ce qui conduit à des questions et à une confusion sur ce qu'est le fichier, d'où il vient, pourquoi il est affiché, etc.
  -- L'ajout de plusieurs/sous-extensions augmente la longueur du fichier et augmente ainsi les risques de rencontrer des problèmes liés à MAXPATH. Peut-être qu'un jour ce ne sera plus un problème, mais nous n'en sommes pas encore là. Je détesterais voir les développeurs obligés de donner à leurs fichiers (et à leurs classes, car les deux sont généralement synchronisés) des noms moins descriptifs, car l'outillage nécessitait désormais six caractères supplémentaires pour les extensions.

• Cela crée plus de travail pour les développeurs d'outils. (À la fois à l'intérieur et à l'extérieur de Microsoft.)
  -- Plus de cas à gérer.
  -- Plus de scénarios à documenter et à tester.
  -- Moins de temps consacré aux corrections de bogues et aux nouvelles fonctionnalités. Avec les outils XAML actuels perçus comme faisant défaut par rapport aux autres technologies et lents à créer des outils personnalisés, pourquoi faire quoi que ce soit qui ralentisse la création de nouveaux outils ?

• Cela risque de créer un très mauvais précédent.
  -- Si cela se produisait, pourquoi ne serait-il pas alors approprié de remplacer tous les fichiers .xaml actuels par .wpf , .uwp , .xamarinforms , etc. ? Ou .xaml2006 , .xaml20009 , .xaml-uwp5 si l'espace de noms sous-jacent, plutôt que l'endroit où ils sont utilisés, est le problème clé ? Il y aurait un avantage potentiel minime (comme dans ce cas), mais cela serait considéré par beaucoup comme la façon dont Microsoft suggère de nommer les fichiers. (Je ne serais pas surpris si quelqu'un ne faisait pas de telles propositions juste en voyant la discussion ici.)
  - Je ne suis pas au courant (mais heureux d'être corrigé) des outils fournis par MS pour gérer les fichiers différemment en fonction des sous-extensions, mais cela forcerait probablement Visual Studio (et d'autres ?, y compris Windows Shell ?) à avoir besoin d'être capables de gérer ces scénarios. Ensuite, une fois que la capacité est là, je peux imaginer que la tentation d'introduire un large éventail de suggestions de nommage complexes mais autrement inutiles proposées et introduites est trop pour certains développeurs, ce qui conduit à la confusion pour le reste d'entre nous.

En résumé, la proposition apporterait de la confusion et plus de travail pour un avantage théorique dans des circonstances limitées. Si vous faisiez cela, j'abandonnerais le développement Windows.

Merci à tous d'avoir prêté votre voix. Nous vous avons entendu ! Nous avons recueilli suffisamment de commentaires, nous pouvons donc affirmer fermement que la modification de l'extension .xaml est un non-go .

Notre intention n'est pas de fragmenter l'écosystème ou de casser des outils tiers (et il y en a beaucoup). Nous convenons que XAML est le langage et que WinUI 3 est un cadre d'interface utilisateur qui utilise XAML. Pour toutes ces raisons, et d'autres, il est logique de continuer à utiliser l'extension xaml.

Notre équipe doit encore faire ses devoirs et évaluer d'autres alternatives que nous devrions consulter plus tard avec la communauté. Par exemple:

1. Ne fais rien. L'expérience de développement des îles XAML sera telle qu'elle est : les fichiers XAML dans un projet différent (ce n'est peut-être pas un gros problème). WInUI 3 utilisera le même espace de noms, et cela n'a pas d'importance car ce sera le seul langage XAML utilisé sur le projet.

2. Utilisez des espaces de noms pour différencier les interfaces utilisateur basées sur XAML. Aujourd'hui, WPF XAML et UWP XAML utilisent les mêmes espaces de noms, peut-être que WinUI 3 devrait utiliser un espace de noms différent comme le fait Xamarin Forms ("http://xamarin.com/schemas/2014/forms"), donc les compilateurs, outils et concepteurs peut différencier les fichiers. D'un autre côté, cela créera des dialectes, bien que cela se produise aujourd'hui. En théorie, cela facilitera aux développeurs de copier et coller des exemples XAML à partir de docs/blogs, bien que malheureusement, il existe de nombreux exemples qui n'incluent pas d'espaces de noms.

3. Faites quelque chose, mais juste pour les îles. Pas besoin de différencier du tout les cadres d'interface utilisateur. Nous pouvons utiliser des conventions. Par exemple, à l'avenir, une application WPF avec XAML Island pourra contenir des fichiers XAML dans un dossier spécifique (dossier des îles ?). Ceci est similaire à la localisation UWP (Strings/en-US/Resources.resw).

Merci encore pour vos commentaires . J'ouvrirai de nouvelles discussions lorsque nous mûrirons plus d'idées.

Inclure une ligne de style snippit ou doctype pour un fichier d'îlot devrait suffire pour l'outillage.

Si j'aime l'idée .ui.xaml parce que c'est un bon compromis. Il s'agit toujours d'une extension XAML valide et peut également aider à sélectionner l'éditeur et les icônes appropriés. C'est également plus efficace que d'ouvrir et d'analyser des dizaines/centaines de fichiers XAML juste pour trouver un type.

@marb2000 WinUI 3 est un framework d'interface utilisateur qui utilise XAML

Devrait être : WinUI 3 est un framework d'interface utilisateur qui peut utiliser XAML. Puisqu'il ne nécessite pas l'utilisation de XAML et n'a pas besoin d'une dépendance au langage XAML.

Nous convenons que XAML est le langage

C'est bien, et beaucoup d'espaces de noms appelés XAML doivent être renommés dans WinUI : tout ce qui n'a rien à voir avec le langage XAML.

La désaccentuation de l'UWP a été pénible à voir. Désormais, lorsque vous effectuez une recherche sur le canal 9 pour du contenu UWP, vous obtenez du contenu Xamarin. C'est un stratagème tellement évident. S'il vous plaît, arrêtez d'essayer de transformer UWP en autre chose ! Réinvestissez, doublez et faites en sorte que cela fonctionne. UWP n'a pas besoin d'une correction de cap, il a besoin que les équipes Xamarin et Office embarquent. La politique interne de Microsoft tue UWP.

@Noemata Est-ce une note officielle ?