Que tal simplesmente .ui?

Essa distinção também poderia ser útil para casos não insulares ou seria mais confusa?

Ou se isso é principalmente para ajudar a distinguir entre, por exemplo, WPF e WinUI Xaml na mesma solução, então que tal uma convenção como .winui.xaml ou .island.xaml ? Isso provavelmente tornaria mais fácil usar as ferramentas existentes.

Isso seria para cenários de ilhas XAML ou em todos os lugares? Para todos os outros cenários, não vejo qual seria o valor disso, além de criar confusão e forçar as pessoas a migrar (e provavelmente quebrar a compatibilidade com versões anteriores de muitas ferramentas, como versões mais antigas do VS). Uma convenção como "whatever.winui.xaml" provavelmente seria menos destrutiva, mas ainda assim só a vejo útil no escopo de uma ilha, não em qualquer outro lugar.

Alterando o título, não quero reduzir a discussão apenas para as ilhas XAML.

Eu digo continue usando .xaml. O escopo (e o nome) do WinUi pode mudar para incluir outras plataformas além do Windows (Talvez através do UnoPlatform?). O que acontece se o nome do projeto mudar?

Eu me inclino mais para o NÃO. A Microsoft tem feito muitas renomeações de produtos e serviços às vezes em detrimento do produto/serviço ou de seus usuários (opinião). Esta é mais uma renomeação.

Isso seria para cenários de ilhas XAML ou em todos os lugares? Para todos os outros cenários, não vejo qual seria o valor disso, além de criar confusão e forçar as pessoas a migrar (e provavelmente quebrar a compatibilidade com versões anteriores de muitas ferramentas, como versões mais antigas do VS). Uma convenção como "whatever.winui.xaml" provavelmente seria menos destrutiva, mas ainda assim só a vejo útil no escopo de uma ilha, não em qualquer outro lugar.

Em toda parte

Acho que o XAML deveria permanecer .xaml , mas se algo novo aparecesse para substituir ou ser útil ao lado do XAML tradicional, então uma extensão .winui poderia ser útil para isso. #804 :)

Este pedido me confunde totalmente… Eu tive que ler esta edição duas vezes para entender o que estava acontecendo… Isso REALMENTE fragmentará o ecossistema xaml mais do que os diferentes dialetos já fizeram.

Sem palavras agora...

@liquidboy bem, isso é pelo menos um feedback claro a favor de não fazer essa mudança :) Obrigado por emprestar sua voz.

Eu gosto da ideia de @jesbis , talvez possamos adicionar um *.islands.xaml que ajude a distinguir mais facilmente a diferença entre arquivos XAML que estão sendo executados em um contexto de ilhas versus não.

Curioso: seria melhor ter .islands.xaml que se aplicasse apenas a arquivos XAML em uma ilha ou apenas usar .winui.xaml como uma extensão geral em todos os lugares? Eu não tenho certeza de qual eu gosto mais dessas duas idéias.

Meu voto é para que ".islands.xaml" ou similar seja o padrão recomendado (mas não estritamente aplicado) em ilhas, e em todos os outros arquivos .xaml ainda são arquivos .xaml. Assim evitamos impactar desnecessariamente as pessoas que não usam ilhas.

Minha maior preocupação vem de todas as ferramentas. Não tenho nenhum problema com a extensão diferente, mas isso significa que todas as ferramentas que dependem da extensão de arquivo .xaml precisarão ser atualizadas (estou pensando em coisas como R#, XamlStyler etc). O suporte de ferramentas em torno do xaml já parece estar lutando, e isso parece que provavelmente pioraria.

Meus $ 0,02

Talvez o título do problema deva ser alterado para algo como:
Os arquivos XAML incluídos para Ilhas Xaml devem ter uma extensão de arquivo diferente com projetos WinUI 3?

Eu sou fortemente a favor de manter .xaml lá. Talvez você vá para .ui.xaml ou .xaml.ui, mas a tecnologia é forte e mantém a ajuda disponível. Por outro lado, infelizmente o xaml tem algum estigma em torno dele após as armadilhas de desempenho do wpf, silverlight e windows phone, então um nome de arquivo mais limpo pode ajudar a virar a esquina. Eu ainda amo xaml, mas não precisamos de mais confusão sobre nomes de tecnologia, a menos que seja claramente pensado.

Eu acho que é uma boa idéia tê-lo simplesmente como .ui, pois se o winui se tornar uma plataforma cruzada (como muitas coisas do Windows), ele será mais adequado.

Isso significa que será à prova de futuro.

Os arquivos de código terão uma extensão .ui.cs que é autoexplicativa e fácil de ler.

.winui.xaml

Então isso significa que teremos arquivos .winui.xaml.cs? caramba..

Use o formato json. É 2020.

JSON é duro e não muito amigável para se trabalhar.

Use o formato json. É 2020.

O formato JSON é para computadores lerem, não para humanos. É difícil de ler e não parece bom.

Acho que o .winui vai fazer o iniciante desistir. Porque vamos pensar que devemos aprender uma nova língua. E agora temos WinForms e WPF e UWP e SL e ASP e ASP.NET Core. Devemos gastar mais e mais tempo para aprender, mas não herdar. Eu não acho que devemos sempre fazer a nova tecnologia.

Desculpe, eu e muitos dos meus amigos não gostamos de aprender coisas novas. Se não esperamos ser a minoria, devemos fazer com que a tecnologia possa ser herdada e possa ser reutilizada e compatível.

Na minha opinião, uma solução mais elegante para "qual XAML é qual" seria depender do namespace xmlns padrão, como sugerido por @grokys neste comentário: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# emitir comentário

Não fizemos isso com o UWP, mas talvez possamos alterá-lo para o WinUI.

Na minha opinião, uma solução mais elegante para "qual XAML é qual" seria depender do namespace xmlns padrão, como sugerido por @grokys neste comentário: AvaloniaUI/AvaloniaVS#95 (comentário)

Não fizemos isso com o UWP, mas talvez possamos alterá-lo para o WinUI.

Você poderia introduzir o equivalente a um Doctype, como em HTML?

Você poderia introduzir o equivalente a um Doctype, como em HTML?

Talvez, mas não deveríamos. O namespace padrão deve ser o que diferencia cada plataforma diferente (afinal, eles fazem no code-behind)

O suporte de ferramentas em torno do xaml já parece estar lutando, e isso parece que provavelmente pioraria.

@keboo isso me atinge muito, e é algo que estou me esforçando muito para consertar e fazer certo.
O fato de estarmos em um mundo onde não podemos distingui-los (para o cenário das ilhas) é um produto de como o ferramental evoluiu ao longo dos anos. Tudo está completamente separado, e é quase impossível racionalizar as diferenças entre os diferentes dialetos. Eu quero mudar isso e começar a fazer a análise e a compilação XAML algo que pode ser facilmente compartilhado em todos os dialetos XAML, onde neste exemplo, WinUI e WPF estão usando o mesmo mecanismo fundamental. As ferramentas devem ser plugáveis ​​conforme declarado pelo namespace padrão e podem ser personalizadas quando necessário. Na minha opinião, não devemos precisar de nada mais do que isso para que esse cenário funcione corretamente. Embora seja um grande esforço, para mim é a coisa certa para todos nós fazermos.

@stevenbrix A plataforma atualmente entenderia quando o XAML está sendo usado em uma situação de ilha, mas o que li na pergunta desse problema é uma maneira de o desenvolvedor informar e entender como o arquivo .xaml será consumido em um WinUI 3.0 projeto.

Quanto às ferramentas XAML em geral, é necessário refazer totalmente a experiência de tempo de design IMO. O Expression Blend foi a última vez que o design e o desenvolvimento XAML foram considerados de primeira linha.

Devido à natureza do XAML, é uma forma escrita e visual. O design Visual XAML ficou em segundo plano para trazer o Intellisense para uma boa qualidade. Se pudesse haver uma experiência de design XAML robusta, de alto desempenho e fácil de criar protótipos e aprimorar - isso poderia revigorar a comunidade.

Uma abordagem de plug-in, que não requer muito trabalho para os fornecedores de controle ou kit de ferramentas, enquanto ainda oferece um bom tempo de design, paleta de ferramentas, experiência em propriedades de elementos - pode ser muito útil. À medida que o XAML se move para outros fatores de forma não tradicionais, o fluxo de trabalho do design precisa ser considerado. Duas exibições de painel (Neo e Duo), superfícies XAML hospedadas sem janela, integrações de shell, projetos de estrutura mista (ilhas xaml, misturas GDI e WinUI), Hololens Spatial 3D, Rotating Surface Hubs, etc.

Mas talvez a marcação declarativa não seja mais a maneira ideal de lidar com isso. Ou talvez deva haver mais separação entre o conteúdo XAML e o estilo XAML? Tal como acontece com HTML e CSS?

O WinUI parece uma boa oportunidade não apenas para manter as coisas como estão, mas também para planejar as próximas décadas.

Não. Eu não vejo o ponto. Não resolve nada.
Se alguma coisa, isso cria problemas com editores que já conhecem a extensão xaml.
Eu trabalho com wpf, uwp e forms xaml todos os dias e nunca fiquei confuso devido à extensão.

O objetivo do Xaml não é ser mais fácil para ferramentas? As ferramentas não podem descobrir isso sem confiar na antiga ideia de extensões de arquivo?

Quero dizer, geralmente, se nada está mudando na estrutura da interface do usuário, ou seja, ainda é XAML, não faça isso.

Se fosse uma estrutura de interface do usuário completamente nova, eu não veria um problema.

Também não sei por que você deseja diferenciar componentes XAML para ilhas com a proposta islands.xaml . Faria algo diferente em ferramentas ou é apenas para legibilidade em uma solução?

Meu primeiro pensamento é que eu absolutamente não gosto dessa ideia. Mas talvez eu não veja os problemas reais que isso pode resolver, e talvez eu não entenda o ponto.

Se houver um arquivo com xaml, quero que seja um arquivo .xaml. No passado, nunca me ocorreu que eu desejasse ter um arquivo .xaml UWP com um nome diferente de um arquivo .xaml do WPF.

A próxima coisa é que um nome de estrutura em uma extensão de arquivo não parece ser uma boa ideia, pois os nomes de estrutura podem mudar, e XAML é sempre XAML.

Então, minha opinião é: Definitivamente fique com .xaml.

Mas quais são as opções com uma extensão de arquivo .xaml?
Outra extensão de arquivo .islands.xaml? Isso significaria que a extensão do arquivo é usada não apenas para descrever o formato, mas também o conteúdo de um arquivo. Mhm... Mas a vantagem deste é que você pode torná-lo opcional para um desenvolvedor. Se eles quiserem usá-lo, eles podem chamar seus arquivos de .islands.xaml e as ferramentas irão buscá-lo com ícones diferentes, etc.

Outro namespace padrão também é uma opção válida. Mas isso significaria para o conjunto de ferramentas que ele precisa examinar cada arquivo .xaml para descobrir que tipo de arquivo é. E isso também significaria que os dialetos XAML são novamente divergidos um pouco por causa de outro namespace raiz.

Mas agora um pensamento completamente diferente:

Se eu acertei, todas essas mudanças só são realmente úteis para o caso XAML Island onde você mistura plataformas na mesma solução, certo? Porque se você usar apenas o WinUI, saberá que todos os arquivos XAML usam o WinUI. Não tenho certeza se as ilhas XAML serão um cenário principal para o WinUI ou não. No passado, quando o WPF foi introduzido, também tínhamos interoperabilidade WPF e WinForms e, para ser honesto, raramente vi desenvolvedores usando controles WPF em seus aplicativos WinForms. Em vez disso, eles continuaram a usar WinForms em WInForms e iniciaram novos projetos com WPF em vez de WinForms. E talvez o mesmo possa ser verdade para o WinUI 3, e acho que será o caso. As Ilhas XAML são uma ótima maneira de modernizar, mas, na minha experiência, os desenvolvedores só farão isso se precisarem definitivamente de um controle do WinUI em seu aplicativo WPF/WinForms. Caso contrário, eles continuam na pilha antiga e iniciam novos aplicativos na nova pilha. Observe que isso não precisa ser a verdade, é apenas a minha experiência. :-)

Isso significa que estamos falando de alterar um nome de arquivo para um cenário que pode não ser o cenário principal da plataforma. E acho que é por isso que acho que não vale a pena. E se um desenvolvedor WPF/UWP/Silverlight/Windows Phone criar um novo projeto WinUI 3? Eles vão pensar

Por que diabos eles mudaram a extensão do arquivo .xaml para ...?

Por favor, não remova a extensão de arquivo .xaml.

Por favor, não mude de extensão!

Muitos anos atrás começamos a usar a extensão .paml no Avalonia mas no final voltamos para .xaml por causa dos problemas que causava: já existem ferramentas em IDEs para lidar com XAML (não importa o quão ruim , pelo menos é alguma coisa!).

Se vamos esperar que cada dialeto XAML tenha sua própria extensão de arquivo, todo projeto que quiser usar XAML terá que escrever 100% das ferramentas do zero - mesmo coisas como as ferramentas para renomear arquivos precisarão ser reescrito a cada vez para também renomear classes code-behind etc.

Como @stevenbrix mencionou acima, existe uma maneira perfeitamente boa de saber qual dialeto de XAML um arquivo está usando, qual é o namespace padrão na parte superior do arquivo. Como primeiro passo, faça com que as ferramentas respeitem isso.

Em seguida, abra o serviço de linguagem XAML, forneça uma API para interagir com um designer e todos podem se beneficiar;)

Linda por favor ;)

Mais uma razão para não: a UWP já luta com problemas de adoção. Renomeá-lo o vende como mais uma tecnologia, em vez de "é mais ou menos a mesma coisa que wpf".
Já existem problemas maiores com as alterações de quebra do WinUI 3.0 que prejudicarão significativamente o ecossistema uwp existente. Não adicione outra coisa que seja diferente.
Ainda é xaml, apenas atingindo diferentes conjuntos de API, assim como c# ainda é c#, mesmo que eu o use para diferentes estruturas de interface do usuário. O código e as APIs que posso usar mudam, mas ainda é a mesma linguagem.

Eu voto não, não vejo benefícios, apenas mais confusão.

Mais uma razão para não: a UWP já luta com problemas de adoção. Renomeá-lo o vende como mais uma tecnologia, em vez de "é mais ou menos a mesma coisa que wpf".
Já existem problemas maiores com as alterações de quebra do WinUI 3.0 que prejudicarão significativamente o ecossistema uwp existente. Não adicione outra coisa que seja diferente.
Ainda é xaml, apenas atingindo diferentes conjuntos de API, assim como c# ainda é c#, mesmo que eu o use para diferentes estruturas de interface do usuário. O código e as APIs que posso usar mudam, mas ainda é a mesma linguagem.

@dotMorten Ha, tive o mesmo pensamento com C#. Se chamarmos os arquivos $ .xaml .winui , devemos chamar os arquivos $ .cs .wincode para torná-lo consistente. :-)

Talvez ainda esteja faltando alguma coisa, mas para mim isso causa mais confusão e não vejo os reais benefícios disso.

Meus 2 centavos, fique com _.xaml_, por favor.
Por favor, unam as coisas ao invés de divergi-las.

E se você quiser compartilhar pequenos trechos de XAML entre WPF e WinUI? Eu estou supondo que deve haver ALGUMA sobreposição, não? Isso tornaria os projetos compartilhados menos úteis... ou há realmente uma grande diferença? Se for principalmente o mesmo XAML semelhante, mantenha a mesma extensão. Se o formato for MUITO diferente do XAML de transição, pode ser um pouco mais aceitável alterar a extensão. A verdadeira questão então é quão próximo é o formato do original?

O XAML também é usado no Xamarin, que visa não apenas o Windows, mas também iOS, Android, macOS...

Substituir .xaml por .winui criará uma situação em que o Xamarin manterá .xaml para arquivos XAML (por que alguém usaria .winui para iOS ou Android?) e destinos do Windows como UWP/WPF... serão movidos para .winui para arquivos XAML .

TL;DR um formato de arquivo/convenção dois nomes (.winui para Windows, .xaml para Xamarin), para mim é confuso.

A extensão deve ser .xaml , pois a sintaxe do conteúdo é xaml, outra extensão só criaria confusão.
Eu voto em algo como .winui.xaml

fique com ".xaml" , é poderoso

Devo dizer que a Microsoft tem um problema de nomenclatura patológica!

E este realmente supera todos eles.

Não

Se você precisar ter UWP XAML e WPF XAML no mesmo arquivo de projeto, use um novo Custom Tool .

Dessa forma, a ferramenta detectará se o arquivo XAML está usando UWP XAML ou WPF XAML e os enviará para o compilador correto por meio de destinos msbuild.

Uma maneira ainda melhor é padronizar a linguagem XAML, para que possamos desenvolver um compilador comum, formato binário e biblioteca de estrutura.

É assim que eu faria!

Já que você está pedindo, não, não faça isso.

Se as ferramentas não puderem ler o arquivo para ver a diferença, o PIOR CASO deverá ser uma convenção não obrigatória de ".winui.xaml" ou algo semelhante. Novamente a chave sendo NÃO REQUERIDA . Apenas arquivos de extensão xaml devem funcionar bem, mas talvez estejam faltando algumas ferramentas aprimoradas.

Embora eu entenda a ideia por trás disso, acho que é uma solução ruim.
Primeiro, WinUI é o nome comercial do framework, não o formato do arquivo. E se alguém decidir que a versão 4 precisa alterar o nome para UniversalUI ou outra coisa? Você terminaria com um nome de estrutura diferente da extensão do arquivo, diferente do formato do arquivo. Pode ser um pesadelo.

Em segundo lugar, pode quebrar a compatibilidade com ferramentas e documentação existentes. Desenvolvedores futuros não poderiam ter claro que os arquivos WinUI são xaml internamente para que não encontrem documentos xaml como relevantes.

Terceiro, fragmentaria mais as linguagens de interface do usuário usadas nos produtos da Microsoft. Eu realmente acho que precisamos ir mais para um padrão em Xaml, então o produto não é tão importante. C# é o mesmo para Xamarin, Net Core, Windows 10 ou WPF, por que o XAML precisa ser diferente?

Deixe as pessoas organizarem seus projetos e organizarem o código para que não seja confuso para elas.

Use o formato json. É 2020.

@rickydatta Mesmo em 2020, a web usa HTML em vez de JSON para definir interfaces de usuário. Há muitas razões pelas quais linguagens de marcação como HTML e XAML são ótimas para definir UIs. JSON é ótimo para várias coisas, mas não para definir UIs. Quando você usa JSON para uma interface do usuário e tenta criar recursos como vinculação de dados, referências de recursos estáticos etc., você verá que fica bastante ilegível. Mas é offtopic aqui, então vamos deixar. Se você quiser JSON, crie um novo problema e vamos ver como a comunidade reage a ele. :-)

Eu realmente tentei evitar comentar aqui, pois a maior parte disso já foi dito, mas cedi. Desculpe. Eu sou fraco.

Não faça isso.

Se você quiser fazer uma mudança, precisa haver um conjunto claro de benefícios que superem os negativos.

Quais são os benefícios potenciais?

• Isso evitaria uma possível confusão para as pessoas que têm alguns arquivos .xaml que contêm inteiramente controles WinUI e alguns arquivos .xaml que não contêm.
• Ajude a habilitar ferramentas para determinar como trabalhar com o conteúdo potencialmente diferente de arquivos .xaml.

É isso.
Eu reli todo este tópico três vezes e não consigo ver nenhum outro benefício potencial listado aqui.

Quais são os possíveis pontos negativos?

• Isso introduziria confusão.
  -- "O que é esta nova extensão?" "O que eu preciso para abri-lo?" "Como é diferente de...?" "Por que eles mudaram isso?"
  -- Qual extensão você usa para um arquivo que contém apenas alguns controles WinUI, ao misturar elementos UWP XAML e WinUI3 existentes? Ou essa sugestão implica que essa capacidade desaparecerá? (Veja, apenas fazendo a sugestão de alterar uma extensão de arquivo, você já está introduzindo mais confusão e FUD. Se coisas como extensões de arquivo ainda podem mudar, talvez eu deva esperar olhando para o WinUI, em qualquer capacidade, até que esteja mais estável . Várias pessoas me disseram para investigar Flutter. Talvez um futuro melhor para mim esteja lá.)
  -- Minha compreensão de um dos pontos de venda das Ilhas Xaml em aplicativos WPF existentes era que significava a capacidade de reutilizar habilidades e conhecimentos existentes ao trabalhar com XAML. Essa alteração sugere que não é apenas XAML, portanto, é outra coisa que deve ser aprendida e, portanto, outra barreira potencial à adoção.)

• É desnecessário.
  -- Se as pessoas quiserem dividir arquivos dentro de uma solução, já podem fazer isso de várias maneiras: projetos diferentes; diretórios diferentes; prefixos ou sufixos em nomes de arquivos; usando múltiplas/sub-extensões; ou aninhando arquivos no VS Solution Explorer. Não está claro como uma nova extensão ou forçar todos a usar várias/sub extensões é melhor do que qualquer uma dessas opções.
  -- [Padrão] Os namespaces dentro do arquivo já informam às ferramentas qual dialeto de XAML está em uso e o que deve ser possível com ele. (Pode haver algum problema não documentado nesta área, o que significa que isso não é possível, mas se for esse o caso, são necessárias mais informações sobre por que alterar a extensão do arquivo é a melhor solução para esse problema.)

• Ignora a história.
  -- Já trabalhei com soluções que continham projetos direcionados ao WPF, Silverlight e Windows Phone. Todos eles usavam dialetos XAML diferentes, mas eu nunca fiquei confuso sobre qual estava em uso ou o que eu poderia fazer em um arquivo. Trabalhei com soluções que contêm XAML para UWP e Xamarin.Forms, mas não experimentei a confusão prevista na suposição por trás desse problema. Também conversei com muitos outros desenvolvedores com soluções semelhantes e nunca ouvi ninguém dizer que usar extensões diferentes os ajudaria.
  -- De todas as críticas que ouvi sobre a existência de diferentes dialetos de XAML, a confusão baseada na nomenclatura de arquivos nunca foi uma delas.
  -- Os desenvolvedores geralmente não gostam quando você diz a eles como eles devem nomear e estruturar arquivos e projetos sem uma boa razão. Pode ser muito melhor documentar orientações e práticas recomendadas/sugeridas para cenários como trabalhar com projetos que contenham arquivos com conteúdo semelhante.
  -- Um grande motivo pelo qual o uso mais amplo de várias extensões em um arquivo nunca decolou é que o Explorador de Arquivos (ou qualquer coisa que liste o conteúdo do sistema de arquivos - incluindo seletores e diálogos fornecidos pelo SO) pode trazer mais confusão quando eles ( estão configurados para - que é o padrão) ocultar as extensões de arquivo conhecidas. Isso pode fazer com que MyClass.winui.xaml pareça MyClass.winui , o que leva a perguntas e confusão sobre o que é o arquivo, de onde veio, por que está sendo exibido etc.
  -- Adicionar várias/sub extensões aumenta o tamanho do arquivo e, portanto, aumenta as chances de encontrar problemas relacionados ao MAXPATH. Talvez um dia isso não seja um problema, mas ainda não chegamos lá. Eu odiaria ver desenvolvedores forçados a dar a seus arquivos (e classes, já que os dois são normalmente mantidos em sincronia) nomes menos descritivos porque as ferramentas agora precisavam de seis caracteres extras para a(s) extensão(ões).

• Ele cria mais trabalho para desenvolvedores de ferramentas. (Tanto dentro como fora da Microsoft.)
  -- Mais estojo para manusear.
  -- Mais cenários para documentar e testar.
  -- Menos tempo gasto em correções de bugs e novos recursos. Com as ferramentas XAML atuais percebidas como faltando por trás de outras tecnologias e lentas para criar ferramentas personalizadas, por que fazer algo que torne a criação de novas ferramentas mais lenta?

• Corre o risco de abrir um precedente muito ruim.
  -- Se isso acontecesse, por que não seria apropriado substituir todos os arquivos .xaml atuais por .wpf , .uwp , .xamarinforms , etc.? Ou .xaml2006 , .xaml20009 , .xaml-uwp5 se o namespace subjacente, em vez de onde eles são usados, for a questão principal? Haveria um benefício potencial mínimo (como neste caso), mas seria visto por muitos como a maneira como a Microsoft sugere nomear arquivos. (Eu não ficaria surpreso se alguém não fizesse tais propostas apenas vendo a discussão aqui.)
  -- Não estou ciente de (mas feliz por ser corrigido) qualquer ferramenta fornecida pela MS manipulando arquivos de maneira diferente com base em subextensões, mas isso provavelmente forçaria o Visual Studio (e outros?, incluindo o Windows Shell?) capaz de lidar com esses cenários. Então, uma vez que a capacidade está lá, posso imaginar a tentação de introduzir uma ampla gama de sugestões de nomenclatura complexas, mas desnecessárias, sendo propostas e introduzidas demais para alguns desenvolvedores, levando à confusão para o resto de nós.

Em resumo, a proposta traria confusão e mais trabalho para um benefício teórico em circunstâncias limitadas. Se você fizesse isso, eu desistiria do desenvolvimento do Windows.

Obrigado a todos por emprestarem sua voz. Nós ouvimos você! Coletamos feedback suficiente, então podemos dizer com firmeza que alterar a extensão .xaml não é uma tarefa fácil .

Não é nossa intenção fragmentar o ecossistema ou quebrar ferramentas de terceiros (e há muitas). Concordamos que XAML é a linguagem e WinUI 3 é uma estrutura de interface do usuário que usa XAML. Por todos esses motivos, e outros, faz sentido continuar usando a extensão xaml.

Nossa equipe ainda precisa fazer alguns trabalhos de casa e avaliar outras alternativas que devemos consultar com a comunidade posteriormente. Por exemplo:

1. Fazer nada. A experiência de desenvolvimento das Ilhas XAML será assim: arquivos XAML em um projeto diferente (talvez isso não seja grande coisa). O WInUI 3 usará o mesmo namespace e isso não importa, pois será a única linguagem XAML usada no projeto.

2. Use namespaces para diferenciar entre interfaces de usuário baseadas em XAML. Hoje, WPF XAML e UWP XAML usam os mesmos namespaces, talvez o WinUI 3 deva usar um namespace diferente como o Xamarin Forms está fazendo ("http://xamarin.com/schemas/2014/forms"), então os compiladores, ferramentas e designers pode diferenciar arquivos. Por outro lado, isso criará dialetos, embora isso esteja acontecendo hoje. Em teoria, isso facilitará os desenvolvedores a copiar e colar exemplos XAML de documentos/blogs, embora, infelizmente, existam muitos exemplos que não incluem namespaces.

3. Faça alguma coisa, mas apenas para ilhas. Não há necessidade de diferenciar em todas as estruturas de interface do usuário. Podemos usar convenções. Por exemplo, no futuro, um aplicativo WPF com Ilha XAML pode conter arquivos XAML em uma pasta específica (pasta ilhas?). Isso é semelhante à localização UWP (Strings/en-US/Resources.resw).

Obrigado novamente pelo seu feedback . Abrirei novas discussões quando amadurecermos mais ideias.

Incluir uma linha de estilo snippit ou doctype para um arquivo de ilha deve ser suficiente para o conjunto de ferramentas.

Se gostar da ideia .ui.xaml porque é um bom compromisso. Ainda é uma extensão XAML válida e também pode ajudar a selecionar o editor e os ícones corretos. Também é mais eficiente do que abrir e analisar dezenas/centenas de arquivos XAML apenas para encontrar um tipo.

@marb2000 WinUI 3 é uma estrutura de interface do usuário que usa XAML

Deve ser: WinUI 3 é uma estrutura de interface do usuário que pode usar XAML. Como não requer o uso de XAML e não precisa de dependência da linguagem XAML.

Concordamos que XAML é a linguagem

Isso é bom, e muitos namespaces chamados XAML precisam ser renomeados no WinUI: qualquer coisa que não tenha a ver com a linguagem XAML.

A falta de ênfase da UWP foi dolorosa de testemunhar. Agora, quando você faz uma pesquisa no canal 9 para conteúdo UWP, obtém conteúdo Xamarin. É uma manobra tão óbvia. Por favor, pare de tentar transformar UWP em outra coisa! Reinvestir, dobrar e fazer funcionar. A UWP não precisa de uma correção de curso, ela precisa das equipes Xamarin e Office para embarcar. A política interna da Microsoft está matando a UWP.

@Noemata É uma nota oficial?