Estas são minhas reflexões iniciais sobre as perguntas que você fez no conteúdo da edição.

Eu venho de uma perspectiva de design e usuário, com apenas um pouco de experiência em desenvolvimento, que se interessou muito pelo desenvolvimento do Silverlight / Windows Phone 7 naquela época e agora se sente um pouco queimado.

Quais modelos seriam mais interessantes para você?

Acho que antes de pedir uma lista de ideias de modelo, é necessário algum tipo de auditoria feita nos aplicativos maiores e mais usados ​​em cada estrutura, então WPF, UWP, WinForms, MFC etc.

Examine a "silhueta" desses aplicativos e descubra os cenários de experiência do usuário comuns.

No topo da minha cabeça, há:

• Menu principal (todas as estruturas)
• MDI (vários documentos em uma única janela) (principalmente MFC)
• Guias e datagrid (WPF, WinForms, MFC)
• Faixa de opções (aplicativos Win32 Office, 3ds max, paint, wordpad, File Explorer etc)
• Utilitários da bandeja do sistema (MFC, WinForms)
• Navegadores
• Assistentes (WPF, MFC)
• Aplicativos MDI complexos (software Adobe, Visual Studio)
• Players de mídia
• LoB de visualização de dados (WPF e Web)
• Aplicativos sociais (React Native, PWA - Skype, Facebook, Twitter)

Todos ou alguns deles podem se beneficiar da integração do sistema WinRT / UWP com o Notifications / Action Center.

Todos esses modelos de Novo Projeto devem evitar os namespaces integrados Windows.Xaml, tema de controle WPF e estilos visuais WinForms em favor de novos modelos e estilos visuais que correspondem aos designs de controle FabricWeb / Fluent.

Também deve haver uma maneira fácil para os desenvolvedores com aplicativos WPF e WinForms existentes adicionarem uma dependência WinUI 3.0 que lhes dá os novos designs de controle com uma instrução de uso simples ou entrada de manifesto

Ilhas XAML

À medida que as ilhas Xaml se tornam mais fáceis de possibilitar - substituir antigos controles de webview, seletores de cores, diálogos baseados em XAML podem ser tão fáceis quanto Adicionar novo ... e escolher um diálogo ou controle padrão ao qual o código C # e C ++ existente pode chamar, e eles têm seu próprio codebehind.

Aplicativos modernos e modelos de página como aplicativos Xbox Next, NavigationView, Master / Details, Hubs, Modern Ribbon, NavigationViewTop e Pivot - todos podem ser disponibilizados para todas as plataformas de apresentação do Windows - com ilhas XAML no local e conteúdo de amostra.

Qualquer um desses cenários, que atualmente não são possíveis no UWP XAML, deve incluir controles e modelos para torná-los mais fáceis.

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

Deve ser uma pergunta quando alguém abre seu projeto na versão mais recente do Visual Studio com um SDK do Windows 10 atual. Pressione o botão e ele substituirá os espaços de nome e usando ou os sinalizará se não for um controle com o qual está familiarizado.

Em novos projetos, deve ser o padrão e o pacote nuget deve ser instalado junto com as versões futuras do SDK do Windows.

Qual seria sua solução preferida para usar componentes UWP com WinUI 3?

Tal como acontece com a resposta de atualização automática, novas páginas e projetos devem incluí-lo por padrão, e uma mensagem perguntando se eles desejam mover automaticamente para WinUI | Adicione comentários ToDo para atualizar os namespaces | Não mude para WinUI .

Para que tipo de aplicativo você gostaria de usar o WinUI 3.0?

Como usuário, quero que todos os aplicativos em execução no Windows compartilhem uma IU e UX comuns, independentemente da estrutura usada.

Quero que os aplicativos sejam instalados sem bagunçar o registro e deixar lixo para trás. (tão centenário)

Quero que todos os aplicativos possam ser instalados de dentro da loja ou de um instalador do tipo Centenário. Virtualize as pastas do sistema e do Windows para cada aplicativo.

Modernizando um aplicativo C ++ MFC com Fluent UI?

O acrílico deve estar disponível para aplicativos WPF, WinForms e MFC e incluído nos novos modelos padrão por meio de uma dependência ou manifesto do WinUI 3.0. CommonControls e estilos de janela devem usar acrílico e barras de título estendidas (que podem ser substituídas para voltar aos padrões atuais)

Os aplicativos Win32 não UWP da Microsoft precisam ser todos recompilados com WinUI 3.0 para que todos usem molduras de janela em acrílico, menus principais, ThemeShadows, Menus de contexto , Campos de texto, Barras de progresso, etc.

E então os aplicativos existentes precisam de uma solução simples para instalar o WinUI 3.0+, que então atualiza a aparência de todos os controles - ou a capacidade de aplicá-lo seletivamente em uma caixa de diálogo por vez, até que toda a IU seja atualizada.

re: namespaces, eu esperaria que eles mudassem apenas com base no destino, mesmo que exija namespaces condicionais.

Aqui estão minhas respostas:

Criação de um novo aplicativo

Quais modelos seriam mais interessantes para você?

• Adoraria ver c ++ / winRT win32 + xaml e .net core + xaml primeiro, os modelos UWP em segundo lugar, o aplicativo win32 empacotado não deve vir como um modelo, pois os modelos de pacote de aplicativos atuais devem funcionar como já funcionam com os atuais aplicativos win32 / .Net.
• Além disso, adoraria ver modelos de item como "Nova janela XAML" com código padrão para mostrá-lo em um aplicativo Win32 ou .net core existente (por exemplo: tornando o aplicativo systray existente à la Docker Desktop, capaz de mostrar um nova janela Xaml de nível superior)

Adicionar WinUI 3.0 a aplicativos Win32 existentes

• compatibilidade não retroativa é a razão exata pela qual nunca usei ilhas xaml em um projeto real (embora usei para me divertir em coisas pessoais). Desacoplar a estrutura da IU da API do Windows é uma das melhores coisas anunciadas com o roteiro do WinUI 3.0 (junto com a capacidade de aplicativos de segmentação não empacotados / não uwp para aproveitá-lo)

Atualizando seu aplicativo UWP Xaml existente para WinUI 3.0

Pode parecer desagradável, mas acho que o aplicativo UWP xaml é um nicho (desde a queda do Windows Phone, não há mais tração em relação ao UWP como plataforma de destino) e, mesmo que fosse bom ter ferramentas / interoperabilidade, eu não não acho que deveria ser o foco principal para WinUI 3.0.
Portanto, tanto o conjunto de ferramentas de atualização de namespace (que pode ser feito usando um localizar e substituir global) e a combinação de UWP xaml e WinUI xaml não parecem críticos para mim.

Além disso, quero apenas mencionar que essa é uma mudança muito bem-vinda, e ter todo o código-fonte aberto da estrutura de interface do usuário no Github é incrível! Muito obrigado por fazer isso!

Em primeiro lugar, esta é uma grande jogada! Infelizmente, não posso negligenciar o fato de que me sinto um pouco magoado pela maneira como a Microsoft lidou com os poucos últimos desenvolvedores em sua plataforma. No momento, só uso UWP para aplicativos voltados para o

1. O WPF é muito mais maduro do que o WinUI (validação, controles existentes, etc), portanto, para empresas, o WPF é um ajuste melhor
2. UWP é ótimo para várias categorias de dispositivos (celular, tablet, desktop, etc), que é onde os consumidores estão

É ótimo ver que o ponto 1 pode ser abordado com o WinUI, o que me deixa entusiasmado com o progresso do WinUI. Infelizmente 2 não é mais aplicável (não há mais dispositivos legais, apenas desktops). Isso nos faz pensar, no momento em que esse material é lançado (1 ano a partir de agora?), O que os desenvolvedores precisam nesse estágio.

Acho que o material de consumo não faz mais parte da equação, aquele navio navegou com a “estratégia” de contenção. Portanto, a única coisa para a qual pode ser bom são os aplicativos corporativos.

Em geral, eu estaria mais interessado em uma boa estratégia de migração de WPF para WinUI para tentar migrar nossa enorme base de código WPF para o Windows 10. A desvantagem de ter que atualizar aplicativos voltados para o consumidor (atualmente UWP) é que eles dependem muito em desenvolvedores de componentes externos (por exemplo, win toolkit, etc). Eu acho que não há nenhuma opção viável para atualizá-los, já que a maioria dos desenvolvedores (que eu conheço) perdeu o interesse no desenvolvimento de cliente / consumidor do Windows.

Respostas às perguntas

Criação de um novo aplicativo

Quais modelos seriam mais interessantes para você?

Eu adoraria ver .net core / xaml / C # aqui, pois acho que essa é a combinação de linguagem mais usada disponível. Mas talvez um modelo de migração seja melhor aqui (tente trazer todos a bordo o mais rápido possível, quanto mais tempo demorar, mais doloroso será).

Adicionar WinUI 3.0 a aplicativos Win32 existentes

Eu acho isso extremamente bom e nós usaríamos muito isso (mas, realisticamente, isso é pelo menos um ano de distância, já que os clientes corporativos ainda estão no Windows 7, mesmo quando o suporte MS terminar, as empresas estarão no Windows 7). Então, podemos migrar lentamente o WPF para o WinUI 3.

Você conhecia as Ilhas Xaml para modernizar aplicativos de desktop?

Sim, mas muitos clientes estão (ou estavam) no Windows 7, então não era uma opção para desenvolvedores corporativos. E para os consumidores, você pode simplesmente usar o UWP de qualquer maneira.

Essa compatibilidade com versões anteriores expandida no Windows 10 torna as Ilhas Xaml mais úteis para você?

É um bom começo porque, no momento em que esse material foi lançado, ele funcionaria em todas as versões com suporte do Windows 10 na empresa.

Atualizando seu aplicativo UWP Xaml existente para WinUI 3.0

Os aplicativos de consumidor para MS acabaram, tudo por causa das escolhas que a MS fez, não há mais espaço para isso. Eu simplesmente pularia toda essa opção e esqueceria. É triste porque coloco milhares de horas em aplicativos UWP, mas acho que precisamos tornar essa morte rápida para torná-la menos dolorosa.

Toda a história prometida esteve sempre atualizada, suporta todos os dispositivos. Acho que todos nós sabemos para que lado essa promessa foi.

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

Se forem apenas namespaces, uma pesquisa / substituição também deve resolver o problema.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Não importa mais, estou disposto a assumir a perda de milhares de horas de desenvolvimento, não há mais usuários de qualquer maneira.

Você cria ou usa bibliotecas de controle UWP Xaml ou componentes WinRT que não podem ser facilmente recompilados e atualizados junto com o código do aplicativo?

Não.

Qual seria sua solução preferida para usar componentes UWP com WinUI 3?

Ilhas UWP (espécie de componentes hospedados)

Em geral

O que você acha do plano geral 3.0 delineado acima e no roteiro? Isso permitiria que você usasse o WinUI para seus aplicativos do Windows novos e existentes?

Provavelmente precisa de algum amadurecimento, mas me vejo usando essas coisas em 1 ou 2 anos para desenvolvimento empresarial. Dependendo da dificuldade de migração, escolheremos WinUI ou web (dependendo de como o próprio Windows "evolui").

Para que tipo de aplicativo você gostaria de usar o WinUI 3.0? Criando um novo aplicativo Win32 e empacotando-o com o MSIX? Adicionando novas visualizações a um aplicativo WPF? Modernizando um aplicativo C ++ MFC com Fluent UI?

Provavelmente apenas adicionando novas visualizações a um aplicativo WPF e lentamente comece a migrar.

Eu gosto muito deste roteiro. O UWP precisa ser liberado de seus grilhões e essa é uma ótima maneira de fazer exatamente isso.

Atualizando seu aplicativo UWP Xaml existente para WinUI 3.0

Isso é muito importante para meu empregador. Temos um aplicativo de desktop UWP complexo na loja. Agora precisamos do Desktop Bridge para obter acesso às APIs win32 que não são suportadas pelo .NET Native.

Gostaria

• acesso direto a todas as APIs win32;
• usando um modelo de execução win32 simples e antigo. Estou bem com alguns sandboxing do tipo Desktop Bridge (por exemplo, virtualização do registro);
• para colocar nosso aplicativo na loja (msix) como está agora;
• ainda usar WNS (notificações push);
• uma experiência de atualização indolor de UWP para algum novo tipo de aplicativo Xaml Desktop. Eu não me importo em fazer algum trabalho manual. Talvez eu prefira uma boa documentação a ferramentas aqui.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Os estilos existentes ainda devem funcionar. Posso conviver com algumas pequenas mudanças visuais. Mas não com mudanças de comportamento.

Você cria ou usa bibliotecas de controle UWP Xaml ou componentes WinRT que não podem ser facilmente recompilados e atualizados junto com o código do aplicativo?

Não.

Qual seria sua solução preferida para usar componentes UWP com WinUI 3?

Se eles não puderem ser recompilados (terceiros): abordagem semelhante às ilhas Xaml. Caso contrário, deve ser possível transferi-los facilmente para o WinUI 3.

Em geral

Para que tipo de aplicativo você gostaria de usar o WinUI 3.0? Criando um novo aplicativo Win32 e empacotando-o com o MSIX? Adicionando novas visualizações a um aplicativo WPF? Modernizando um aplicativo C ++ MFC com Fluent UI?

• Aplicativos desktop win32, empacotados com MSIX.
• Aplicativos de plataforma cruzada Uno;)

Não introduza novos namespaces para coisas como _INotifyDataErrorInfo_ - ele deve ser usado em modelos de visualização que geralmente são multiplataforma e não devem depender do WinUI. Deve ser definido onde outras coisas como esta estão localizadas (ou seja, _INotifyPropertyChanged_ ou _INotifyCollectionChanged) _

Gostaria apenas de saber se o objetivo final é criar uma pilha de interface do usuário entre plataformas. Entender isso pode não ser completamente entendido como chegamos lá. No entanto, se essa for a intenção ... seria melhor marcar isso sem as referências de Win no início deste esforço. A longo prazo, haverá menos dores de cabeça.

Seria melhor rotular como XamlUI ou semelhante? Os namespaces Microsoft.UI. * São adequados , basta marcar o repo e como

Agradecemos seu contato. Aguarde o que está por vir neste espaço: sorria:

Para mim, todos os detalhes técnicos são menos importantes.
UWP, WPF ou qualquer estrutura apenas do Windows, por mais incrível que seja, não vai ser suficiente, desde que não seja executado em todas as plataformas (pelo menos Windows, Droid, iOS e web) e seja amigável com qualquer tamanho de tela.

A TBH me decepcionou na última versão ao descobrir que a MS não tem planos de fazer UWP ou XAML entre plataformas. Uno não obteve reconhecimento oficial além de um discurso. Ainda mais frustrante, eu diria doloroso, foi descobrir que a MS está dando tanto amor aos frameworks React Native e HTML / JS AGAIN (WinJS), enquanto negligencia os desenvolvedores de pilha .NET responsáveis.
Eu gostaria de ver a MS oficialmente criando uma pilha de interface do usuário de plataforma cruzada como o Uno, e fornecendo as ferramentas certas, modelos e suporte integrado.

E, a propósito, trabalho com o XF desde sua aquisição pela MS e gostaria que ele tivesse uma alternativa, pelos seguintes motivos: a. Sem suporte na web, b. Muito tendencioso para dispositivos móveis, sem amor por desktops c. Sua hierarquia de biblioteca parece desleixada, definitivamente quando comparada à biblioteca de controle WPF / UWP d. Não está usando MS XAML.
Aqui está a solicitação de recurso que postei na Comunidade de Desenvolvedores da Microsoft: .NET UI Standard .

Obrigado a todos!

Precisamos de uma interface de usuário XAML que também seja executada na Web (Assembly). Pelo menos um subconjunto de UWP.
Por que não abraçar a plataforma UNO e fazer a renderização da web usando o SkiaSharp?
Pode ser Silverlight 6 , a contraparte web do WinUI

Respostas rápidas para as perguntas

Quais modelos seriam mais interessantes para você?

Projetos estilo SDK do .NET core ou algum formato de projeto MSVC simplificado.
Os arquivos de projeto antigos são muito complicados para editar manualmente e existem toneladas de problemas de interação entre o sistema de projeto antigo e o novo. Devemos abandonar totalmente o sistema de projeto antigo para projetos novos.

Você conhecia as Ilhas Xaml para modernizar aplicativos de desktop?

Não. Estou reescrevendo meu aplicativo com uma alteração completa do modelo de dados, portanto, não há migração progressiva.

Essa compatibilidade com versões anteriores expandida no Windows 10 torna as Ilhas Xaml mais úteis para você?

Ainda existem muitos usuários no Windows 7 e as Ilhas Xaml não podem ajudar.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Não. Todos os meus componentes são escritos por mim mesmo, ou de MUX e WCTK, para que eu possa executar uma migração manual rápida.

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

Não tanto, porque meu projeto não é grande (~ 20 páginas e ~ 10 controles personalizados por enquanto).

Qual seria sua solução preferida para usar componentes UWP com WinUI 3?

Eu gostaria que houvesse uma versão fornecida com o sistema operacional, para permitir a criação de ferramentas muito pequenas e distribuição em KBs . A ferramenta simplesmente não funciona em um sistema operacional inferior, pois o suposto usuário pode entrar em contato comigo imediatamente (por exemplo, por meio de algum software de bate-papo).

Para que tipo de aplicativo você gostaria de usar o WinUI 3.0? Criando um novo aplicativo Win32 e empacotando-o com o MSIX? Adicionando novas visualizações a um aplicativo WPF? Modernizando um aplicativo C ++ MFC com Fluent UI?

Criar um novo aplicativo somente para Windows 10 e enviar sem a loja.
A assinatura confiável é cara para desenvolvedores individuais, e o upload para a loja não se aplica a aplicativos específicos de domínio, nem a aplicativos de longo prazo.

Minha aparência pessoal para a plataforma de IU

Conjunto de ferramentas Xaml

A linguagem xaml de alguma forma não é séria e estou enfrentando muitos problemas como "como devo representar isso". WPF xaml e UWP xaml não são totalmente compatíveis, então preciso lembrar suas diferenças. O Xaml não é totalmente compatível com os recursos do .NET, então às vezes preciso escrever alguns truques feios em meu modelo e uma classe auxiliar.

Vindo com x:Bind , as coisas ficam ainda piores. Os cenários simples são fáceis de usar, mas é muito complicado fazer coisas que vão além do acesso à propriedade. Por exemplo, ele não oferece suporte à sobrecarga de método, então devo compilar para verificar qual sobrecarga é escolhida para esta expressão de ligação. Não consigo nem fazer uma troca simples ou uma conversão "visível quando alguma propriedade é falsa" e um método auxiliar é necessário. A documentação não diz nada sobre esses cenários detalhados, então eu acho que deveria haver uma posição para discussão de design da linguagem xaml e fazer do xaml uma linguagem seriamente projetada como C #.

O editor xaml também é difícil de usar. É razoável para o designer tentar executar algum código para mostrar os efeitos reais, mas o editor de texto deve estar ciente dos metadados. Abrir um arquivo xaml na visualização do código-fonte é lento porque está ativando o designer e lançando algumas exceções de interação para xaml totalmente adequado para execução, como NullReferenceException e Cannot convert __ComObject to some type . Ele atinge ProjectReference por meio de bibliotecas construídas e resulta em erros complicados, mesmo quando uma simples edição em uma área de API não pública na biblioteca de dependência, normalmente a implementação do modelo de dados. Portanto, acho que deve haver um compilador xaml totalmente integrado ao Roslyn, que reconhece os metadados e o código-fonte.

Um melhor modelo de janelamento

É normal para aplicativos com informações e estado completo usar o modelo de múltiplas janelas em vez do modelo de navegação. Atualmente na UWP, criar uma nova janela usando ApplicationView é doloroso porque há problemas de threading. O novo AppWindow compartilha o thread da interface do usuário e não tenho certeza sobre o desempenho da interface do usuário.

Reescrever o Visual Studio no WinUI em algum momento futuro pode provar que ele é um sistema de interface do usuário maduro.

Interfaces de ligação de dados

Estamos muito cansados ​​de criar modelos implementando INotifyPropertyChanged . Eu escrevi uma tarefa MSBuild personalizada para converter um xml em acessadores de propriedade expandida, mas isso não ajuda quando eu quero fazer algo personalizado no setter quando a propriedade muda.

E há problemas de threading. Meus dados vêm totalmente de um servidor de rede em segundo plano, portanto, a captura de contexto para await não pode me ajudar. No WPF e em Binding , é exatamente como está porque Binding resolve o threading. Ao mudar para x:Bind , tenho que resolver dentro do gerador de eventos, porque x:Bind apenas opera no thread de chamada. As coisas ficam ainda piores quando tenho várias visualizações de aplicativo tocando os mesmos dados, o que significa que não há um despachante de IU global disponível e a única solução é capturar SynchronizationContext.Current no registro do evento. Para coleções, ItemsSource também não é seguro para threads e a mesma solução alternativa é necessária.

Definitivamente, deve haver um conjunto de ferramentas para resolver os problemas de modelagem, encadeamento e extensão para modelos vinculáveis ​​mutáveis. E uma solução genérica embutida para coleção vinculável deve fornecer um mecanismo para "propriedade especificada de qualquer filho alterado".

IObservableVector<T> é um tipo genérico falso que pode usar object apenas, INotifyCollectionChanged não é genérico. Apenas implementá-lo para uma coleção integrada como ObservableCollection<T> não é suficiente, especialmente para cenários complicados e orientados para ISupportIncrementalLoading / IItemsRangeInfo . A plataforma deve fornecer uma implementação abstrata padrão com as melhores práticas, permitindo ao usuário apenas implementar um método abstrato de preenchimento de dados.

@shaggygi @weitzhandler @TonyHenrique

Se houver um futuro de plataforma cruzada para UWP / XamlUI3.0 abstraindo a sintaxe XAML, do Windows Renderer, e o restante do Windows Runtime seria uma maneira de lidar com isso.

Se pudesse haver uma mentalidade quase plug-in com o projeto, poderia haver um Android ou iOS / AppKit Renderer e um Android / iOS AppKit Shim para passar ART APIs em C # e VB, bem como a linguagem C ++, C existente Apoio, suporte.
Xamarin poderia ajudar aqui.

A Microsoft não precisa ser a única a trabalhar nos renderizadores da plataforma alt.

Mas, focando no Windows por enquanto ... WinUI 3.0 poderia abranger Fabric Web / React Native / WPF / WinForms / MFC. Os PWAs também serão cidadãos de primeira classe para o desenvolvimento de aplicativos, portanto, há histórias de plataforma cruzada para aplicativos não feitos para Windows / .NET / UWP diretamente.

O que é necessário agora é fornecer uma história para que os desenvolvedores de C # /. NET / UWP tragam seus aplicativos e investimentos para um cenário mais amplo de plataformas.

Meus 2 centavos: sou um dev Xamarin.Forms e (como muitos outros) estou interessado em ver todos os dialetos XAML sendo mesclados em um que funcione em qualquer lugar, incluindo o espaço móvel. Não tenho certeza de como isso iria cair, mas é pelo menos meu desejo sobre o assunto.

WinUI 3.0 em diante, talvez - mas existem muitos aplicativos WPF por aí para esperar que todos reescrevam e traduzam todo aquele XAML. Novos projetos WPF poderiam usar o dialeto WinRT XAML mais moderno. Você pode introduzir o equivalente de um DocType ao XAML para que diferentes dialetos possam coexistir no mesmo projeto.

Mais fácil falar do que fazer, claro.

@mdtauk Acho que, uma vez que a plataforma Xaml seja realmente de código aberto, teremos um entendimento mais claro sobre o que ela depende na parte inferior da pilha (já sabemos que as principais dependências específicas da plataforma são DirectX11, Direct2D e Windows Media Foundation, mas quem sabe qual parte do SDK do Windows é usada lá) e como ela é dividida em camadas (para que possamos ter uma ideia real sobre a viabilidade de qualquer portabilidade).
Além disso, ainda não verificamos sob que tipo de licença o código-fonte será distribuído. Não tenho certeza se já foi decidido.

Android usa Vulkan e acho que suporta OpenGL
iOS e macOS usam metal

Quanto aos codecs de mídia, pode ser possível fazer uso de APIs baseadas em C nativas para substituí-los.

@simonferquel Ficará mais claro quando o código for refatorado e verificado. E pode ser necessário que alguns especialistas em iOS e Android liderem esses esforços.

Acho que mudar o namespace era uma abordagem razoável quando winui era uma coleção de controles. No entanto, agora que basicamente substitui a plataforma, acho que isso não se justifica mais. Isso já funciona da mesma maneira para WPF / Winforms, onde o código pode ser movido do .net Framework para .net core sem alterar os namespaces no código. A plataforma deve ser capaz de carregar automaticamente as versões winui das dlls necessárias quando ativada. Dessa forma, a compatibilidade de origem e binária (usei com êxito bibliotecas de estrutura .net em aplicativos centrais .net) pode ser preservada.

Só queria agradecer a todos pelos comentários até agora! A equipe WinUI está analisando cuidadosamente todas as respostas e pontos.
Provavelmente também separaremos alguns problemas específicos para falar sobre pontos específicos que surgiram (por exemplo, compatibilidade com estruturas e componentes UWP existentes), uma vez que organizamos nossas ideias.

Só quero agradecer à MS por ouvir mais e dar aos desenvolvedores .net ferramentas incríveis, mas não posso deixar de me sentir desapontado com o futuro do UWP Xaml após a conferência de construção.
Lendo este blog e muitos artigos na rede, você tem a sensação de que o UWP está se tornando exclusivamente “corporativo” e até mesmo isso é discutível, pois muitas empresas estão se tornando mais agnósticas quanto ao sistema operacional, permitindo que os funcionários usem, por exemplo, MacBook Pro.

Deixe-me ser claro que estou investindo pesadamente em UWP nativos e Xamarin Forms (Android, iOS) e adoro a plataforma, mas depois que a MS anunciar o suporte nativo para React, estou prestes a abandonar o barco.

Sei que devo tornar meu aplicativo UWP mais independente de plataforma na área de trabalho, pois esperava poder criar um "aplicativo híbrido" com meu aplicativo uwp atual como o shell e incorporar mais e mais tecnologias de front-end da web usando React na mistura . Algo como o recurso “Conjuntos” proposto que eu entendo agora está atrasado por causa de prioridades mais altas dentro do Edge, teria sido ideal para minha solução atual, pois confunde totalmente as linhas entre UWP nativas e tecnologias da web ao executar a tecnologia nativa e da web em “Janelas / guias de borda”. Essa abordagem “híbrida” me permitirá abraçar lentamente a tecnologia da web em minha plataforma atual, mas também dá aos “aplicativos nativos” uma guia no “navegador”, por assim dizer. (da perspectiva do consumidor) Isso também me fornece uma saída de emergência se “aplicativos uwp nativos” falharem a longo prazo no desktop.

A razão para pensar acima é que a UWP não me fornece uma saída de emergência, pois pode facilmente se tornar a próxima vítima do Silverlight se não houver capacidade para várias plataformas em breve. A MS está protegendo suas apostas, certificando-se de que eles não percam a tendência do PWA ou que sua mão esteja se voltando para o suporte nativo React no Windows. O problema é que apostei na esperança de que, a essa altura, houvesse um “caminho” para UWP / c # / .net no navegador ou plataforma cruzada e que eu pudesse reutilizar a maior parte do meu investimento nessas plataformas.

Lembro-me de que quando todos os desenvolvedores gritavam compre Xamarin, demorou uma eternidade para a MS fazer isso. Acho que a maioria dos desenvolvedores familiarizados com o web assembly sabe que recentemente eles conseguiram executar uma “versão completa” do Windows Server em web assembly dirão para comprar a plataforma Uno e torná-la enorme com um investimento significativo. Se um sistema operacional completo pode ser executado em Web assembly, a MS deve fornecer a cada desenvolvedor .net um caminho de migração para a capacidade de plataforma cruzada para proteger seus investimentos existentes.

Você pode dizer que o Blazor está lá, mas francamente, antes de investir mais tempo em uma nova plataforma, prefiro aprender React ou você pode dizer que nós MS temos recursos limitados para tudo isso. Certamente, quando você paga $ 7,5 bilhões pelo Github, tudo se torna relativo.

Eu acho que é fundamental que a MS entenda o dano à reputação de um caminho de migração com falha para o recurso de plataforma cruzada para investimentos UWP / Win32 existentes. O recurso de plataforma cruzada deve ser sinônimo de .NET 5 e não é. Não tenho certeza se passos pequenos para plataforma cruzada neste caso vão funcionar para MS e acredite, sempre fui um grande fã de xaml / .net / c #

Quais modelos seriam mais interessantes para você?

Você quer dizer modelos de projeto ou modelos de item também?

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

Seria apenas uma pesquisa e substituição (menos valor) ou também incorporaria dependências de atualização para a nova versão (mais valioso, mas não tenho certeza de como você poderia saber)

Re: compatibilidade com versões anteriores para novos recursos

A compatibilidade retroativa com a Atualização de criadores (15063) será um ponto de referência fixo ou o plano daqui para frente será oferecer suporte à versão atual e ao número X de versões anteriores a ela?

O que isso significará para quem está criando uma extensão ou próprio controle ou funcionalidade que deseja compartilhar publicamente? Eles precisarão oferecer suporte a esse nível de compatibilidade com versões anteriores também? Mesmo para o Windows 8.1?

Re: Migração de namespaces

Será possível migrar uma UWP existente em etapas (estou pensando nas páginas) ou será necessário atualizar o aplicativo inteiro de uma vez? Se for o aplicativo inteiro de uma vez, isso tornará a adoção mais lenta.

E sobre a migração de aplicativos WPF? - A estratégia de migração é usar ilhas XAML que podem usar WinUI 2.x ou 3.x? Ambos podem ser usados ​​no mesmo aplicativo?

Sim, dividir esse problema em vários outros mais focados ajudará a capturar ideias com mais clareza e evitar tangentes.

Substitua todas as instâncias de UWP pelos nomes apropriados, pois não está claro a que você está se referindo.

@mrlacey :

Você quer dizer modelos de projeto ou modelos de item também?

Os modelos de item ou biblioteca também são interessantes! Existem alguns pontos importantes nas respostas até agora sobre o fornecimento de código padrão e inicial, que é outra coisa que poderíamos considerar adicionar ao longo do tempo, talvez como o Windows Template Studio .

Seria apenas uma pesquisa e substituição (menos valor) ou também incorporaria dependências de atualização para a nova versão (mais valioso, mas não tenho certeza de como você poderia saber)

Boa pergunta - que tipo de atualizações de dependência o tornaria mais valioso? por exemplo, encontrar novas versões de pacote NuGet compatíveis?

A compatibilidade retroativa com a Atualização de criadores (15063) será um ponto de referência fixo ou o plano daqui para frente será oferecer suporte à versão atual e ao número X de versões anteriores a ela?

Prevemos que o intervalo de versões de suporte muda ao longo do tempo com base no uso. Em vez de ficarmos restritos a um número específico de versões, provavelmente continuaremos a olhar para os dados de uso e oferecer suporte às versões mais ativas do Windows 10 no mercado.

O que isso significará para quem está criando uma extensão ou próprio controle ou funcionalidade que deseja compartilhar publicamente? Eles precisarão oferecer suporte a esse nível de compatibilidade com versões anteriores também? Mesmo para o Windows 8.1?

Atualmente, não prevemos a imposição de quaisquer requisitos adicionais ou "certificação" para controles personalizados. O controle de versão seria com você. A história geral do controle de versão na atualização de maio de 2019, WinUI 3.0 e futuras versões do WinUI é definitivamente um tópico que queremos aprofundar em breve.

Será possível migrar uma UWP existente em etapas (estou pensando nas páginas) ou será necessário atualizar o aplicativo inteiro de uma vez? Se for o aplicativo inteiro de uma vez, isso tornará a adoção mais lenta.

Ótima pergunta - obrigado por notar isso. Este também é um tópico que queremos aprofundar em breve.

Substitua todas as instâncias de UWP pelos nomes apropriados, pois não está claro a que você está se referindo.

@riverar : existe um uso ou seção específica que não está claro?

Usamos o termo " UWP Xaml " para nos referir à plataforma Xaml fornecida como parte do Windows 10 e do UWP SDK, para diferenciá-la de outras plataformas baseadas em Xaml (por exemplo, WPF).

Também nos referimos ao " modelo de aplicativo UWP " (empacotamento e instalação, gerenciamento de dados e estado, ciclo de vida do tempo de execução, etc.), como distinto de um modelo de aplicativo Win32.

Mesmo em desktops Windows, os usuários passam muito tempo navegando na web.
Acho que precisamos de uma maneira de desenvolver aplicativos da Web decentes, usando o (subconjunto do) UWP vNext XAML + .NET (C # / F # / VB.NET)

Desenvolvi em WPF + ClickOnce por muitos anos, depois comecei a olhar para UWP. Eu gosto de UWP, mas ele (ou a próxima versão) precisa ser capaz de executar EXE autônomo, APIs de janela melhores (permite criar um aplicativo personalizado de estilo Winamp Window se quisermos), mais APIs de impressão, interoperabilidade fácil com C dll , OCX, pelo menos um subconjunto dos componentes deve ser executado na web.

Quando vi o UNO, pensei: a Microsoft poderia comprar essa empresa e juntar esses desenvolvedores às equipes da UWP e do Xamarin. Eu ficaria feliz se a próxima versão UWP se tornasse uma coisa do Azure, que roda na Web, Windows, Mobile e IoT. IMO até o portal do Azure pode ser escrito em UWP vNext.

A Microsoft pode fazer isso. Você fez isso com Silverlight, você fez WPF, você fez UWP, você fez Xamarin. Agora é a hora da estrutura GUI XAML definitiva. E, na minha opinião, a Web deve ser suportada, pelo menos um subconjunto da funcionalidade.

_INotifyDataErrorInfo_

Não introduza novos namespaces para coisas como _INotifyDataErrorInfo_ - ele deve ser usado em modelos de visualização que geralmente são multiplataforma e não devem depender do WinUI. Deve ser definido onde outras coisas como esta estão localizadas (ou seja, _INotifyPropertyChanged_ ou _INotifyCollectionChanged) _

Sobre este tópico. Windows.UI.Xaml.Interop já tem uma interface INotifyCollectionChanged e Windows.UI.Xaml.Data tem INotifyPropertyChanged. Esses dois serão movidos para namespaces da Microsoft. Talvez os assemblies System.Runtime.WindowsRuntime possam fazer algum mapeamento de WinUI para .Net

Minha única coisa que quero acrescentar, se ainda não tiver sido adicionado, é que apoio 100% o modelo de pacote MSIX / Appx e o Win10 fez um trabalho fantástico de consertar a merda que foi instalada e removida durante a vida útil do Windows. No entanto, sempre tive dificuldade em construir um aplicativo "UWP" por causa do subconjunto estranho de opções de API disponíveis que foram feitas na caixa de proteção AppContainer. Como desenvolvedor C ++, isso era frustrante e, a cada ano, ver você abrir ainda mais a sandbox para permitir o conjunto completo de APIs do Win32 tem sido um alívio.

Portanto, se o WinUI 3.0 permitir que eu crie um aplicativo com acesso a 100% da pilha do Win32, será ótimo! Eu tentei usar XamlIslands agora, e é uma saída de emergência fantástica, mas tem sido instável para mim e ainda resta algum trabalho antes de realmente cruzar a linha de chegada.

Obtendo modelos de projeto que me permitem construir um aplicativo Win32, sem ser colocado dentro de um processo AppContainer, e me permitem acessar todos os avanços que você fez com a IU, o WinUI 3 será um ajuste perfeito para mim.

@ eklipse2k8 Ainda precisa haver um sistema de permissão para acessar os arquivos e dispositivos de um usuário, mesmo em uma sandbox descontraída. Além disso, acho que deve haver regras para manter o userland e evitar a elevação ao acesso de administrador e kernal - sem algum tipo de teste oficial e requisitos de assinatura de código.

Olá Microsoft,

Eu não sei o quanto esta postagem irá influenciar o tópico Font Rendering , ClearType , DirectWrite e o futuro da IU do Windows, mas eu sou um dos poucos pequenos, mas vocais e apaixonados que têm sérias queixas com os subsistemas de renderização de fontes em Janelas.

Está bem documentado em quase todas as frustrações (ou satisfação) amam a suavização de fontes e outras que absolutamente odeiam isso.

Não estou aqui para discutir se um é melhor do que o outro. Nem estou aqui para discutir hacks de registro, 'sintonizadores de fonte' ou como posso ajustar as configurações do sistema operacional para fazer as fontes parecerem melhores. Acredite em mim, eu fiz tudo; até mesmo indo ao ponto de fazer pesquisas para escrever um driver de modo kernel para corrigir funções DirectWrite no modo kernel.

Estou aqui porque tenho uma condição médica óptica muito comum chamada miopia / miopia . Posso ver as coisas claramente de perto. Mas apenas à distância de um braço, minha visão está bem no limite da minha acuidade visual e onde o texto começa a ficar borrado.

Além da distância dos braços, preciso usar lentes corretivas. : óculos: Tenho certeza de que estamos todos cientes, as telas dos computadores desktop estão a uma distância de aproximadamente um braço. Daí o problema.

• Fontes que parecem suaves, parecem borradas para mim.
• Fontes com bordas nítidas (ajustadas ao pixel) parecem mais claras para mim.

Quando as fontes são ajustadas para pixels, as bordas nítidas são um sinal visual para meu cérebro de que minha visão está clara e em foco . No entanto, quando encontro um texto suave, aquele sinal visual engana meu cérebro, fazendo-o pensar que

Como colega desenvolvedor que passa longos períodos escrevendo código e olhando texto, é frustrante e dói como o inferno. Este é o principal motivo pelo qual ainda estou executando o Windows 7 e não o Windows 10 . Quase toda a UI Metro principal do Windows 10 está usando suavização de fonte em todos os lugares.

Para ilustrar esse problema de suavização de fonte, vamos dar uma olhada no snap-in services.msc MMC no Windows 7 :

Você vê algum texto borrado que parece fora de foco? Aqui. Vamos aproximar um pouco mais ...

Meu Deus, que bom, parece que estou olhando para um texto estrábico em um estereograma .

Acontece que, neste caso específico, vasculhando a hierarquia de controle desta janela, o snap-in MMC hospeda um controle DHTML / ActiveX do Internet Explorer que está renderizando um texto difuso no painel "selecione um item para visualizar sua descrição". O menu "Ajuda" e a lista de serviços nítidos (ajustados ao pixel) são processados ​​com os primitivos USER32 e GDI32 normais.

Este pequeno exemplo destaca um dos maiores problemas com a renderização de fontes no Windows. Acontece que o IE8 respeitará a configuração global do sistema operacional que desativa ClearType e suavização de fonte. No entanto, se você instalar o IE9 ou superior, o IE9 + felizmente ignorará todos e quaisquer esforços para desativar a suavização de fonte. O IE9 + simplesmente não se importa e força todos os usuários a visualizar o texto em sites (e em controles ActiveX) com texto suavizado por fonte.

O problema fica pior para usuários como eu porque, com o passar do tempo, o nascimento do Windows 8 e do Windows 10, Metro Apps, WPF e UWP adotaram a mesma abordagem do IE9 +. Todas essas tecnologias de IU sob o capô ignoram as configurações globais do sistema operacional que devem ser respeitadas em nossas máquinas. Se desabilitarmos o ClearType e a suavização de fonte em um nível de sistema operacional, esperamos que as APIs ClearType e DirectWrite (e, conseqüentemente, os aplicativos Metro, WPF e UWP) não sejam desenhados com nenhuma suavização de fonte.

Eu sei que não sou o único com esse problema.

Um tempo atrás, o Google Chrome fez a mesma coisa com seu lançamento v31 e tentou seguir a abordagem do IE9 + e mudou toda a renderização de fontes para DirectWrite, ignorando as configurações globais do sistema. Essa mudança colocou a Internet em fúria. Consulte o problema 319429 do Chromium . Finalmente, depois de muito ranger de dentes, o Google reverteu o curso e corrigiu o problema no Chrome 37 para os usuários com deficiência visual míope e agora respeita a configuração de todo o sistema operacional que desativa a suavização de fonte.

Graças aos poderes constituídos e às forças do mercado, a Microsoft perdeu a guerra dos navegadores e agora está adotando o mecanismo de renderização Chromium, mas prendo o fôlego que a equipe do Edge respeitará as configurações de suavização de fonte desativadas.

Estou aqui apenas para defender que a Microsoft precisa de uma configuração global que precisa ser respeitada , para todos os aplicativos no sistema operacional, em todas as pilhas de IU , para aqueles com problemas de acuidade visual.

E como um lembrete amigável, este é um problema de acessibilidade para a IU do Windows em geral, não de preferência visual.

Com base na prevalência mundial de miopia, pode-se estimar que mais de 22% da população mundial atual, ou seja, 1,5 bilhão de pessoas são míopes. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Obrigado,
Brian

: walking_man:: walking_woman: Pessoas Desaparecidas - Andando em LA

Isso significa que o framework Xaml completo seria desenvolvido no GitHub e lançado fora da banda como pacotes NuGet .

NuGet é ótimo, mas o suporte a vcpkg (e CMake ) também seria apreciado (para aqueles de nós com grandes bibliotecas de plataforma cruzada existentes).

Quais modelos seriam mais interessantes para você?

Em ordem de preferência:
Win32 + Xaml Desktop + WinUI
Win32 + Ilhas Xaml + WinUI
UWP + WinUI

Você conhecia as Ilhas Xaml para modernizar aplicativos de desktop?Essa compatibilidade com versões anteriores expandida no Windows 10 torna as Ilhas Xaml mais úteis para você?

Sim, as ilhas Xaml são interessantes, mas como visamos consumidores, e não clientes corporativos, a compatibilidade expandida com versões anteriores não é um obstáculo - a maioria dos clientes fica razoavelmente feliz em atualizar seu sistema operacional (e com prazos para implementar mudanças com base no novo WinUI Xaml, tê-lo bloqueado até 1903 provavelmente significaria que já foi lançado há um ano).

O namespace raiz para Xaml, composição e APIs de entrada no WinUI será diferente do namespace raiz do SDK UWP do Windows:

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

Isso não me afeta, já que não temos um aplicativo UWP (atualmente usamos WPF para vendas diretas e WPF + Desktop Bridge para a loja), mas alterar namespaces é uma coisa única e mesmo nas maiores bases de código, uma localização global e substituição de Windows::UI::Xaml não é tão assustador (todos nós estamos usando o controle de versão certo ..?).

O caminho mais rápido para o lançamento do WinUI 3.0 seria não oferecer suporte à mixagem:

Por mim, tudo bem, eles devem ser tratados como bibliotecas incompatíveis separadas. Você pode direcionar UWP Xaml ou WinUI Xaml. Conforme mencionado acima, a conversão única não deve ser tão difícil.

No entanto, uma de nossas maiores preocupações são os problemas de compatibilidade e o trabalho que podem ser criados para aplicativos UWP e bibliotecas de componentes existentes, principalmente se você estiver criando ou consumindo bibliotecas de controle UWP Xaml.
Por exemplo, as versões existentes do Windows Community Toolkit não seriam utilizáveis ​​em aplicativos WinUI 3.0, portanto, o Toolkit e quaisquer aplicativos que o usassem precisariam ser atualizados antes de usar o WinUI 3.0.

A Microsoft precisa escolher uma tecnologia e mantê-la. Por anos, prometemos as melhores e mais recentes estruturas de IU para desktop (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml e agora WinUI Xaml). Embora a escolha seja ótima, ela leva a uma fragmentação da funcionalidade e do conhecimento do desenvolvedor. É muito mais fácil ter uma sessão / uma página da web / uma resposta stackoverflow sobre a implementação de um recurso no Windows, em vez de 7 diferentes dependendo da tecnologia. Se WinUI Xaml for o futuro, o Community Toolkit precisa ser atualizado para aproveitá-lo.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Tenho evitado fazer qualquer coisa com o UWP Xaml porque a funcionalidade simplesmente não existe (em comparação com o Win32 / WPF) e suponho que não estou sozinho nesse aspecto. Como tal, a compatibilidade total não é um problema.

Você cria ou usa bibliotecas de controle UWP Xaml ou componentes WinRT que não podem ser facilmente recompilados e atualizados junto com o código do aplicativo?

Não.

Qual seria sua solução preferida para usar componentes UWP Xaml com WinUI 3?

N / D

1. O que você acha do plano geral 3.0 delineado acima e no roteiro ? Isso permitiria que você usasse o WinUI para seus aplicativos do Windows novos e existentes?

Não há menção de Xaml Desktop no roteiro. Isso está sob a alçada do WinUI?
Já mencionei isso para o pessoal da // Build /, mas o motivo para não adotar o UWP Xaml antes é que era impossível fazer um aplicativo que usasse bibliotecas C ++ existentes. Por exemplo, quando um usuário escolhe um arquivo com FileOpenPicker , o resultado é entregue como um IStorageFile e não há maneira de passar isso para uma biblioteca de terceiros existente para abrir (por exemplo, libpng , libjpeg , etc). É por isso que tivemos que ficar com o WPF, então se Xaml Desktop ou Win32 + Xaml Islands nos permite viver sem essas restrições, então sim, nos permitiria usar WinUI para um novo aplicativo.

1. Para que tipo de aplicativo você gostaria de usar o WinUI 3.0? Criando um novo aplicativo Win32 e empacotando-o com o MSIX ? Adicionando novas visualizações a um aplicativo WPF? Modernizando um aplicativo C ++ MFC com Fluent UI?

Criação de um novo aplicativo Win32 com WinUI (e empacotamento com MSIX).

Se você tiver alguma dúvida, entre em contato. Terei prazer em discutir mais detalhes.

Na verdade, esperando que haja uma maneira de chamar Compact Overlay de WPF / WinForms.
Precisamos apenas de um sistema de permissão de administrador como "permissão para desenhar sobre outros aplicativos" no Android.

Espero que este modelo de aplicativo + embalagem (UWP + AppX, Win32 + MSIX) permita isso (Abstração total dentro do Sandbox)

O Windows não deve ser as possibilidades mais avançadas e ilimitadas, com a melhor segurança?
Não por recurso inválido para segurança.

Obrigado por se abrir para a comunidade para comentários sobre o roteiro.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Indo direto ao ponto, temos vários aplicativos UWP em uso para clientes corporativos no momento e espero que o caminho de migração não seja tão difícil. Se houver mudanças significativas, seria muito bom ter uma ferramenta de migração semelhante a .Net Framework a .Net Core que gera a compatibilidade de nosso caminho de migração, isso deve relatar qualquer coisa que possa precisar de alteração ( por exemplo, APIs que podem estar obsoletas ou se comportar de maneira diferente) e uma opção para alterar automaticamente o namespace, se possível. Dessa forma, o caminho de migração de UWP para WInUI não será tão volátil para nós, desenvolvedores corporativos.

Você conhecia as Ilhas Xaml para modernizar aplicativos de desktop?
Essa compatibilidade com versões anteriores expandida no Windows 10 torna as Ilhas Xaml mais úteis para você?

Sim, mas não foi um grande problema, pois, no futuro, todos os nossos aplicativos de desktop recém-desenvolvidos estão usando comunicação UWP por meio de um back-end de API, e a maioria de nossos clientes já está executando o Windows10.

O que você acha do plano geral 3.0 delineado acima e no roteiro? Isso permitiria que você usasse o WinUI para seus aplicativos do Windows novos e existentes?

A equipe de desktop já está animada com as novidades do WinUI 3, mas, como dito acima, teme a migração de todos os nossos aplicativos UWP para ele se o caminho não for tão fácil.

Quanto ao XAML geral, uma vez que toda a estrutura de interface do usuário XAML viverá desacoplada do Windows, conforme outros expressaram, de modo que seja possível trocar os renderizadores. Isso abrirá a possibilidade de executar WinUI XAML em outras plataformas, o que é um grande fator de definição hoje em dia, quando as pessoas escolhem uma pilha para seguir, como evidenciado com a popularidade dos frameworks Electron e JS tirando vantagem disso para pequenas empresas que não têm a mão de obra para desenvolver bases de código nativas especificamente para cada plataforma.

Além disso, adicione que com WinUI 3 em diante também deve melhorar o dialeto XAML, talvez introduzir um namespace / Doctype de versão para especificar qual versão de XAML está sendo usada para manter a compatibilidade com versões anteriores para aplicativos mais antigos. Há muito a ser feito para tornar o XAML menos prolixo ou fragmentado, como ter que escrever INotifyPropertyChanged com setters privados de apoio para um em vez de ser apenas um atributo de propriedade simples, dizer NotifyPropertyChangedAttribute e deixar o A etapa de compilação injeta a implementação para evitar sobrecarga de tempo de execução ou DependencyProperties para controles personalizados para simplificar a criação de componentes. Talvez também leve algumas das melhorias na equipe do Razor para algumas das partes boas que eles têm.

Essas solicitações podem ou não ser viáveis, mas eu adoro o XAML e adoraria que ele continuasse a melhorar, então vou expor alguns dos pontos problemáticos (mas ainda úteis) que eu e alguns de nossa equipe tivemos ao desenvolver para eles.

@mdtauk Não me oponho à segurança de arquivos, mas o kernel subjacente deve impedir que você escreva em lugares aos quais não está autorizado, em vez de usar um novo conjunto de APIs e abandonar a API de arquivos win32. Além disso, sei que isso está saindo do assunto, mas a API StorageFile / StorageFolder são substituições horríveis, nem mesmo levando em conta a segurança de arquivos. Eles são lentos e você sempre está em proxy por meio do intermediário de arquivo de tempo de execução. Além disso, nunca deveria ser uma restrição que os aplicativos em sandbox precisassem de permissão especial aprovada pela MS para gravar na pasta de documentos do usuário. Por exemplo, quão péssima era a história do arquivo para o esforço do AppContainer, era impossível criar um banco de dados sqlite em qualquer lugar, exceto na pasta LocalData oculta do usuário. Para um sistema de desktop em que os usuários desejam criar, salvar e abrir arquivos e salvá-los como, yadda yadda, isso sobrecarregou os desenvolvedores de software com a necessidade de treinar novamente seus usuários sobre como gerenciar o conteúdo dos usuários.

Quanto ao acesso de administrador, a versão de outubro de 2018 adicionou "allowElevation" como um direito, o que faz sentido. Um aplicativo pode permitir que um usuário execute como administrador se precisar desse amplo acesso de nível de sistema para algum conjunto de recursos. Não estamos todos construindo pequenos editores de fotos e aplicativos de fluxogramas fofos.

@MarkIngramUK Obrigado por seus comentários, apenas um esclarecimento. O conceito do Xaml Desktop que foi apresentado em um Sneak Peek em // Build 2019 foi renomeado para WinUI Desktop. Este novo projeto do Visual Studio usará um modelo de aplicativo Win32, com WinUI como estrutura de apresentação, e pode ser nativo ou gerenciado (usando .NET Core 3).

Obrigado @ marb2000 - isso está dentro do prazo do WinUI 3.0?

@ marb2000 por WinUI Desktop, você quer dizer aplicativos Win32 com ilhas Xaml? Em qual sessão de compilação isso foi mostrado?

Uma coisa que a equipe WinUI deve tomar cuidado com a renomeação do WinUI 3.0: se você renomear qualquer um dos tipos projetados em .NET, as projeções não funcionarão (e não estamos planejando adicionar mais, já que não é um sistema extensível sustentável). Aqui está uma lista dos tipos que projetamos: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Quaisquer alterações em tipos diferentes desses tipos exigirão que os usuários envolvam seus objetos em novos objetos que implementam as novas interfaces ou copiem seus dados para os novos tipos. Em particular, os tipos INotifyPropertyChanged e INotifyCollectionChanged são de interesse em relação às ilhas XAML e fornecem suporte downstream.

INotifyDataErrorInfo

Não introduza novos namespaces para coisas como INotifyDataErrorInfo - ele deve ser usado em modelos de visualização que geralmente são multiplataforma e não devem depender do WinUI. Deve ser definido onde outras coisas como esta estão localizadas (ou seja, INotifyPropertyChanged ou INotifyCollectionChanged)

Sobre este tópico. Windows.UI.Xaml.Interop já tem uma interface INotifyCollectionChanged e Windows.UI.Xaml.Data tem INotifyPropertyChanged. Esses dois serão movidos para namespaces da Microsoft. Talvez os assemblies System.Runtime.WindowsRuntime possam fazer algum mapeamento de WinUI para .Net

Obrigado pela resposta, mas por que você precisa dele no namespace da Microsoft se o .NET Standard já o tem em System.ComponentModel? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@ meir-pletinsky. NET é apenas uma estrutura que você pode usar para fazer aplicativos com UWP XAML. Eles querem validação de campo de texto disponível para Devs, não importa qual estrutura eles usam

@mdtauk , não, WinUI Desktop (anteriormente Xaml Desktop) permite que você use Xaml com Win32 diretamente, sem o uso da ilha.

@ marb2000 Seria ótimo se o Application Packaging Project permitisse que você construísse um AppX com uma janela Win32 e incluísse componentes WinRT da mesma maneira fácil que um projeto UWP faz. Há muitas coisas que não funcionam sem editar manualmente os arquivos vcxproj, como adicionar recursos e o compilador cppwinrt gerando os cabeçalhos dos componentes WinRT incluídos.

Outro projeto importante para esta nova IU é o _PropertyChanged.Fody_ de Simon Cropp que permite a implementação automática do INotifyPropertyChanged (tentei com C # / F #). Veja https://github.com/Fody/PropertyChanged

Ele permite um código simples como este:

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

que podemos usar para vincular à interface do usuário.

Uma coisa que eu gostaria de ver no WinUI 3.0: atualmente, o compilador UWP XAML ( genxbf.dll ) só pode ser chamado diretamente pelo MSBuild quando referenciado a partir de um arquivo csproj, vbproj ou vcxproj. Isso ocorre porque não existe uma ferramenta de linha de comando que possa ser usada para invocar essa funcionalidade. Isso me parece uma decisão muito estranha, já que nada mais no download do SDK do Windows 10 requer Visual Studio. (O complemento WDK também inclui destinos do Visual Studio, mas todos esses destinos invocam ferramentas de linha de comando que podem ser usadas independentemente do VS.) Eu apreciaria muito a adição de, por exemplo, XbfCompiler.exe e XbfCodeGen.exe para o diretório bin do SDK. (O ex EXE compilaria arquivos XAML para arquivos XBF, e o último geraria os arquivos code-behind que são necessários para fazer referência a tipos XAML do código.) Isso seria útil principalmente em projetos C ++ que usam CMake ou outro não visual Ferramenta de compilação do Studio, mas também pode ser usada para projetos C # e VB.NET, se necessário. Obrigado!

@MarkIngramUK por acaso você sabe onde eu poderia aprender mais sobre o WinUI Desktop. Essas sessões Build 2019 não estão disponíveis para assistir online. Parece uma informação importante que deve ser vinculada neste repo

@mdtauk Foi mencionado no chamado Sneak Peek, que é apenas para participantes do Build. Afaik não há gravação. Eu também não estava lá, mas há um slide - talvez o melhor slide :-) - disponível no Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk O roteiro do WinUI 3 contém as informações e diagramas mais recentes, que estão ainda mais atualizados do que o mostrado na amostra do Build. Não existe "XAML Desktop" nem "WinUI Desktop" ... era apenas uma escolha confusa de palavras em um slide que foi fotografado. O conceito que está sendo comunicado (e o roteiro tenta explicar isso de forma mais clara) é que, para WinUI 3, estamos trabalhando para torná-lo para que você possa ter um modelo de projeto que crie um novo aplicativo de modelo Desktop / Win32 tradicional usando WinUI 3 para sua IU (assim como hoje existem modelos para estruturas de IU como WinForms, WPF, MFC, etc. além do modelo Desktop / Win32 tradicional), além de um modelo de projeto de aplicativo de modelo UWP / WinRT atualizado que usa WinUI 3. Isso ajuda a esclarecer?

O roteiro 3.0 parece bastante razoável para a seguinte estratégia: permitir que qualquer aplicativo cliente do Windows use XAML e os controles WinUI "modernos".

No entanto, essa estratégia parece míope se considerarmos a realidade do mercado atual: para muitos desenvolvimentos de aplicativos, Android e iOS são os alvos principais, e o Windows é bom ter. Para o desenvolvedor .NET, o Xamarin oferece suporte decente para Android e iOS, mas o suporte para Windows é inferior. Portanto, para aplicativos móveis / desktop nativos, o Win UI 3.0 não faz nada para simplificar o desenvolvimento de plataforma cruzada para desenvolvedores .NET.

O que eu realmente gostaria de ver é um dialeto XAML avançado com aspirações verdadeiramente universais. Devo ser capaz de escrever um aplicativo .NET usando XAML e executar esse aplicativo no Windows, iOS e Android. O aplicativo deve ser verdadeiramente de primeira classe em cada plataforma e ter acesso aos elementos nativos conforme necessário. Como mencionado, o Xamarin é um bom começo, mas seu dialeto de XAML é muito diferente, ele tem suporte insuficiente para o Windows e nada do trabalho que você está fazendo ajuda.

Então, tldr, é bom que você continue fornecendo uma plataforma de IU moderna para Windows. É bom que você esteja facilitando o uso em diferentes tipos de aplicativos. Ruim que você não aspira a suporte multiplataforma.

Opcionalmente, desative ou desative os comportamentos do ciclo de vida do aplicativo móvel legado, como suspender + marca para exclusão.

A realidade é que UWP é um ambiente de área de trabalho e, pelo menos para jogos, o usuário pode muitas vezes minimizar o aplicativo, o que geralmente leva à suspensão / exclusão do aplicativo. Esta é uma experiência chocante e muito diferente de qualquer aplicativo ou jogo win32 para desktop. Solicitar um adiamento estendido, que provavelmente ainda expirará, não é suficiente para lidar perfeitamente com isso.

Embora esse ciclo de vida seja útil para alguns aplicativos, é prejudicial para outros. Idealmente, um aplicativo ou jogo de desktop deve ser capaz de declarar um recurso que permite que o aplicativo cancele o modelo de ciclo de vida suspend + tombstone, o que evitaria que ele fosse eventualmente suspenso quando minimizado.

@natemonster

Por: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

Em dispositivos desktop, as sessões de execução estendida criadas com ExtendedExecutionReason.Unspecified têm um limite de tempo com bateria. Se o dispositivo estiver conectado à alimentação de parede, não haverá limite para a extensão do período de tempo de execução estendido. Se o dispositivo estiver usando a energia da bateria, o período de tempo de execução estendido pode chegar a dez minutos em segundo plano.

Um usuário de tablet ou laptop pode obter o mesmo comportamento de longa duração - às custas da vida útil da bateria - quando a opção Permitir que o aplicativo execute tarefas em segundo plano é selecionada em Uso da bateria pelas configurações do aplicativo.

@TonyHenrique quando você menciona Fody , é porque você deseja criar uma consciência sobre ele ou está dizendo que ele deve ser integrado ao WinUI?

Os modelos de item ou biblioteca também são interessantes! Existem alguns pontos importantes nas respostas até agora sobre o fornecimento de código padrão e inicial adicional, que é outra coisa que poderíamos considerar adicionar ao longo do tempo, talvez como o Windows Template Studio.

@Jesbis Sou um contribuidor central do Windows Template Studio e estou observando o roteiro do WinUI com uma visão do que faremos no futuro e de como apresentaremos suporte para WPF. ;)

que tipo de atualizações de dependência o tornaria mais valioso? por exemplo, encontrar novas versões de pacote NuGet compatíveis?

Ser capaz de detectar atualizações do NuGet seria mais útil, mas existem outros possíveis problemas de compatibilidade com a obtenção de atualizações. Eu tornaria a detecção de novas versões e a conversão automática uma prioridade baixa. São tantas as considerações que seria um grande projeto por si só e prefiro ver o tempo investido na plataforma de uma ferramenta como essa.

@mrlacey Mencionei Fody porque acho que é uma solução interessante e precisamos de uma maneira melhor de evitar o código clichê _INotifyPropertyChanged_. Seria bom ter uma solução com suporte da MS para esse conceito de objeto Reativo que gerasse automaticamente um evento quando alguma propriedade fosse alterada.
Funciona em classes C # e até em F # Records (mas teve algumas dificuldades).
Portanto, no roteiro do WinUI também deve haver isso.

Observação: seria bom se também pudéssemos usar os registros F # para definir nossas entidades de dados e vincular diretamente à IU XAML. Seria legal se pudéssemos usar F # Records + Fody + DataBinding sem problemas.

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

Isso seria mais familiar para pessoas que vêm do C #.
Outra abordagem seria a maneira Elmish. Eu acho que ambos são interessantes e poderiam ser apoiados.

@tonyhenrique / @mrlacey Acho que as coisas do Fody (OAP) deveriam estar fora do escopo. A equipe WinUI já tem o suficiente em seu prato, e eu acho que é melhor ter a tecelagem em projetos separados (ciclos de lançamento muito mais rápidos no caso de melhorias).

E eu acho que isso é na verdade um detalhe de implementação .NET (IL) dos modelos, não tem nada a ver com o WinUI (embora ele possa ouvir os eventos de mudança). Minha sugestão é mantê-los separados. Por exemplo, eu uso Catel e ele tem seus próprios tecelões Fody para garantir que tudo seja tecido corretamente.

O que eu realmente gostaria de ver é um dialeto XAML avançado com aspirações verdadeiramente universais. Devo ser capaz de escrever um aplicativo .NET usando XAML e executar esse aplicativo no Windows, iOS e Android. O aplicativo deve ser verdadeiramente de primeira classe em cada plataforma e ter acesso aos elementos nativos conforme necessário.

Há uma proposta antiga para ir nessa direção: UX de plataforma cruzada para .NET 5 - título original Cross platform UX for .NET Core 3.0 . O apoio esmagador da comunidade para isso é óbvio e podemos esperar que a MSFT perceba que esta é a melhor direção para desenvolver qualquer estrutura de interface do usuário que funcione em .NET. Praticamente não há razão para manter bases de código separadas para grupos de plataformas diferentes e criar forçosamente conjuntos de habilidades de desenvolvedor separados com base em diferentes estruturas de UX suportadas pelo .NET.

Ao criar uma UX única para todas as plataformas, cancelamos todas as ineficiências no desenvolvimento do framework e diminuímos as barreiras para a adoção do desenvolvedor.

@mfeingol / @ 4creators , eu aceitaria

O aplicativo deve ser verdadeiramente de primeira classe em cada plataforma

no Windows para começar ...

É 2019, quero uma IU nativa rápida e não quero ter que pensar seriamente em criar uma interface de usuário com CreateWindowExW , GDI, etc.

Agora que com o WinUI3.0 e superior o código está desacoplado do Windows 10, há planos no futuro para o WinUI funcionar no Linux e no Mac?

As interações do @jesbis Touch serão mantidas no WinUI 3.0?

Obrigado pelo esclarecimento, eu presumi que a forma como o 3.0 funcionaria seria incluir as ilhas Xaml no WinUI, em vez de usar o Community Toolkit.

Com ele se tornando XAML mais Win32, faz mais sentido, especialmente com o Windows Core OS reescrevendo seu shell em XAML.

Pelo que entendi agora, este rico acesso à API Win32 está em C e C ++ | com qualquer coisa em C # contando com .NET (tudo seja agora .NET Core).

Talvez devesse haver uma maneira segura e simples de acessar essas APIs Win32, bem como mais pontos de entrada para exibir uma IU de aplicativos?

• Flyout XAML da bandeja do sistema para aplicativos WinUI 3

• UIs de seletor simples para Hololens / Xbox / Surface Hub / IoT, etc.

• Caixas de diálogo de arquivos comuns personalizáveis ​​XAML atualizadas e seletores de pasta

• acesso C # .NET simples a APIs Win32

• configuração compacta para todos os elementos XAML, que correspondem ao tamanho do controle Win32 e WPF (isso ajudará os Frameworks a se encaixarem confortavelmente)

• combinar estilos de controle / fontes / pincéis de acento / acrílico ao usar WinUI

• definição clara de quais dispositivos requerem o ciclo de vida WinRT / Mobile

• Estilos de controle do Xbox Next integrados para desenvolvimento e teste de aplicativos do Xbox no Windows

• Armazenamento e pacote exe / MSI / APPX único e download com suporte por padrão, SEM INSTALADORES, virtualização do sistema de arquivos do tipo centenário por padrão

• WinForms WinUI 3.0 - UI simples, acesso apenas ao MFC, mouse e teclado

• WPF WinUI 3.0 - interface de usuário densa, renderização 3D, reconhecimento de DPI, toque simulado e suporte básico de tinta

• Xaml WinUI 3.0 - toque completo, MR, gamepad, tinta, voz, mouse, teclado. UIs densas e simples. Novo suporte de janelamento. Renderização MR 3D. Ciclo de vida gerenciado opcional ou ciclo de vida de desktop. O melhor de todos os mundos é o padrão para shell e aplicativos de caixa de entrada retrabalhados, com versões Win32 de aplicativos de caixa de entrada como bloco de notas, charmap, pintura, explorador de arquivos - código aberto e disponível na loja.

As interações de toque serão mantidas no WinUI 3.0?

@ r7dev sim, o plano é manter o mesmo nível de suporte de toque.

F # é ignorado no roteiro do WinUI 3.0. Microsoft ignorando um de seus produtos mais uma vez.

Considerações sobre a API Win32

Algo que também pensei é o motivo pelo qual o win32 também ficou por aí. Acho que há uma suposição de que isso se deve a projetos legados, mas na verdade é muito mais profundo do que isso. A ABI Win32 é super fácil de conectar com sua linguagem de escolha, nodejs, python, rust, go, ruby, c #, c ++, etc. etc. Se meu projeto principal está enferrujado, por exemplo, e eu quero gerar uma janela para gerenciar a saída, como um desenvolvedor de ferrugem, é super poderoso acessar o conjunto de API win32 e construir um front end na mesma linguagem.

No OS X, para acessar o AppKit, você só precisa criar uma ponte entre a API C objc_msgSend e obter acesso a toda a infraestrutura obj-c. Todas as linguagens acima fizeram um ótimo trabalho de ponte e facilitou a escrita no idioma de sua escolha e a produção de algo atraente.

Portanto, se você deseja que o WinUI 3.x seja o verdadeiro caminho a seguir para acessar a IU do Win32 de baixa latência, memória e alta qualidade, é necessário considerar a facilidade com que outros mantenedores de linguagem podem acessar a infraestrutura.

Consistência da IU

Se você realmente está planejando desacoplar a IU do sistema, qual é o plano para a IU permanecer consistente com cada atualização do sistema operacional? Quando a Apple faz ajustes nas sombras e gradientes no AppKit ou iOS, os aplicativos que dependem das estruturas do sistema herdam todos esses ajustes e permanecem consistentes. Também vai dificultar para você adicionar experiências de todo o sistema porque os aplicativos que estão bloqueados para infraestruturas de IU há 3 anos podem não funcionar bem com algum novo serviço do sistema, portanto, terão outra camada de compatibilidade com o passar do tempo.

Sempre haverá recursos que precisam ser ativados, posso pensar no Modo escuro como algo que, se o aplicativo não foi projetado para isso, realmente não faria sentido oferecê-lo como uma opção, mas ainda há ajustes nos componentes do sistema que mudariam com o tempo.

Tamanho Binário

Qual é a história planejada para entregar todos esses UI.dlls com nossos projetos? Essas coisas terão 40 MB de tempo de execução que precisam ser enviados com nossos projetos? O que acontecerá se um projeto for abandonado, eles começarão a parecer desatualizados porque usam estruturas de IU antigas?

Um dos benefícios do C ++ é que ele tem uma quantidade mínima de sobrecarga de biblioteca, dependendo da base de código. Certamente, se todos os aplicativos daqui em diante exigissem o WinUI 3.x, isso representaria 40 MB x número de aplicativos.

Tamanho Binário

O WinUI já é uma dependência, assim como o .NET. Já é uma biblioteca de todo o sistema. :)
Você não tem dlls duplicados e não os terá.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@ eklipse2k8

"Eu também pensei sobre o motivo pelo qual o win32 também permaneceu. Acho que há uma suposição de que isso se deve a projetos legados, mas na verdade é bem mais profundo do que isso. O Win32 ABI é muito fácil de conectar com sua linguagem de escolha , nodejs, python, rust, go, ruby, c #, c ++, etc. etc. Se meu projeto principal está enferrujado, por exemplo, e eu quero gerar uma janela para gerenciar a saída, como um desenvolvedor de ferrugem, é super poderoso para acesse o conjunto de API do win32 e crie um front-end no mesmo idioma. "

Este é um saco misto, embora implementar o suporte WinRT para uma nova linguagem seja um grande obstáculo a ser superado, uma vez que você fizer isso, você terminará com ligações digitadas geradas automaticamente para quaisquer novas APIs. Eu tenho trabalhado em um projeto Rust que une Win32 e WinRT recentemente (usando as APIs de composição em uma janela Win32), e as partes do Win32 definitivamente têm sido mais dolorosas no geral, embora eu tenha tido que contornar desajeitadamente o restante falta de suporte do Rust para alguns recursos do WinRT, como herança de classe. (Definitivamente, ajuda que usar o Composition dentro do Win32 agora seja possível, pois permite melhorar incrementalmente o suporte para esse recurso em vez de ter que lidar com todo o modelo do aplicativo de uma vez)

Provavelmente, o maior problema é que a documentação para detalhes de WinRT ABI de baixo nível é um pouco desorganizada, e há muito pouco conhecimento ou consciência deles no mundo / comunidade. No entanto, espero que esta situação melhore com o projeto xlang.

Em quais modelos você está mais interessado?

Atualmente, prefiro começar a partir de um projeto de aplicativo em branco (Windows universal). Também gosto de templates com framework pré-configurado, mas só quando quero experimentar algo rapidamente. Um modelo de "Menu principal" e um modelo MDI para UWP também seriam bons (já que esses modelos também existem para WinForms)

Você conhecia as Ilhas Xaml para modernizar aplicativos de desktop?
Essa compatibilidade expandida com versões anteriores no Windows 10 torna as Ilhas Xaml mais úteis para você

Sim, conheço a Ilha Xaml. Se eu puder, tentarei manter um aplicativo WPF puro ou UWP puro. Eu não estava em uma situação em que exigiria tal recurso.

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

Sim, com certeza se funciona de forma confiável! Estou surpreso com os muitos comentários que não apreciam um recurso tão bom. Além disso, esse recurso pode verificar se uma atualização para WinUI 3.0 é possível, adotar o código XAML, ajustar os namespaces e instalar os nugets WinUI necessários.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Eu esperaria alterar apenas os namespaces do controle para funcionar totalmente com o WinUI 3.0. Não quero investir muito tempo na atualização para WinUI 3.0

Você cria ou usa bibliotecas de controle UWP Xaml ou componentes WinRT que não podem ser facilmente recompilados e atualizados junto com o código do aplicativo?

Estou usando bibliotecas de controle UWP Xaml de terceiros (como o Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement). Acho que seria capaz de atualizar controles simples de bibliotecas de terceiros, como um Dockpanel sozinho, para o WinUI 3.0.

Qual seria sua solução preferida para usar componentes UWP Xaml com WinUI 3?

• Crie um modelo de projeto "Aplicativo em branco com WinUI 3.0" no Visual Studio para UWP. A dependência do WinUI 3.0 será instalada como nuget (como no WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . Eu absolutamente preferiria tal solução, desde que eu tenha todos os controles básicos. Eu esperaria que todas as classes do Windows.UI tivessem uma classe equivalente no namespace Microsoft.UI.

O tópico principal no WinUI 3.0 era sobre controles e compatibilidade do Windows 10 que podem ser usados ​​a partir de UWP e WPF ou WinForms via Ilha XAML, se estou correto. Há alguma chance de que a marcação UWP XAML obtenha recursos adicionais de alguma forma?

• Faltam gatilhos de estilo
• Estilo `BasedOn = {StaticResource {x: Type TextBlock}} ausente
• DataTemplates definidos com DataTypes não são aplicados automaticamente como no WPF (apenas por meio de chave)
• Por que cada segundo Windows.UI.Xaml.Controls control (TextBlock, Border, ...) é declarado como selado ?! Não faça isso no WinUI 3.0 com UWP.
• Extensões de marcação para paridade WPF
• Isso já foi mencionado, mas vou mencioná-lo mais uma vez. É triste que a UWP não use System.ComponentModel.IDataErrorInfo. Dessa forma, não posso compartilhar meu projeto de modelo com a solução UWP.
• ReportControl (para aplicativos empresariais)

Estou realmente ansioso para WinUI 3.0 e sua compatibilidade com versões anteriores!

F # é ignorado no roteiro do WinUI 3.0

Há alguma chance de que a marcação UWP XAML obtenha recursos adicionais de alguma forma?

@ Happypig375 , @ mfe-:

O roteiro cobre apenas a versão 3.0 inicial e, para a versão inicial, estamos focados principalmente na paridade e compatibilidade com versões anteriores para recursos existentes, com um pequeno número de novos recursos.

Se você acha que outros novos recursos, como melhor suporte a F # ou novos recursos de marcação, são importantes, abra uma nova solicitação de recurso para que possamos rastreá-los separadamente!

Por que cada segundo controle Windows.UI.Xaml.Controls (TextBlock, Border, ...) é declarado como lacrado ?! Não faça isso no WinUI 3.0 com UWP.

Os controles de desbloqueio são, na verdade, um dos poucos novos recursos que esperamos incluir no 3.0 😊

Quando se trata de idiomas, seria legal misturar e combinar (o que deve funcionar se tudo for compilado antes do empacotamento)

F # usado para alguma lógica de back-end - C # para ligação de dados e código de IU - C ++ para controles e talvez alguns ganchos Win32 de baixo custo ou até mesmo para iniciar uma caixa de diálogo WinForms.

Todas as linguagens de código são iguais, intercambiáveis, com WinUI 3.0 lidando com toda a IU

Isso é xlang 😉

Isso é xlang 😉

@MarkIngramUK Hmm, pensei que fosse uma ponte entre as linguagens, que abstrai cada linguagem, em vez de permitir arquivos de código de várias linguagens em um único projeto.

Eu meio que me esforcei para entender o propósito do xlang - encobrir as atualizações que estão acontecendo no repo (mas ainda tenho em minha lista de observação)

O xlang funciona antes ou depois da compilação? É sua própria linguagem abstrata que pode ser projetada ou fica apenas entre os arquivos de código existentes?

Sim, você não pode misturar idiomas em um único projeto. É uma ponte, mas ainda útil para esses fins.

@MarkIngramUK Eu acho que sim, se seu código pode ser compilado, então incluído.

Seria bom poder usar C # para acessar recursos nativos do Win32, sem PInvokes e outros truques .NET

@jesbis , honestamente, estou mais interessado nos aspectos de plataforma cruzada deste projeto ...

Acho que, no início, vocês deveriam renomear para algo mais _genérico_ e não estritamente para "Windows".

Entendi que a implementação inicial deve ser estritamente focada em aplicativos Win32 e UWP / Xamarin de volta e Windows, mas apenas OSS e torná-la desde o início chamada como uma estrutura "somente Windows", definitivamente não terá muita tração como UWP não o fizesse e os desenvolvedores de outras plataformas nunca teriam interesse nisso.

Se o alvo no .Net 5 for "Um .Net em todos os lugares", que é basicamente o que todos sempre esperaram desde .Net 1.0, as bases para a estrutura "Anything but Win UI" devem começar cruzadas.

Um bom exemplo de como consertar é o Google Flutter. Flutter está em seus primeiros dias, mas ganhou MUITA tração devido ao fato de que seu núcleo (também conhecido como Flutter Engine) é 100% cross-plat e funciona em qualquer lugar (incluindo IoT, Win, OSX e agora até na Web!).

Esse é apenas o meu 2c. Eu adoraria voltar a trabalhar no Xaml, mas se continuar na mesma linha que no UWP, temo que não obterá o impulso certo e será outra tentativa de reescrever o WPF que eventualmente precisará de outra tentativa em o futuro e assim por diante.

Por favor, não me enlouqueça e não tome meu comentário como uma crítica ruim. Só desejo que os esforços na interface do usuário no mundo .Net obtenham algo como Flutter, .Net Core 3.0 / .Net 5 e até mesmo Blazor.

Só para constar, eu comecei um projeto para reescrever / portar o mecanismo Flutter inteiramente em C # e .Net Core devido à falta de opções no .Net World ...

BTW, CoreUI é um bom nome ...

Parabéns a Jake Helfert por essa sugestão 😄

💃

BTW, CoreUI é um bom nome ...

Parabéns a Jake Helfert por essa sugestão 😄

💃

CoreUI pode ser confundido com .NET Core

O WinUI é muito focado no Windows, mas a estrutura XAML dentro dele poderia obter renderizadores para Metal (iOS e macOS) ou Vulkan (Android) - e FabricWeb poderia ser a maneira PWA / ChromeOS de lidar com outras plataformas.

Se a equipe decidir trazer a plataforma de apresentação, o Xland ou o Xamarin podem lidar com o tempo de execução para aplicativos de plataforma cruzada.

Sobre a migração da IU UWP da caixa de entrada para WinUI 3.0, citarei uma postagem recente do blog de @dotMorten (https://www.sharpgis.net/post/2019/05/14/The-future-UWP):

Nota divertida de fundo: o que está acontecendo com a UWP não é que ela esteja sendo morta: a Microsoft está girando para trazer as melhores partes para onde precisamos. Isso realmente aconteceu antes, mas infelizmente não foi usado como uma oportunidade para executar um pivô. Lembra do Silverlight? Adivinhe de onde veio o CLR de plataforma cruzada do .NET Core. E muito código do Silverlight também acabou em UWP. Eles tinham apenas girado e dito “Sim, concordamos que o Silverlight não faz sentido no sobressalente do consumidor, mas está prosperando no espaço corporativo, então vamos desenvolver isso e vamos evoluí-lo para .NET Core e Windows Store”. Infelizmente, isso não foi tão bom, e muitas pessoas ainda sofrem de PTSD e desconfiam de tudo o que a Microsoft faz que pareça estar acabando com qualquer tecnologia.

Eu realmente acho que é importante lembrar que ser percebido como eliminando ou redefinindo estruturas existentes sem dar aos desenvolvedores e bases de código um bom caminho a seguir não afeta apenas os desenvolvedores na estrutura existente - pode lançar uma nuvem sobre os esforços futuros enquanto todos se perguntam por que o coisa nova não terá apenas o mesmo destino. Isso não é uma observação sobre qualquer abordagem de migração proposta específica, mas sim uma resposta aos comentários de que a migração não importa porque poucas pessoas estão usando a estrutura de IU da caixa de entrada existente. Essa não é a única consideração!

@weitzhandler WinUI 3.0 é sobre combinar várias estruturas Win32, .NET Core e UWP com uma única estrutura XAML e interoperar com WPF, WinForms e MFC ++

O XAML no Windows é processado até Direct X.

Se você quiser pegar o mesmo XAML, combinado com o .NET Core, e fazê-lo funcionar em outras plataformas. Você precisaria escrever novos renderizadores para essas plataformas. iOS e macOS usam Metal como seu equivalente Direct X. Android usa Vulkan. Não tenho ideia de como o Linux lida com a renderização, eu acho que é apenas Open GL.

A Microsoft não vai querer fazer isso porque não faz sentido para eles. Mas o WinUI 3.0 será de código aberto - para que outros possam escolher tentar trazê-lo para várias plataformas

@mdtauk

Obrigado por esclarecer isso. Flutter é provavelmente o futuro para mim.

Isso é apenas meu entendimento, posso estar enganado.

O Flutter supostamente receberá suporte para Windows no futuro. E o suporte React Native está chegando ao Windows também. Além disso, existem PWAs se você investir nesse mundo HTML da Web e Javascript.

Para mim, toda a história do WinUI pode fazer mais sentido se eles também levarem em consideração a permissão de pelo menos um subconjunto básico de execução em plataforma cruzada (macOS, iOS, Android), incluindo Web, e também oferecer um suporte F # melhor e modelos de projeto (incluindo Vinculação de duas vias XAML para registros F # e também uma forma Elmish mais funcional)

O XAML precisa ser agnóstico em relação ao ambiente, assim como o HTML, sem tomar 100 MB + mesmo para os aplicativos de ferramentas mais básicos, como os aplicativos HTML fazem. Isso significa uma estrutura XAML escrita em C / C ++ ou C # puro e pode ser hospedada em WASM, Win32, UWP, iOS, Android, macOS, Linux etc. com o mínimo de esforço quando se trata de portabilidade. Você precisa de um back-end de renderização agnóstico como os motores de jogo usam para começar.

Nenhum, se este XAML focado em UWP estiver resolvendo quaisquer problemas que minha empresa ou eu tivemos durante anos com XAML ... e isso é portabilidade. TBH MS está tratando da interface do usuário completamente errado e não vai chegar a nenhum lugar rápido (está perdendo muito tempo valioso para muitas pessoas). Esse hackery UWP XAML simplesmente não parece bom para as pessoas a quem o mostro ... o que é triste, porque significa apenas um retrocesso sem fim contra a adoção de XAML e não tenho mais argumentos neste momento.

A única maneira de salvar XAML em minha opinião é:

• Crie uma nova base de estrutura agnóstica / portátil para .NET Core e C / C ++.
• Crie uma camada de abstração de renderização agnóstica que qualquer pessoa pode estender por meio de solicitações pull.
• Assim como o HTML, mantém o XAML focado em conceitos de aplicativo de janela única (assim como é feito em jogos também), MAS permite recursos de área de trabalho estendidos para várias janelas etc. (Isso permite que o aplicativo seja executado em quase qualquer contexto, assim como uma IU de jogos pode)

Simplificando, há duas condições que devem ser combinadas em uma antes que a adaptação XAML seja excluída.

1 MS precisa apoiar o projeto XAML ou as pessoas temem que ele caia.

2 Ele precisa ser multiplataforma ou todo mundo vai ficar preso a tempos de execução HTML excessivamente inchados.

De qualquer forma, são meus dois centavos e se o WinUI 3.0 for projetado da maneira certa, talvez a portabilidade seja possível. Neste ponto, pense no que sentir.

Há alguns comentários sobre ser multiplataforma aqui, e não tenho certeza de que o WinUI precisaria ser multiplataforma para ter sucesso. De qualquer forma, não funcionaria bem no Mac ou no Linux, pois é diferente o suficiente para não parecer nativo em nenhuma dessas plataformas. Este projeto é de propriedade de uma equipe que tem um grande conhecimento sobre como o funcionamento interno do Windows funciona, e seria uma distração para eles saírem e descobrir como fazer algo funcionar muito bem no Mac ou Linux no mesmo grau.

Além disso ... Fluent no Mac pareceria desajeitado, basta olhar para o iTunes, a Apple teve que portar todo o seu sistema de interface do usuário para o Windows, e definitivamente parece fora do lugar. A renderização de fontes é diferente, as curvas de animação, sombras e opções de cores parecem tão fora de lugar no Win10. Quer dizer, é bom e usável com certeza, mas eu prefiro o spotify, que não tenta emular nenhuma IU de desktop e apenas usa um navegador da web por baixo do capô. No Mac, ver o holofote da revelação com componentes quadrados em uma área de trabalho cheia de cantos arredondados e nenhum efeito de revelação seria tão difícil.

Não, eu acho que este projeto deve se concentrar em oferecer o melhor da classe para fazer software Windows nativo, para desenvolvedores que querem / precisam construir software Windows. Deixe as coisas de plataforma cruzada para as equipes de Electron / Typescript resolverem.

Há alguns comentários sobre ser multiplataforma aqui, e não tenho certeza de que o WinUI precisaria ser multiplataforma para ter sucesso. De qualquer forma, não funcionaria bem no Mac ou no Linux, pois é diferente o suficiente para não parecer nativo em nenhuma dessas plataformas. Este projeto é de propriedade de uma equipe que tem um grande conhecimento sobre como o funcionamento interno do Windows funciona, e seria uma distração para eles saírem e descobrir como fazer algo funcionar muito bem no Mac ou Linux no mesmo grau.
Além disso ... Fluent no Mac pareceria desajeitado, basta olhar para o iTunes, a Apple teve que portar todo o seu sistema de interface do usuário para o Windows, e definitivamente parece fora do lugar. A renderização de fontes é diferente, as curvas de animação, sombras e opções de cores parecem tão fora de lugar no Win10. Quer dizer, é bom e usável com certeza, mas eu prefiro o spotify, que não tenta emular nenhuma IU de desktop e apenas usa um navegador da web por baixo do capô. No Mac, ver o holofote da revelação com componentes quadrados em uma área de trabalho cheia de cantos arredondados e nenhum efeito de revelação seria tão difícil.
Não, eu acho que este projeto deve se concentrar em oferecer o melhor da classe para fazer software Windows nativo, para desenvolvedores que querem / precisam construir software Windows. Deixe as coisas de plataforma cruzada para as equipes de Electron / Typescript resolverem.

Não acho que alguém realmente queira um design totalmente Fluent em outras plataformas, mas sim ser capaz de maximizar o código comum entre as plataformas.

Isso é algo que já foi abordado pela equipe de Design da Microsoft. O site da Fluent diz explicitamente "projetar e construir aplicativos personalizados que são nativamente iOS, embora ainda sejam exclusivamente fluentes". Os documentos do Fluent mostram que o estilo de controle nativo deve ser usado.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

O que deve ser evitado é ter que projetar e manter interfaces de usuário completamente separadas para cada plataforma. Isso não significa que ele precisa parecer idêntico na superfície, mas deve compartilhar um layout comum, e os designers de IU devem ser capazes de reutilizar o máximo possível. O estilo real não precisa (e não deve) corresponder ao estilo do sistema Windows 10.

Em essência, o que se deseja é uma maneira fácil de fazer os aplicativos do Windows rodarem em outras plataformas, sem ter que refazer toda a IU - não para trazer o design Fluent para outras plataformas. Isso permitiria que as pessoas escrevessem primeiro para o Windows e, em seguida, levassem seus aplicativos para outras plataformas sem muito trabalho.

@KyleNanakdewa Bem, se eles estão fazendo o código aberto, deixe alguns fãs do Xaml criarem os bits de plataforma subjacentes. Eu acho que provavelmente é arquitetonicamente complexo o suficiente e tira proveito do Win32 o suficiente para que eu suspeite que a porta seria uma tarefa gigantesca.

Acho que este projeto deve se concentrar em oferecer o melhor da classe para fazer software Windows nativo

Esse argumento pode ser convincente se a Microsoft ainda não possuir um kit de ferramentas XAML de plataforma cruzada existente que por acaso oferece um dialeto de XAML muito diferente do WinUI.

Além disso, existem PWAs se você investir nesse mundo HTML da Web e Javascript.

Sim ... "aquele mundo" que está substituindo rapidamente tudo o que sabemos sobre desenvolvimento de SO / Store / Hosted nativo. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Considere que "aquele mundo" existe em _todos_ os dispositivos modernos com um renderizador HTML5:

• Apple com 1,4 bilhão
• Droid com 2,5 bilhões
• Windows 10 com 800 milhões

Você notará que o Windows agora tem a menor participação de mercado, o que significa que qualquer oferta que atenda especificamente a essa plataforma atingirá o menor mercado. Isso apenas reduz o alcance máximo de mercado potencial de um aplicativo, o que, por sua vez, reduz seu limite máximo de receita potencial.

Compare isso com o Flutter, que com _uma_ base de código atinge _todos_ os mercados mencionados acima, junto com a web , que, como mencionado, é composta de todos os três - maximizando, portanto, o alcance de mercado e as receitas potenciais para desenvolvedores de aplicativos enquanto reduz os custos necessários de construção aplicativos para fazê-lo.

Embora eu seja um grande fã dos esforços aqui para abrir o código, colaborar e solicitar feedback da comunidade , ainda não vi nada dessas discussões (das quais também gosto 😁) que me mostre com alguma confiança que os esforços aqui serão competitivo - e, portanto, _profissional_ - quando comparado com os gostos de Flutter (que aliás também está se preparando para PWAs ).

O controle do diagrama é essencial em qualquer experiência de desktop moderna baseada em dados que em breve será oficial do NET CORE 3 (setembro de 2019) e eventualmente. NET 5 (novembro de 2020)

Vejo o controle de código aberto Networkview fornecido como um caso de uso eficaz sobre como trabalhar com o Xaml para portar o WPF para o controle da IU do Win. Esta IU do Win portada servirá como uma boa guilda para outros portarem outros controles WPF um pouco mais complexos para a IU do Win.

Vemos o caso de uso 2 em 1 em que nosso aplicativo precisa oferecer suporte ao modo tablet no futuro sistema operacional Windows Core. Suspeitamos que o Winform no .net Core 3 não ajudará .. outra forte justificativa porque o controle do diagrama Win UI NÃO é apenas um exercício de PoC, MAS deve ser parte dos controles win ui core em classe FIRST semelhante ao controle de grade movendo-se para frente.

Se você acha que outros novos recursos, como melhor suporte a F # ou novos recursos de marcação, são importantes, abra uma nova solicitação de recurso para que possamos rastreá-los separadamente!

Parece que @migueldeicaza está https://github.com/microsoft/microsoft-ui-xaml/pull/736

Quero ecoar os pensamentos de @ eklipse2k8 sobre plataforma cruzada. Ao fazer uma biblioteca de interface do usuário de plataforma cruzada, você sempre terá que fazer concessões. O WinUI não deve se comprometer - ele precisa ser a substituição moderna da interface do usuário do Win32 (não quero mais chamar CreateWindowExW !) E precisa ser uma demonstração do que você pode fazer no Windows. O WinUI no macOS ou Android sempre proporcionaria uma experiência que nunca poderia se igualar à experiência nativa. Escrevemos aplicativos de plataforma cruzada e criamos UI nativa em cada plataforma. Dessa forma, os clientes obtêm a melhor experiência em sua escolha de plataforma. Se as pessoas querem uma solução de plataforma cruzada, tudo bem, elas devem procurar outra biblioteca para esse propósito - talvez uma que envolva o WinUI na plataforma Windows.

E com relação ao PWA, eles não representam o uso completo do sistema de IU do Windows, recomendar o foco em "aplicativos de janela única" descartaria imediatamente qualquer software profissional (exceto jogos). Já existem soluções para PWA e plataforma cruzada - não precisamos de outra.

XKCD obrigatório:
https://xkcd.com/927/

@MarkIngramUK Acho que a conversa de Cross Platform é mais sobre ser capaz de codificar em .NET e XAML para declarar a interface do usuário - do que ter esse aplicativo executado no Android, iOS, macOS, Linux ?! - sem ter que alterar o código ou abandonar o XAML.

Agora, se houvesse Renderizadores XAML para essas outras plataformas - como eles interpretam o XAML poderia ser como Formulários Xamarin, que se transferem para plataformas de IU nativas - ou simplesmente desenham no buffer da placa gráfica e desenham os pixels na tela - mantendo a maior parte do mesmos estilos de controles.

O WinUI 3.0 deve permanecer um projeto focado no Windows para unificar as várias APIs e ABIs com uma plataforma de interface do usuário baseada em XAML moderna. Mas isso não significa que o Xamarin ou os indivíduos não podem pegar o código de renderização e fazer versões para outras plataformas.

Tudo o que seria realmente necessário (em um alto nível de raciocínio) é garantir que o código que renderiza XAML para a tela no Windows esteja contido, para que outros renderizadores possam intervir em cenários de plataforma cruzada.

O WinRT / UWP / XAML vai precisar de alguma refatoração para retirá-los do SO Windows 10 - então, como essa refatoração é feita, para permitir a expansão futura, é algo para se manter em mente. Quer a plataforma cruzada se torne uma realidade ou não.

@MarkIngramUK eu concordo com @mdtauk

Não deve haver nenhuma razão para que não possamos usar xaml para descrever componentes de IU em outras bibliotecas, incluindo React. Se você olhar para um projeto como http://www.cshtml5.com , eles usam xaml que é convertido para html.
Eu também não acho que alguém alude ao fato de que o objetivo final é que a IU tenha a mesma aparência em outras plataformas, mas o que eu pessoalmente quero é algo do lado da IU que eu possa usar para alavancar meu investimento existente, por exemplo, UWP

A questão é simplesmente esta. Se eu fizer uma proposta para um cliente corporativo e apresentar um aplicativo UWP incrível, isso será fantástico em todos os aspectos. Se esse cliente corporativo tiver 1 usuário que está usando, por exemplo, um MacBook Pro, então eu imediatamente tenho um problema, pois o cliente corporativo prefere levar algo que funcione em qualquer lugar (denominador mínimo => site) do que meu "aplicativo nativo", mesmo que ele execute no Windows 10.

Portanto, a acessibilidade é fundamental. O fato de que a MS ainda espera que façamos investimentos em "aplicativos nativos" em 2019, sem nenhum roteiro para recursos de plataforma cruzada, é uma loucura.

Qualquer novo projeto de uma perspectiva empresarial provavelmente seguirá a lógica acima para acessibilidade e, portanto, todos os novos projetos serão tendenciosos para a web e tudo porque não há um roteiro que inclua capacidade de plataforma cruzada em XAML / UWP

Então, avançaremos 2-3 anos a partir de agora, nenhum novo investimento de empresas em UWP / win32 e você está sentado com outro "Silverlight" com o qual ninguém se importa.

A MS pode até me dizer que o XAML será preterido amanhã e que a "nova" biblioteca de IU é, por exemplo, React. Contanto que o c # possa ser colado a essa nova biblioteca, cortarei minhas perdas, descartarei o XAML e adotarei essa nova biblioteca de interface do usuário de plataforma cruzada. Pelo menos meu investimento tem durabilidade e é acessível a longo prazo.

Ao não fornecer clareza sobre este problema específico em torno da capacidade de interface do usuário de plataforma cruzada, a MS está criando incerteza em torno de sua "pilha nativa" e, portanto, a maioria das empresas prefere passar por um incêndio com uma perna de pau do que abraçar o desconhecido.

E com relação ao PWA, eles não representam o uso completo do sistema de IU do Windows

É justo, e eu concordo. Meu ponto principal com a PWA foi demonstrar que sua participação de mercado supera qualquer mercado específico, uma vez que é composto de todos os mercados agregados.

Dito isso, suponho que parte da confusão da minha parte seja o namespacing para refletir Microsoft.* , quando na verdade parece que ainda deveria ser Windows.* (ou mesmo Microsoft.Windows.* ) .

Já existem soluções para PWA e plataforma cruzada - não precisamos de outra.

Infelizmente, esse não é o caso do desenvolvimento .NET, que é parte da confusão e da angústia entre plataformas em torno deste anúncio e da discussão subsequente.

portanto, maximizando o alcance do mercado e as receitas potenciais para desenvolvedores de aplicativos, ao mesmo tempo que reduz os custos necessários de construção de aplicativos para isso.

Às vezes, os detalhes de desempenho e UX podem fazer uma grande diferença. O Skype maximizou o alcance de mercado usando a estrutura Electron ao custo de sacrificar o desempenho e o resultado é o desastre comercial.

Com relação a soluções multiplataforma (xplat).
As soluções Xplat são uma abstração de vários sistemas subjacentes nativos. Meu entendimento do WinUI é que ele será o sistema nativo do Windows.

Se o WinUI também fosse xplat, como ele incorporaria coisas que são exclusivas do Windows? Isso não o impediria de fazer coisas novas e inovadoras? Ou isso significaria que está na Microsoft para portar qualquer coisa nova ou diferenciadora do Windows para outras plataformas também? E as coisas que não puderam ser portadas porque o outro sistema operacional subjacente não podia suportá-las - elas não deveriam ser adicionadas ao Windows?

Se você construir algo com tecnologias nativas do Windows, é razoável presumir que a Microsoft oferecerá suporte por um período de tempo e fornecerá um caminho para novos sistemas baseados no Windows no futuro. (Reconhecendo o SilverLight como uma exceção.) Não acho razoável supor que, se você criar algo com tecnologias nativas do Windows e depois quiser executá-lo em um sistema operacional concorrente, cabe à Microsoft / Windows tornar isso mais fácil. Se você construiu um aplicativo para o iPad com Swift e também quis trazê-lo para a área de trabalho do Windows, esperaria que a Apple mudasse o desenvolvimento do iOS para tornar isso mais fácil?

Se você gosta ou prefere usar tecnologias nativas do Windows, isso é ótimo. O que você não pode fazer é adiar a decisão de negócios que você toma ao escolher essas tecnologias para outra pessoa. Todas as escolhas de tecnologia têm consequências e ninguém sabe o que pode ser necessário alguns anos no futuro ou o que seus clientes podem pedir. Pedir que um software desenvolvido especificamente para o Windows também possa ser executado em outro lugar pode dar a impressão de que o objetivo é evitar a tomada de uma decisão de tecnologia que poderia ter possíveis consequências negativas em qualquer momento no futuro. Com base na natureza da tecnologia e na velocidade da mudança, não acho isso realista.

Dito isso, se você deseja construir uma solução xplat (e há muitas pessoas que o fazem e razões para isso), porque você deseja direcionar vários sistemas operacionais agora, ou pode querer no futuro, então isso é razoável e compreensível cenário.
Para isso a Microsoft tem o Xamarin. Ou, se você preferir algo com XAML mais parecido com UWP, existe o Uno. (Existem muitas outras opções também.)
Se, como eu, você deseja que o Xamarin tenha um suporte nativo melhor para criar aplicativos do Windows, não acho que ter o WinUI tentando fazer várias coisas seja a resposta.

WinUI é mais do que apenas XAML e controles específicos. Inclui detalhes de como esses controles e os aplicativos construídos com eles se integram ao sistema operacional subjacente.
Se o planejamento do WinUI se concentra em tornar o desenvolvimento do Windows no Windows o melhor possível, esse é um bom caso para inovação e bom suporte futuro. Também é provável que aumente as chances de as pessoas continuarem a usar o Windows e, portanto, torna-se importante que ele tenha suporte sólido de várias soluções xplat.

Com relação a soluções multiplataforma (xplat).
As soluções Xplat são uma abstração de vários sistemas subjacentes nativos. Meu entendimento do WinUI é que ele será o sistema nativo do Windows.

Desculpe, mas eu não me sinto assim ...

Veja o Flutter ... Ele tem um motor central que pode renderizar qualquer coisa em qualquer plataforma que suporte.

Além disso, possui componentes que são totalmente implementados no Dart usando a camada gerenciada por mecanismo e que representam (desenhar / renderizar) em fidelidade de pixel a plataforma e a linguagem de design que você deseja usar, por exemplo, Material.io e Cupertino da Apple.

Então, esse IMHO, essa seria a melhor abordagem para fazer algo multiplataforma e que, ao mesmo tempo, represente as capacidades subjacentes da plataforma.

Não acho que seja razoável supor que se você construir algo com tecnologias nativas do Windows e depois quiser executá-lo em um sistema operacional concorrente, cabe à Microsoft / Windows tornar isso mais fácil

Certo ... Eu acho que o ponto que os outros estão fazendo é que isso parece um pouco para trás / surdo nos dias de hoje, especialmente no contexto de iniciar um novo aplicativo. Por que alguém criaria um aplicativo nativo do Windows quando isso atinge apenas uma pequena% do mercado? Este não é um bom uso de capital.

Se for para manter aplicativos herdados do Windows ou para fazer especificamente um aplicativo do Windows, então sim, eu concordo com tudo isso e faz sentido. No entanto, uma vez que parece haver mudanças significativas e mais investimentos envolvidos, a proposta de valor de fazer isso em vez de usar o Flutter ainda não foi explicada.

Isso é precisamente o que estou dizendo ...

Por exemplo, os incorporadores de vibração para Desktop no Win10 (WPF e UWP), bem como no OSX, estão chegando.

Eles são 100% gerenciados pelo tempo de execução de flutter, mas estão usando apenas (por exemplo) WPF / UWP para obter o gerenciamento de janelas e o ponteiro Graphics . Todo o resto é gerenciado pelo motor ...

Nós mesmos adaptamos o mecanismo de flutter para um dispositivo ARM embutido e devo dizer que foi uma experiência incrível. Porque? Porque nasceu para ser portátil e funcionar em qualquer lugar, permitindo que o "embedder" lide com detalhes de implementação específicos da plataforma em primitivos como GPU, renderização de software, gerenciamento de entrada, etc ...

É por isso que estou dizendo que WinUI por meio de UWP: The empire strikes back não vai funcionar a longo prazo.

A MSFT deve vir com algo multiplataforma, aberto e portátil. Assim como fizeram com .Net Core, com Blazor, etc ... Reinvent UWP / XAML não vai a lugar nenhum.

Eu acredito que o XAML tem um bom potencial se usado corretamente no sentido em que é usado para "descrever" (ou declarar como alguns dizem) a interface do usuário. O "mecanismo" constrói a árvore de renderização a partir dele e, a seguir, despacha os comandos de renderização para a plataforma subjacente.

Como a MSFT fez recentemente com o Chromium como núcleo do Edge, acredito que o WinUI (ou qualquer que seja o nome que se tornou) poderia aproveitar o Skia, pois tem back-ends para GL, DX, Vulkan, Renderização de software, FB, etc ... Apenas começando com que você tem um potencial ENORME para adicionar outras plataformas mais tarde ...

@galvesribeiro ,

Veja o Flutter ... Ele tem um motor central que pode renderizar qualquer coisa em qualquer plataforma que suporte.

Além disso, possui componentes que são totalmente implementados no Dart usando a camada gerenciada por mecanismo e que representam (desenhar / renderizar) em fidelidade de pixel a plataforma e a linguagem de design que você deseja usar, por exemplo, Material.io e Cupertino da Apple.

Ótimo, então assim que a Apple lançar uma atualização para o macOS e as atualizações da IU (talvez mudanças no raio do canto do botão ou nos gradientes de fundo, etc.), seu aplicativo Flutter não atualiza e continua a se parecer com o sistema operacional anterior - ao contrário de um nativo controle que obteria os benefícios de graça.

@MarkIngramUK esse é o trabalho da equipe para dar suporte às atualizações.

Assim como a equipe Xamarin fornece atualizações do dia 0 + 1, essa equipe pode fazer o mesmo. A equipe do Google também faz isso ...

Ao usar o controle "nativo", você está de volta ao mundo Xamarin onde apenas faz, invólucros (também conhecidos como Renders) ...

Não estamos discutindo ligações C # para controles nativos (como o Xamarin faz) ... Estamos falando de uma estrutura de IU completa como você faz com o Flutter ...

Só para constar, ninguém usa o tema "padrão" para nenhuma plataforma. Todos eles criam sua experiência do usuário exclusiva com base nas linguagens de design de cada plataforma.

Se você está tão preocupado em ter sempre a aparência de um componente nativo, seu aplicativo provavelmente nunca terá um bom público como eles seriam ...

Acredito que estamos falando de dois projetos diferentes aqui. O WinUI precisa ser o substituto do Win32. As pessoas estão pedindo uma solução multiplataforma, o que é razoável, mas não acho que deva ser esse projeto.

Além disso, Flutter permite que você use o "tema" em todas as plataformas. Assim, você pode executar o Cupertino em seu PC Win10. Um GRANDE exemplo é o design de materiais. É uma linguagem de design, não um conjunto de controles. Pode ser usado em qualquer lugar ... Acontece que algumas plataformas (como Android) têm seus controles nativos implementando-o ...

@MarkIngramUK

Estou apenas esclarecendo por que o WinUI não deve ser apenas um substituto do Win32, só isso.

Se for esse o caso, tenho quase certeza de que acontecerá em um futuro próximo, assim como o UWP ...

Concordo que o próprio @MarkIngramUK WinUI deve se concentrar em fornecer uma IU unificada para Windows, não importa se você usa C #, APIs do WinRT, ABIs do Win32, C ++, F #, VB, .NET Core.

O WinUI 3.0 envolve retirar todo o código e renderização de XAML do sistema operacional Windows e torná-lo uma estrutura independente do ciclo de atualização do sistema operacional e torná-lo código-fonte aberto.

Como ele é levantado e reembalado ainda está em aberto. Apenas os internos da Microsoft sabem como o farão. Para dar suporte ao futuro suporte de plataforma cruzada para XAML, só espero que se reflita sobre como isso pode ser alcançado no futuro, já que eles o estão retirando do Windows.

O .NET Core já está disponível em outras plataformas. Portanto, esse é o código C # por trás já transferível. Agora é apenas XAML, a interface do usuário e os controles, que precisam de um caminho para iOS / macOS / Android / Linux (e o que quer que venha no futuro)

Fora do escopo do WinUI 3.0, talvez, mas definitivamente vinculado a este projeto e esforço.

@jesbis @terrajobst @jevansaks

Quais são os planos da Microsoft para trazer uma estrutura de IU para o .NET Core que renderiza no desktop, móvel (Droid, iOS) e web?
A incerteza sobre isso já se arrasta há muito tempo.

@weitzhandler , eles já têm um roteiro , com o seguinte parágrafo:

Um alvo nativo do Windows para web e frameworks multiplataforma
WinUI 3 é melhor otimizado para bibliotecas e estruturas para construir .
Por exemplo, estamos planejando basear a nova implementação de alto desempenho do C ++ React Native Windows no WinUI 3.

Observe a parte enfatizada, "para construir". Como eu disse acima, não há razão para que isso não possa ser o Windows primeiro, com outras bibliotecas sendo construídas em cima dele.

OK então...

/me keep working on FluSharp

o que é razoável, mas não acho que deveria ser esse projeto.

Está com sede por aí @MarkIngramUK , perdoe nossas projeções. 😅

com o parágrafo seguinte

Não fala muito. Não revela a intenção clara da MS de fazer xplat de desenvolvimento C # e .NET. Talvez diga que HTML JS e CSS shi são melhores equipamentos para você do que C # se você quiser ser portátil.

No momento, Xamarin and Xamarin Forms é a história da Microsoft para o desenvolvimento em C # e .NET Core fora do Windows.

React Native para Windows está chegando para código Javascript e UI nativa (que usará WinUI 3.0 XAML)

No momento, a Microsoft não tem planos anunciados para trazer o XAML do WinUI 3.0 para outras plataformas.

O projeto WinUI está tentando unificar as estruturas de desenvolvimento Win32, WPF, MFC, UWP e .NET Core em uma única estrutura de apresentação XAML moderna.

Acho que depois disso, o trabalho deve ir para encontrar maneiras de renderizar XAML escrito para WinUI 3.0 - em plataformas como macOS, iOS, Android, etc - mas isso não está na agenda até agora.

Uma vez que o trabalho do WinUI 3.0 comece aqui, ele será de código aberto, de modo que torna possível o trabalho em várias plataformas no futuro, se houver necessidade suficiente para isso. E pode não ser a Microsoft que eventualmente disponibilize esses caminhos de plataforma cruzada, pode ser a comunidade de código aberto.

Algum plano de tornar o F #, enteado ruivo do .NET, um cidadão de primeira classe? E então as pessoas se perguntam por que a grande maioria dos desenvolvedores .NET não toca no F # com uma vara de três metros.

No momento, Xamarin and Xamarin Forms é a história da Microsoft para o desenvolvimento em C # e .NET Core fora do Windows.

Sim, o Xamarin.Forms está sendo portado para macOS, GTK, UWP e WPF, além de ter material design em todos os lugares em andamento, o que o torna o framework de interface do usuário .NET de fato, mas é tão lento e cheio de bugs que me pergunto o que a Microsoft está pensando sobre seus desenvolvedores. Basta olhar para a lista de problemas! Uma vez iniciado o desenvolvimento sério, os bugs são atingidos a torto e a direito. Espero que com o WinUI possamos finalmente ter uma melhor experiência de desenvolvimento.

Re: F #

Se você acha que outros novos recursos, como melhor suporte a F # ou novos recursos de marcação, são importantes, abra uma nova solicitação de recurso para que possamos rastreá-los separadamente!

Sim, é sempre F # que é rastreado separadamente e ignorado novamente. Basta olhar para UWP e .NET Native - ambos não tinham o F # em mente e a comunidade em geral tinha que descobrir tudo. 🙄 Após 4 anos, F # ainda não é compatível com .NET Native.

Para sugestões / perguntas do F #, criei um problema dedicado:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

Sinta-se à vontade para direcionar as discussões do F # para lá.

Definitivamente, não estamos ignorando o feedback sobre ele - ter um problema dedicado apenas nos ajuda a organizá-lo e rastreá-lo.
A equipe está discutindo como isso poderia se encaixar no roteiro para 3.0 e posteriores e irá atualizar o novo problema com quaisquer desenvolvimentos.

RE: interface de usuário de plataforma cruzada:

Obrigado a todos pelos pontos levantados até agora e pela paixão por .NET e Xaml.
Só quero dizer novamente que estamos ouvindo atentamente todos os comentários e compartilharemos nossas ideias e atualizações à medida que progredimos.

Só para reafirmar o roteiro atual e alguns pontos que surgiram:

WinUI é a plataforma de IU nativa do Windows (incluindo aplicativos nativos, não apenas .NET) e, para a versão 3.0 inicial, estamos focados principalmente em torná-la independente do sistema operacional e trabalhar para deixá-la pronta para o desenvolvimento de código aberto em um lançamento mais rápido ciclo. Queremos ter certeza de que o escopo é viável o suficiente para termos uma prévia deste ano.

Um de nossos outros objetivos atuais de curto prazo é permitir que WinUI sirva como um destino nativo para outras plataformas usarem no Windows: por exemplo, também estamos trabalhando para garantir react-native-windows - uma implementação C ++ React Native de alto desempenho para Windows - usa WinUI , e os controles WinUI podem ser usados ​​para criar visualizações de IU nativas em aplicativos React Native.

Serei totalmente honesto. Eu tenho um aplicativo de desktop Windows nativo que escrevi em 2006 no WinForms que ainda estou vendendo online hoje.

Não tenho planos de migrar este aplicativo para WPF, UWP ou usar qualquer tecnologia exclusiva de IU do Windows. Eu não me importo com o quão convincentes as demonstrações do Windows parecem. Se eu decidir trabalhar neste aplicativo novamente, a próxima versão principal será algum tipo de implementação de plataforma cruzada que pode ser executada em MacOS, Linux e Windows.

Atualmente, provavelmente seria semelhante a Blazor + .NET Core + Electron.

Acho que @Mike-EEE traz alguns pontos importantes. A UX / plataforma que me permite alavancar minhas habilidades em C # para atingir o maior número de público é a tecnologia mais provável que irei escolher.

A Microsoft deve se concentrar em capacitar os desenvolvedores para alavancar suas habilidades existentes para alcançar um público maior com seus aplicativos. Acho que é uma estratégia vencedora e manterá a Microsoft no jogo.

O que está escrito na parede é que o software do sistema operacional está se tornando cada vez mais uma mercadoria. Sendo assim, as pessoas podem escolher qualquer sistema operacional que quiserem e obter os aplicativos que desejam usar. Acho que isso ficará mais evidente à medida que o tempo avança, à medida que os fornecedores mundiais de software continuam a se concentrar em plataformas cruzadas.

Em economia, uma mercadoria é um bem ou serviço econômico que tem fungibilidade total ou substancial: isto é, o mercado trata as instâncias do bem como equivalentes ou quase isso, sem levar em consideração quem os produziu. https://en.wikipedia.org/wiki/Commodity

A Microsoft tem que decidir: ela quer fazer parte da história das ferramentas do desenvolvedor? Ou a Microsoft investe milhões de dólares em uma nova pilha de UX somente para Windows que acabará se juntando ao cemitério de pilhas de UX que cada vez menos pessoas usam?

Este projeto é de propriedade de uma equipe que tem um grande conhecimento sobre como o funcionamento interno do Windows funciona, e seria uma distração para eles saírem e descobrir como fazer algo funcionar muito bem no Mac ou Linux no mesmo grau.

É uma posição difícil de ter certeza. Mas os tempos mudaram. O mundo de hoje é muito diferente do mundo de 1995. A meu ver, há algumas opções:

Você poderia contratar mais pessoas para expandir esse conhecimento além do Windows.

Ou use o conhecimento dessa equipe para construir um encanamento de UX dentro do Windows que aprimora a compatibilidade para estruturas de aplicativos de interface do usuário de plataforma cruzada para executar melhor no Windows.

Exatamente como o WSL fez para rodar Linux no Windows.

• Use o conhecimento da equipe para fazer o GTK rodar 200 vezes mais rápido.
• Use o conhecimento da equipe para fazer os aplicativos QT rodarem 200 vezes mais rápido.
• Use o conhecimento da equipe para fazer aplicativos Electron renderizar mais rápido do que qualquer outro sistema operacional.

Há muito trabalho que pode ser feito para aprimorar a história de compatibilidade de UX de plataforma cruzada do Windows. Mas investir em uma pilha de UX totalmente nova e esperar que todos nós mudemos (sem nenhuma história de plataforma cruzada) é uma aposta bem grande. Você vai ter que quebrar esse hábito de criar novos frameworks UX apenas para Windows.

Apenas meus dois centavos. :Bolsa de dinheiro:

: horse_racing:: cowboy_hat_face: Lil Nas X - Old Town Road (filme oficial) com Billy Ray Cyrus

@bchavez

Você vai ter que quebrar esse hábito de criar novos frameworks UX apenas para Windows.

-- Não apenas isso. Até o hábito de quebrar a portabilidade XAML interna do próprio Windows. WPF, Siliverlight, UWP, todos em seu próprio fork ... Esse tipo de coisa está afastando mais e mais pessoas das ferramentas de desenvolvimento do Windows em geral que eu pessoalmente gostaria de continuar usando no futuro. Quanto mais resistência das ferramentas de desenvolvimento do Windows significa que cada vez menos C # é relevante e, para mim, é o que me preocupa quando começo a utilizá-lo.

RE: interface de usuário de plataforma cruzada:

... WinUI é a plataforma de IU nativa para Windows (_ incluindo aplicativos nativos _, não apenas .NET) e para a versão 3.0 inicial, estamos focados principalmente em torná-la independente do sistema operacional e trabalhar para torná-la pronta para o código aberto desenvolvimento em um ciclo de lançamento mais rápido. Queremos ter certeza de que o escopo é viável o suficiente para termos uma prévia deste ano.

Adicione um +1 para a ideia de atualizar a aparência visual dos controles WinForms, MFC, WPF em execução com WinUI 3.0 para corresponder melhor aos estilos de controle Fluent / FabricWeb.

Certamente, tamanhos de controle diferentes (qualquer coisa que não seja WinRT XAML provavelmente deve corresponder suas métricas à versão compacta dos controles UWP), mas uma aparência coerente e consistente.

Adicione uma dependência WinUI 3.0 em WinForms e os controles mudam.

Os aplicativos WPF do WinUI 3.0 detectam e usam os temas de controle Fluent.Light.xaml ou Fluent.Dark.xaml.

@weitzhandler Eu entendo seu sentimento. Espero nunca ter que tocar em javaScript e similares para fazer esta interface de usuário de plataforma cruzada. Não gosto nem de pensar em começar um projeto usando elétron, angular, dardo, vibração.
Espero que possamos ter uma solução em breve com o .NET 5, que traga o sonho do Universal XAML. O Microsoft XAML pode GANHAR, Web, Mobile, Desktop e IoT.
O Silverlight quase fez isso, para muitos casos de uso .

Você vai ter que quebrar esse hábito de criar novos frameworks UX apenas para Windows.

O WinUI 3.0 nunca será lançado se tivermos que esperar (inevitavelmente comprometido em todas as plataformas) suporte multiplataforma. WinUI deve ser a estrutura de IU de nível mais baixo no Windows e, se você quiser capacidade de plataforma cruzada, crie em cima disso (ou use React Native, Xamarin, etc).

Você vai ter que quebrar esse hábito de criar novos frameworks UX apenas para Windows.

Gostaria apenas de esclarecer que não estamos tentando criar uma nova estrutura de IU com WinUI 3.0.

Nosso objetivo inicial é:

• remover barreiras para usar as tecnologias nativas modernas existentes (Windows 10 Xaml UI e compositor), desacoplando-as do sistema operacional e permitindo que funcionem em modelos de aplicativos existentes (win32 e UWP), linguagens, outras estruturas (por meio de ilhas) e versões do Windows

• atualizar nosso processo de engenharia para ser de código aberto

O WinUI 3.0 nunca será lançado se tivermos que esperar (inevitavelmente comprometido em todas as plataformas) suporte multiplataforma.

Cara ... Se você realmente acredita nisso, quer dizer que frameworks de sucesso como o Flutter não funcionam ...

Eu também não gosto do Dart, mas eles lançaram um produto de descida bonito que está evoluindo e ganhando tração MUITO rápido.

Estou frustrado porque o WinUI se tornará apenas coisas do Windows ...

O .Net precisa de uma estrutura de IU que corresponda à grandiosidade dos recursos de plataforma cruzada do .Net Core, assim como acabamos de obter para Web com Blazor (cliente e servidor).

Acho que, por enquanto, ainda temos que contar com esforços voltados para a comunidade.

Eu entendo o que sua equipe está tentando fazer @jesbis ... É que muitos de nós estão cansados ​​de ver UI em .Net / C ++ / UWP / MFC / Windows um _silo_'ed coisa que só roda no Windows enquanto todo o mundo (ofc exceto Apple e OSX) estão indo na direção oposta, oferecendo aos desenvolvedores soluções cada vez melhores entre plataformas. Como você mencionou o React e o Rect-Native (só para constar, eu também não gosto, apenas mencionando que eles estão evoluindo).

Então, o que temos agora são apenas iniciativas conduzidas pela comunidade como Avalonia ou mesmo Uno e outros frameworks (como FluSharp, que estou trabalhando conforme mencionado) que evoluem MUITO LENTAMENTE por razões óbvias ...

Minha sugestão é que, em vez de apenas retirar o XAML e o compositor da base de código do Windows e torná-lo apenas para Windows, obtê-lo e fazer abstrações adequadas para que pudesse funcionar em várias plataformas. Assim como fizemos com .Net Core, que inicialmente era apenas Windows, mas os esforços da comunidade fizeram com que funcionasse muito rápido no Linux, OSX e até mesmo em dispositivos ARM ...

(inevitavelmente comprometido em todas as plataformas) suporte multiplataforma

Eu realmente não acho que isso será um problema, visto que o design de plataforma cruzada é, e sempre foi, um aspecto-chave da IU XAML da UWP e do Design Fluent. Definitivamente, existem alguns controles em que o design visual é diferente entre as versões do Windows - isso é tratado perfeitamente, você obtém a interface do usuário nativa que corresponde ao sistema operacional do dispositivo.

Por exemplo, Acrílico e Revelação integrados aos controles, cores de destaque em Pivots e NavigationViews - essas coisas não aparecem na Atualização do Criador, mas aparecem na FCU e mais recentes. Nenhuma mudança necessária.

Obviamente, há muito mais complexidade nos bastidores para renderizar a IU em um sistema operacional totalmente diferente, mas em termos de projetar a IU, não acho que haja novas considerações a serem feitas, do que nunca com UWP e WinUI.

Acho que a grande preocupação é quais são os planos de longo prazo. Com base nas respostas de @jesbis , parece que eles estão focando apenas no curto prazo agora, e os planos de longo prazo ainda estão abertos para discussão.

Isso é compreensível, o escopo de tal projeto é enorme. Eu poderia entender perfeitamente se não fosse o plano de curto prazo, mas sim o plano final. A transparência é importante aqui, é claro que ninguém quer oferecer suporte a uma plataforma sem um futuro claro.

É claro que a MS como um todo está focada em plataformas cruzadas - vemos isso com o Fluent Design (que agora tem exemplos para iOS, Android e web), um grande número de aplicativos feitos pela MS em outras plataformas - portanto, a IU compartilhada é realmente apenas um grande elo perdido. E é por isso que seria tão decepcionante não ver isso acontecer - acho que muitas pessoas gostam da ideia de uma plataforma de aplicativo universal feita pela MS, mas não faz sentido oferecer suporte, se não tivermos um solução completa para isso.

O ponto é ... Como com material.io e Cupertino, poderíamos (e não estou surpreso se o Google já não estiver fazendo isso!) Ter o "tema" flutuando para uma linguagem de design fluente ...

E esse é o meu ponto quando eu disse que uma estrutura de interface do usuário verdadeiramente cruzada não se importaria com isso e apenas funcionaria, como o Flutter faz ... Não vejo onde temos compromissos sobre isso ...

@weitzhandler Eu também não gosto de HTML para aplicativos nativos. Caso contrário, eu estaria usando Electron com React 😄

Só não estou sendo passional aqui, estou apenas sendo racional.

Estou realmente ansioso pelo WinUI 3.0 e eu o usaria imediatamente para um novo projeto de desktop C ++ / WinRT do Windows. E espero que a próxima versão principal após a 3.0 introduza um runtime portátil para hospedar os aplicativos WinUI (como o runtime Flutter). Para um número significativo de aplicativos LOB e aplicativos semelhantes ao Photoshop, a GUI pode ser a mesma em cada plataforma, mas a chave é o desempenho e a reutilização do código-fonte. E também acho que o projeto xlang é uma ótima ideia e promete boas notícias no futuro.

Eu sugiro que os usuários aqui reservem um tempo para ouvir Scott Hunter após o BUILD 2019 sobre como Win UI, Xamarin Form, UNO, Web Assembly poderiam se unir.

.NET Core 3 e posterior com Scott Hunter @ .NET Rock

Os Formulários Xamarin (XAML) e UNO (XAML) foram criados com a visão de plataforma cruzada. No caso do UNO (além de iOS, Android, XAML para Web por meio de Web Assembly).

UWP foi criado sem nenhuma visão além do ecossistema da Microsoft, por exemplo, Web, Android, iOS. Todo o impressionante esforço de design do Fluent tem pouca ocupação devido à lenta adoção de UWP

Como @ Mike-EE apontou, o droid e o iOS têm 2 ~ e 1,5 ~ bilhões, enquanto o Win10 tem 0,9 bilhões. A maioria dos desenvolvedores ainda reluta em pular do WinForm e WPF para o UWP.

PORQUE? Os controles UWP, do comercial e da Microsoft, estão INCOMPLETOS !!!!! em comparação com aqueles no WinForm e WPF. Não há nenhum esforço da Microsoft para ajudar nessa transição. A Ilha XAML não tratará disso ENQUANTO A MICROSOFT tem BLIND SPOT, pois os desenvolvedores PRECISAM fazer a transição do winForm e do WPF para UWP.

Com esses controles UWP ausentes, agora um esforço significativo está sendo feito para trazer o Win UI para React Native for Web. ?????? Precisamos desses controles de IU do Win ausentes para UWP para que possamos fazer lobby para a transição do WinForm e do WPF para o UWP .

Um desses controles é o Controle de Diagrama . Todos os aplicativos de negócios com uso intensivo de dados precisam de controle de diagrama para UWP.

==> Eu entendo a necessidade de desacoplar a IU UWP. Isso só faz sentido espalhar a marca Fluent Design para outras plataformas, por exemplo, iOS, Android, Web.
==> Concentre-se em fornecer um melhor controle de modelo 3D e controles de diagrama (ambos 2D / 3D)

Só faz sentido ficar e aguardar o NET5 quando ALL BCL partir (mono é mesclado com o nativo do Windows, para Web Assembly etc), porque EU VER O FUTURO DA HOLOLENS IU 3D criativa.

Para isso, precisamos de Controle de Diagrama 2D / 3D para UWP e controle de modelo 3D que não deve apenas exibir o modelo, mas permitir que o desenvolvedor acesse a animação do esqueleto / vértice.

@jesbis Recomendo que você coloque mais pessoas nesses USP (pontos de venda exclusivos) do Win UI para UWP.

@weitzhandler

Este problema foi criado para discutir o roteiro do

@jesbis fez uma declaração esclarecedora :

WinUI é a plataforma de IU nativa do Windows (incluindo aplicativos nativos, não apenas .NET) e, para a versão 3.0 inicial, estamos focados principalmente em torná-la independente do sistema operacional e trabalhar para deixá-la pronta para o desenvolvimento de código aberto em um lançamento mais rápido ciclo. Queremos ter certeza de que o escopo é viável o suficiente para termos uma prévia deste ano.

Seus primeiros dois comentários foram sobre o assunto.

Os seis itens a seguir foram uma combinação de improdutivo e depreciativo, e você está perto de violar o Código de Conduta de Código Aberto da

Esta deve permanecer uma conversa profissional e produtiva com a Microsoft.

// Não estou acompanhando essa conversa para ouvir algum cara desabafar o dia todo.

Acho que há alguns comentários excelentes aqui, embora pareça que pode haver duas discussões separadas. Vou ser breve porque a maior parte já foi dita antes.

Plataforma cruzada e web

O .NET Core é ótimo. Podemos finalmente atingir todas as plataformas e pontos de contato com ótimas ferramentas e uma linguagem incrível.
A única coisa que está faltando é uma pilha de IU, exceto para Blazor (HTML / CSS é uma merda). Para máxima comparabilidade, seria ótimo ter uma estrutura que permitisse aos desenvolvedores de desktop migrar para a web e além com as mesmas habilidades, ferramentas e linguagem (Xaml e C #). Tbh, o Silverlight fez uma grande coisa lá - simplesmente funcionou). Não tenho certeza se o WinUI precisa ser essa estrutura, mas levante o problema internamente. Basicamente, o Flutter para desenvolvedores .NET, e direcionar para a Web seria a maior vantagem.

Não tenho certeza se o Xamarin pode ser essa plataforma, mas se for - certifique-se de que o Xaml esteja alinhado o máximo possível entre WinUI e Xamarin.

WinUI

Isso precisa acontecer. Deve haver uma pilha Xaml comum para criar as melhores experiências possíveis na plataforma Windows. Idealmente, as lacunas que faltam no WPF em termos de controles e funcionalidade devem ser preenchidas.

HoloLens e além

Com o Lite chegando, e novos fatores de forma super empolgantes, como o HoloLens, pode-se argumentar que o UWP não está pronto para isso em termos de interface do usuário. Sim, podemos executá-los em um HoloLens, o que é bom, mas gostaria de ver uma maneira de realmente otimizar aplicativos para 3D sem usar o Unity completo.

O WinUI está muito à frente do Xamarin. Mas a equipe da Microsoft acabou de lançar o Xamarin 4.0 ...
Pessoalmente, gosto mais do Xamarin, pois é a denominação mais baixa para Cross Platform, e haverá um aumento no número de aplicativos nativos para SaaS no futuro.

Além de Xamarin, existe alguma alternativa.
1) Por que não abraçar a plataforma UNO e fazer a renderização da web usando SkiaSharp?
2) @ zezba9000 Você precisa de um back-end de renderização agnóstico como os motores de jogo usam para começar. Na verdade, eu meio que reconheço ...

Talvez a Microsoft empurre mais o WinUI, porque não há rastreamento de código-fonte aberto, ao contrário de outra solução de plataforma cruzada: Xamarin, UNO, pode ter bibliotecas UNIX ...

De qualquer forma, que a força esteja com você.
PS: Os patrocinadores do Github são da Microsoft, portanto, patrocine algum desenvolvedor de Mac / Linux notável para o fork de plataforma cruzada do WPF / Winforms.

@jkoritzinsky , Uma coisa que a equipe WinUI deve tomar cuidado com a renomeação do WinUI 3.0: se você renomear qualquer um dos tipos projetados em .NET, as projeções não funcionarão (e não estamos planejando adicionar mais uma vez que não é um sistema extensível de manutenção). Aqui está uma lista dos tipos que projetamos: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Quaisquer alterações em tipos diferentes desses tipos exigirão que os usuários envolvam seus objetos em novos objetos que implementam as novas interfaces ou copiem seus dados para os novos tipos. Em particular, os tipos INotifyPropertyChanged e INotifyCollectionChanged são de interesse em relação às ilhas XAML e fornecem suporte downstream.

Eu concordo e fico feliz que você tenha levantado esse problema, embora eu gostaria de acrescentar que acho que essas projeções são um pouco infelizes. Não projetamos cada API que provavelmente deveria ser (pensando nas APIs System.IO), então devemos remediar isso ou pensar de forma diferente. Uma coisa que vem à mente é não adicionar tipos semelhantes, mas diferentes, aos tipos .NET em um namespace diferente. Em vez disso, devemos permitir que nossos desenvolvedores C ++ também usem System.ComponentModel.INotifyDataErrorInfo. Isso é mais ou menos o que fizemos com C ++ / CLI, mas não exigiria o carregamento do CLR para um aplicativo C ++ puro. Não sei se isso seria mais confuso, mas parece que estamos vazando as diferenças fundamentais e subjacentes nas tecnologias .NET e WinRT na camada de API, o que faz com que as coisas pareçam incoerentes.

@ meir-pletinsky. NET é apenas uma estrutura que você pode usar para fazer aplicativos com UWP XAML. Eles querem validação de campo de texto disponível para Devs, não importa qual estrutura eles usam

Isso é certo sobre o dinheiro, nós temos desenvolvedores C ++ com os quais nos preocupamos. Embora, como mencionei acima, eu adoraria que não causássemos confusão na comunidade .NET apenas para que isso acontecesse.

@mdtauk , não, WinUI Desktop (anteriormente Xaml Desktop) permite que você use Xaml com Win32 diretamente, sem o uso da ilha.

Acho que @ meir-pletinsky estava se referindo a .NET / C ++, a menos que esteja faltando alguma coisa.

@MarkIngramUK Acredito que estamos falando de dois projetos diferentes aqui. O WinUI precisa ser o substituto do Win32. As pessoas estão pedindo uma solução multiplataforma, o que é razoável, mas não acho que deva ser _este_ projeto.

Sim, concordo totalmente! Para mim, WinUI significa definir a interface de usuário mais moderna, de alto desempenho e melhor em tudo para Windows. O Xamarin deve ser a história de plataforma cruzada da Microsoft e deve evoluir para ficar no topo do WinUI.

@mdtauk

Adicione um +1 para a ideia de atualizar a aparência visual dos controles WinForms, MFC, WPF em execução com WinUI 3.0 para corresponder melhor aos estilos de controle Fluent / FabricWeb.

Certamente, tamanhos de controle diferentes (qualquer coisa que não seja WinRT XAML provavelmente deve corresponder suas métricas à versão compacta dos controles UWP), mas uma aparência coerente e consistente.

Adicione uma dependência WinUI 3.0 em WinForms e os controles mudam.

Os aplicativos WPF do WinUI 3.0 detectam e usam os temas de controle Fluent.Light.xaml ou Fluent.Dark.xaml.

Eu realmente não quero ver a MS investindo tempo e recursos nessas estruturas para que pareçam aplicativos nativos do Windows 10. É por isso que haverá o WinUI 3.0. Você quer a aparência do Windows 10 em aplicativos WPF / WinForms? Use o WinUI 3.0.
A MS deve preferir investir seus recursos para fechar as lacunas existentes (e bloquear) entre o UWP / WinUI e suas contrapartes Win32, do que visitar novamente seus frameworks mais antigos. Especialmente porque o WinUI se destina a se tornar _a_ estrutura de apresentação do Windows ...

Gostaria de pedir esclarecimentos sobre o WinUI e as intenções da Microsoft sobre UI / UX:

1. O WinUI substitui TODOS os seguintes (hipoteticamente?): Win32, ATL, MFC, WinForms, Silverlight (eu sei), WPF, UWP e / ou Ilhas XAML? Reconheço que essas tecnologias continuarão a existir e a ter suporte por algum tempo indefinido ; Só quero entender claramente que isso é o que a Microsoft está dizendo que é "o caminho a seguir" e que (por exemplo) devemos considerar WinForms e WPF da mesma forma que consideramos Win32 ou MFC.

2. O WinUI deriva do UWP? (Ou quão semelhantes são os dois?) Quão semelhante (ou diferente) é o WinUI em comparação com UWP, ilhas XAML ou WPF?

Como desenvolvedor profissional de C # e C ++, comecei a trabalhar com WinForms, depois mudei para WPF e depois voltei para WinForms simplesmente porque podia projetar UI / UX para fins comerciais em WinForms quase duas vezes mais rápido do que em WPF. O WPF deu muito mais flexibilidade, desempenho e parecia muito melhor - mas a mutilação XAML que ocorreu assim que alguém tocou a interface por meio do Designer em vez de editar manualmente o XAML foi horrível. Em alguns casos, acho que WinForms (usando o Designer) foi muito mais rápido do que construir manualmente um formulário ou controle XAML semelhante.

Pessoalmente, adoraria uma IU disponível e idêntica em todos os produtos da Microsoft. Uma estrutura que pode ser aproveitada pelo Win32 ou .NET de forma semelhante significaria aplicativos consistentes e de aparência moderna para TODOS os desenvolvedores da Microsoft, e também significaria que questões e problemas comuns podem ser resolvidos em sessões que visam uma única tecnologia - por exemplo, ao fazer uma pergunta sobre um controle, a resposta seria idêntica (se não quase idêntica) para um desenvolvedor Win32 OU um desenvolvedor .NET. Isso tornaria o aprendizado de "WinUI" útil para qualquer pilha para qualquer desenvolvedor e também tornaria o acesso às informações online (StackOverflow, etc.) muito mais valioso, independentemente de onde você está desenvolvendo. Embora eu não use o Xamarin, se o Xamarin pudesse ser feito para seguir esses passos (como uma extensão do WinUI?), A declaração acima poderia ser aplicada não apenas aos desenvolvedores do Windows, mas também àqueles voltados para Android, iOS, etc.

Para que tipo de aplicativos eu gostaria de usar o WinUI?

Se meu entendimento de WinUI estiver correto e for "o caminho a seguir", substituindo Win32, MFC, Forms, WPF, etc., e a mesma estrutura estiver disponível para desenvolvimento nativo ou .NET, então irei substituir a composição ansiosamente em _ TODOS _ os aplicativos que eu apoio. UIs modernas e consistentes, que funcionam (e se comportam) da mesma forma, independentemente da plataforma ou pilha? Não é isso que todos nós queremos? Eu não acho que alguém queira se lembrar de como CreateWindowEx () e executar um loop de mensagem para despachar eventos no Win32 enquanto manipula eventos de uma maneira completamente separada no WinForms ou WPF. É hora de algo "moderno". Eu realmente espero que isso seja o que WinUI (3.0) é.

Compatibilidade do sistema operacional e suporte de nível inferior

Acho ótimo que o WinUI esteja se concentrando em separar a composição do sistema operacional, mas há um grande número de clientes que nem mesmo usam o Windows 10 ainda. Eu sei que é um ponto problemático, e todos nós gostaríamos que nosso público-alvo estivesse exibindo o mais recente, mas é um problema real que todos nós enfrentamos diariamente. Que discussão está sendo feita sobre como tornar o WinUI disponível para plataformas mais antigas além de 1703, que acredito ser a plataforma mais antiga visada no momento?

Tornar o WinUI estaticamente vinculável ou incorporável (como o .NET Core / 5) é uma opção? Teremos que ter como alvo o Windows 8.1, Windows 8, Windows 7 - até mesmo o Windows PE. Como podemos usar o WinUI com esses requisitos?

@shidell :

O WinUI deriva do UWP? (Ou quão semelhantes são os dois?) Quão semelhante (ou diferente) é o WinUI em comparação com UWP, ilhas XAML ou WPF?

WinUI 3.0 será, de certa forma, a próxima versão dos componentes da plataforma de IU do Windows 10 / UWP, incluindo a plataforma Xaml, composição e entrada. Vem dessa base de código.

Deve ser muito semelhante às APIs da plataforma Windows 10 / UWP Xaml, exceto o que é mencionado no roteiro : ou seja, um namespace raiz diferente, melhor suporte para combinação e correspondência com outras tecnologias (por exemplo, usando um modelo de aplicativo win32 em vez de UWP), e alguns novos recursos aditivos.

O WinUI substitui TODOS os seguintes (hipoteticamente?): Win32, ATL, MFC, WinForms, Silverlight (eu sei), WPF, UWP e / ou Ilhas XAML? Reconheço que essas tecnologias continuarão a existir e a ter suporte por algum tempo indefinido; Só quero entender claramente que isso é o que a Microsoft está dizendo que é "o caminho a seguir" e que (por exemplo) devemos considerar WinForms e WPF da mesma forma que consideramos Win32 ou MFC.

WinUI é onde nosso principal desenvolvimento e progresso ativos são para a IU do aplicativo nativo no Windows. É também o que o próprio Windows e os aplicativos e dispositivos nativos da Microsoft usam.

As ilhas Xaml farão parte do WinUI e permitirão que você use o WinUI para criar novas visualizações em aplicativos existentes (por exemplo, WPF, WinForms).

Que discussão está sendo feita sobre como tornar o WinUI disponível para plataformas mais antigas além de 1703, que acredito ser a plataforma mais antiga visada no momento?
Tornar o WinUI estaticamente vinculável ou incorporável (como o .NET Core / 5) é uma opção? Teremos que ter como alvo o Windows 8.1, Windows 8, Windows 7 - até mesmo o Windows PE. Como podemos usar o WinUI com esses requisitos?

Obrigado por compartilhar o feedback sobre isso. Para 3.0, estamos focados nas plataformas do roadmap (1703+, com algum suporte em 8.1). Definitivamente entendemos que os desenvolvedores também têm clientes em outras versões, e isso é algo que planejamos avaliar no futuro.

Incrível - parece que WinUI é "o caminho a seguir" e, dado esse entendimento, dizer que estou animado seria um eufemismo.

Em particular, acho fantástico que as ilhas XAML permitirão aos desenvolvedores estender o WinUI para tecnologias mais antigas, como WPF e WinForms. Essa é uma ótima ponte para "avançar" ao trabalhar / estender projetos antigos.

Incrível - parece que WinUI é "o caminho a seguir" e, dado esse entendimento, dizer que estou animado seria um eufemismo.

Em particular, acho fantástico que as ilhas XAML permitirão aos desenvolvedores estender o WinUI para tecnologias mais antigas, como WPF e WinForms. Essa é uma ótima ponte para "avançar" ao trabalhar / estender projetos antigos.

Eu gostaria de pensar se um projeto WinForms, MFC ou WPF foi criado com WinUI 3.0 incluído - eles poderiam apenas renderizar páginas / conteúdo / janelas XAML sem ter que usar uma Ilha XAML em um Form / Janela WPF / Janela HWND.

A capacidade de usar apenas XAML puro ou usar uma Ilha para colocar o XAML nas superfícies fornecidas pela estrutura - tornaria o WinUI 3.0 "A única IU para governar todos eles"

realmente tornaria o WinUI 3.0 "A única IU para governar todos eles"

... no Windows. 😉

WinUI 3.0 será, de certa forma, a próxima versão dos componentes da plataforma de IU do Windows 10 / UWP, incluindo a plataforma Xaml, composição e entrada. Vem dessa base de código.

Por falar nisso ,

Uma tentativa foi feita , é claro, mas ficou muito aquém da implementação do WPF, apesar de levar mais de dois anos completos para ser desenvolvida.

Além disso, muitos serviços que estavam disponíveis na marcação WPF ainda precisam estar disponíveis e implementados em UWP. O esforço aqui é para garantir que a nova marcação WinUI 3.0 baseada em UWP terá total fidelidade com o WPF? Peço desculpas se isso for explicado em algum lugar, mas ainda tenho que analisar a mensagem para vê-la (e agradeço quaisquer recursos para corrigir / complementar meu entendimento).

realmente tornaria o WinUI 3.0 "A única IU para governar todos eles"

... no Windows. 😉

Pelo menos para a janela de lançamento do WinUI 3.0. Espero que seja o início de um processo para trazer a renderização XAML para outras plataformas ...

Gostaria de saber se você pode falar sobre como será a integração entre WPF e UWP. Em particular, com conceitos como extensões de marcação que temos pedido na UWP há anos, com muito pouco sucesso. [...] O esforço aqui é para garantir que a nova marcação WinUI 3.0 baseada em UWP terá total fidelidade com o WPF?

@Mike-EEE fidelidade total com WPF não é um objetivo para 3.0. No entanto, estamos rastreando uma série de itens de trabalho para fechar as lacunas ao longo do tempo (por exemplo, # 741 melhorias na extensão de marcação - por favor, dê uma olhada e deixe um comentário se isso atenderia às suas necessidades!) E continue a expandir o WinUI além do WPF (por exemplo, # 686 suporte de modelo 3D).

Se houver outros recursos específicos no WPF que você deseja / precisa usar no WinUI, sinta-se à vontade para abrir novos problemas de propostas de recursos para eles ou comentar no recente " Recursos do WPF que deveriam estar no WinRT XAML ", edição nº 719 . Não temos recursos infinitos, mas definitivamente estamos tentando levar em conta a opinião da comunidade em nosso planejamento. Assim que tudo estiver com o código aberto, também haverá uma oportunidade para qualquer pessoa potencialmente ajudar a contribuir com recursos.

Isso é encorajador, @jesbis obrigado por compartilhar isso. Eu atualizei os votos relevantes no UserVoice para apontar os assinantes para esse problema.

Acho que minha maior preocupação é se a fidelidade total do WPF não é um objetivo, embora ter o WinUI utilizado dentro do WPF _é_ um objetivo, então você encontrará atritos com a adoção do WPF, pois ele tem o modelo Xaml superior (e original).

Ou seja, não parece haver uma proposição de valor óbvia para incorporar WinUI3.0 ao WPF, da mesma forma que as ilhas Xaml não têm uma proposição de valor óbvia. No final do dia, parece que você está tentando trazer um modelo Xaml regredido / inferior / subdesenvolvido para o modelo Xaml estabelecido e superior, o que simplesmente não faz nenhum sentido.

Para casos de uso em WinForms, MFC, etc., sim, essa abordagem faz sentido para WinUI3.0. No entanto, com o WPF, ele tem um modelo de apresentação superior e paradigma de desenvolvedor / designer que simplesmente não foi correspondido por nenhuma outra iniciativa da MSFT ou de fornecedores externos.

@Mike-EEE, com base na conversa de Scott Hunter , parece-me, o que pode estar errado, que o objetivo de "UM BCL para governar todos" tem uma prioridade mais alta do que "Uma IU para governar todos".

Ao substituir o MONO subjacente Xamarin Forms XAML e UNO XAML na Web por meio de Web assembly por um BCL comum que tem AoC, aplicativos baseados em Xamarin Forms XAML, o Uno XAML na Web TODOS SE BENEFICIARÁ do desempenho de velocidade.

Este desempenho de velocidade É CRÍTICO para qualquer pessoa que se preocupa com o futuro de sua carreira investindo em C # para plataforma cruzada em visualizações de intensa competição proveniente de outras tecnologias, por exemplo, flutter, reagir etc.

Esperançosamente, nesta jornada em direção ao .NET5 = um BCL comum para governar todos eles , a padronização do XAML é cuidada, parcial ou completamente, ao longo do processo, MAS não o objetivo principal do .NET5.

Outra prioridade além da necessidade de padronização XAML é a disseminação da marca Microsoft por meio de design fluente para todas as plataformas (móvel, desktop e web). [Em termos técnicos, desacoplamento por meio do Win UI 3.0, que sempre nos pedem para focar no propósito do roteiro do WinUI 3.0]

NO FINAL, a quantidade de UWP, que o Win UI origina, realmente desempenha um papel neste ÚNICO BCL PARA ORDENAR TODOS EM NOV2020, quando o .NET5 for lançado, TAMBÉM NÃO É um objetivo de alta prioridade na minha opinião.

Do ponto de vista do marketing, infelizmente não traduzido em tecnologia que nos preocupa profundamente, é que a marca da Microsoft por meio de design fluente é onipresente e o aplicativo que promove esse design é RÁPIDO EM TODOS OS LUGARES.

É assim que vejo a estratégia de longo prazo da Microsoft de "conquistar a participação no mercado" devido à falta de presença móvel.

Isso é óbvio, exceto que eu vejo um potencial muito maior está em Hololens 2 e além. Para isso, PRECISAMOS ASSEGURAR QUE OS APPS UWP com WinUI 3.0 venham com controles de diagrama 3D e visualizador de modelo 3D avançado.

Desculpe pessoal, eu continuo empurrando isso porque quero usar o tempo limitado que tenho na MELHOR DA MELHOR TECNOLOGIA. :-)

Em relação ao período de transição WinUI 3.0

Eu sugeriria que a Microsoft trabalhasse diretamente com os mantenedores do Windows Community Toolkit (alguns dos quais trabalham para MS) para:

1. Teste para ver se há algum obstáculo imprevisto ao redirecionar o kit de ferramentas para WinUI 3.0 (incluindo o aplicativo de amostra).
2. Teste a renomeação automática de namespace por meio do Visual Studio ou "outra ferramenta" para ver como funciona.
3. Relate publicamente como foi o processo (postagem no blog / problema no GitHub / o que você quiser).
4. Forneça um pedaço de texto copiado e colado sobre WinUI 3.0 e a transição que os mantenedores do projeto podem anexar a seus GitHub / Nuget / outros Leia-me, ou pelo menos um URL com informações concisas sobre ele. Isso ajudará a fazer com que todos os usuários desses projetos se familiarizem rapidamente com o WinUI 3.0 e explicará o que eles precisam fazer para concluir a transição.
5. Descreva um processo de transição sugerido e um cronograma que os mantenedores do projeto / biblioteca podem escolher adotar.

Em relação ao último item, este deve abranger sugestões como:

• Crie um novo número de versão principal indicando que ele deve ser usado com aplicativos WinUI 3.0 (como WCT v6.0).
• Opcionalmente (?) Crie um branch para conter o código legado que oferecerá suporte a projetos que ainda não foram atualizados para o WinUI 3.0.
• Forneça um período de tempo (por exemplo, 3/6/12 meses) durante o qual o suporte para projetos legados será fornecido (por exemplo, correção de bugs de fusão e outros do branch principal). Isso poderia ter datas específicas para 'sincronizar' o período de suporte entre os projetos / bibliotecas da comunidade.

Por último, acho que será importante identificar o que pode ser feito se você precisar oferecer suporte ao Windows 10 versão 1507 e 1607 LTSB. Estas são as únicas 2 versões com suporte do W10 que estarão disponíveis e com as quais o WinUI 3.0 não será compatível no momento do lançamento.

Originalmente, eu iria sugerir testar o processo com a Calculadora do Windows 10, já que é um aplicativo de código aberto de qualidade de produção. No entanto, percebi que esse aplicativo precisa ser executado em 1507 e 1607 LTSB por mais 6 a 7 anos. Obviamente, haverá alguma controvérsia em torno do suporte a esses tipos de aplicativos, especialmente quando se trata de projetos comunitários menores. Se eles realmente precisam desse suporte, uma estratégia clara de longo prazo sobre como fazê-lo deve ser fornecida.

Em relação ao WinUI 4.0 / 3.x / vNext

Como os comentários aqui indicam, a comunidade tem uma longa lista de desejos para versões futuras do WinUI. Devemos realmente capitalizar sobre o ímpeto e o entusiasmo que estão sendo construídos aqui, documentando publicamente alguns dos planos de mais longo prazo.

Como a maioria desses itens está fora do escopo da v3.0, acho que um novo problema deve ser criado mais cedo ou mais tarde para começar a coletar feedback da comunidade sobre WinUI 4.0 / 3.x / vNext. No mínimo, isso ajudará a identificar os tipos de trabalho que a equipe WinUI está considerando e o que está fora do escopo do WinUI e / ou a responsabilidade de outras equipes MS.

Um exemplo do último ponto - eu realmente gostaria de ver essas coisas:

• Suporte .NET Core 3.0 para projetos UWP (responsabilidade da equipe .NET, pelo que entendi)
• Suporte total para aplicativos do Windows (UWP e Win32) do Visual Studio App Center (obviamente, não é algo pelo qual a equipe WinUI é responsável)
• Diretrizes mais concretas do Fluent Design, semelhantes ao que você pode encontrar nos documentos do Material Design (novamente, responsabilidade separada da equipe)
• Uso de WinUI 3.0 e design Fluente nos aplicativos W10 embutidos (equipes separadas e alguns desses aplicativos precisam oferecer suporte a versões LTSB)

Ao identificar esses itens fora do escopo, podemos redirecionar a comunidade para os pontos adequados de feedback e / ou explicar o que está acontecendo nessas áreas.

Fora dessas coisas, a lista de desejos dentro do escopo pode começar a se formar, e a comunidade pode começar a mostrar seu apoio para o que eles querem do WinUI no futuro.

Seria ótimo se o F # tivesse um suporte equivalente ao C #, por exemplo, tendo os mesmos modelos de projeto do C #.

Gostaria que o WinUI (UWP vNext) tivesse um objeto Window adequado como o WPF tinha, com os métodos Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency e Show () / ShowDialog ().

(_Não tenho certeza de como esta janela funcionaria (ou seria permitida) em aparelhos de tela pequena, como telefones celulares e IoT_)

@TonyHenrique há uma nova API de janelas para UWP em 1903, mas está longe de estar concluída.

Está examinando novamente a renderização de XAML no escopo do WinUI 3.0.

As coisas que sinto que estão um passo abaixo da renderização do WPF são:

• O texto não usa ClearType, em vez de favorecer o anti-aliasing da escala de cinza;
• Falta de precisão de pixel para coisas como traços de borda;

Posso entender quando o Windows Phone 7 e o Windows Phone 8 tiveram que compartilhar um sistema de renderização - o tipo de tecnologia de tela e a velocidade de renderização estavam levando a um melhor desempenho. Mas com o WinUI girando primeiro para a área de trabalho e exibições maiores - talvez seja a hora de restaurar essas qualidades para o mecanismo de renderização XAML.

E se coisas como Hololens e Xbox requerem consideração especial, por que não oferecer um modo de desempenho que pode ser ativado no nível da plataforma nos dispositivos que precisam de renderização como agora?

E o modelo f #?

A menos que funcione imediatamente em formulários padrão do Windows e modelos de projeto WPF direcionados ao .NET Framework 4.5 ou mais recente, não podemos adotar a biblioteca WinUI.

Exigir apenas a versão mais recente do Windows 10 e / ou aplicativo UWP é um obstáculo para a adoção do design Fluent.

Eu sugeriria que a Microsoft trabalhasse diretamente com os mantenedores do Windows Community Toolkit (alguns dos quais trabalham para MS)

@kmgallahan
Ótima sugestão! Isso está definitivamente no plano. Nossa equipe costuma trabalhar em estreita colaboração com os mantenedores do Windows Community Toolkit e é uma das coisas que gostaríamos de usar como um projeto de teste.

Está examinando novamente a renderização de XAML no escopo do WinUI 3.0.

@mdtauk
Qualquer alteração de renderização provavelmente está fora do escopo do 3.0, mas abra um problema para que possamos revisitar a ideia em versões subsequentes. Um grande foco foi definitivamente o desempenho universal que, como você observou, levou a algumas alterações de renderização no Windows 8+. A chave do modo de desempenho é uma ideia interessante.

E o modelo f #?

@edgarsanchez , @khoshroomahdi
Parece que estamos recebendo muito interesse no F #! Gostaríamos muito de saber por que você deseja o F #: sinta-se à vontade para comentar na edição do F # sobre por que você o deseja e para que o usaria: # 740

A menos que funcione imediatamente em formulários padrão do Windows e modelos de projeto WPF direcionados ao .NET Framework 4.5 ou mais recente, não podemos adotar a biblioteca WinUI.

@jozefizso
Você já olhou para as ilhas Xaml? Este recurso permite usar WinRT Xaml em aplicativos WPF e Windows Forms para que você possa começar a aprimorá-los com visualizações / páginas Xaml modernas:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

Estamos planejando que o WinUI 3.0 inclua ilhas e seja compatível com as versões anteriores do Creators Update e mais recentes, que são pelo menos as últimas 5 versões do Windows.

Será que Xaml Islands está trabalhando na atualização de criadores e mais recente com o WinUI 3.0 para atender às suas necessidades?

Qualquer alteração de renderização provavelmente está fora do escopo do 3.0, mas abra um problema para que possamos revisitar a ideia em versões subsequentes. Um grande foco foi definitivamente o desempenho universal que, como você observou, levou a algumas alterações de renderização no Windows 8+. A chave do modo de desempenho é uma ideia interessante.

Feito # 768

As ilhas XAML requerem o Windows 10, versão 1903 e a biblioteca do Windows Community Toolkit requer que o projeto seja UWP. Isso é impossível.

As ilhas XAML requerem o Windows 10, versão 1903 e a biblioteca do Windows Community Toolkit requer que o projeto seja UWP. Isso é impossível.

O WinUI 3.0 não vai para o Windows 7/8 / 8.1 - mas esses sistemas operacionais chegarão ao fim da vida em breve. E você ainda pode usar WPF e WinForms para eles por enquanto. Isso é para quando seus usuários mudaram para o Windows 10

Nesse caso, o projeto será UWP para Windows 10, portanto, não há motivo para oferecer suporte a WPF / WinForms. Isso é apenas se mover em um círculo e fragmentar as ferramentas do desenvolvedor.

@jozefizso Mais preciso dizer que o UWP está mudando para permitir que seja mais parecido com WPF e WinForms, e a IU XAML está se aproximando das plataformas WPF e WinForms.

Aplicativos UWP com IU XAML moderna saindo da sandbox restritiva e capazes de se conectar às plataformas WPF e WinForms.

É assim que eu entendo.

Ilhas XAML requerem Windows 10, versão 1903

Nesse caso, o projeto será UWP para Windows 10

Com o WinUI 3.0, planejamos disponibilizar ilhas em 1703 e posteriores (muito mais atrás).

Também estamos trabalhando para que o WinUI seja utilizável com um modelo de aplicativo Win32 em vez de UWP (informalmente sendo chamado de "desktop WinUI"), de forma que não seja necessariamente um aplicativo UWP.

Também estamos trabalhando para que o WinUI seja utilizável com um modelo de aplicativo Win32 em vez de UWP (informalmente sendo chamado de "desktop WinUI"), de forma que não seja necessariamente um aplicativo UWP.

Isso é o que estou mais animado. Um aplicativo nativo com a API completa do Windows disponível, seja Win32 ou Windows Runtime, capaz de ter interface do usuário de alto desempenho via Xaml.

Também estamos trabalhando para que o WinUI seja utilizável com um modelo de aplicativo Win32 em vez de UWP (informalmente sendo chamado de "desktop WinUI"), de forma que não seja necessariamente um aplicativo UWP.

Isso é o que estou mais animado. Um aplicativo nativo com a API completa do Windows disponível, seja Win32 ou Windows Runtime, capaz de ter interface do usuário de alto desempenho via Xaml.

Pegue um aplicativo WinForms, mantenha o codebehind, mas substitua o Form por uma janela XAML e tenha acesso a todos os pincéis e controles XAML.

O WPF seria um pouco mais complicado de usar apenas o WinUI XAML no lugar - mas pelo menos os controles do WPF poderiam ser estilizados para corresponder aos do WinUI

1. O namespace deve ser renomeado. "Xaml" não é apropriado porque Xaml se refere a uma linguagem de marcação, que está sendo usada incorretamente como linguagem de marketing (que muda com frequência) para componentes UWP nativos. "Xaml" deve ser substituído por "WinUI". Você pode ver quanta confusão é causada até mesmo neste thread, onde muitas vezes não está claro se "Xaml" se refere à linguagem .xaml ou aos componentes da interface do usuário.
2. Na medida em que isso aproxima o WPF e o UWP, isso é bom. Cada um deles tem recursos que não estão presentes no outro e faz sentido ter uma "IU do Windows" que combine os dois. Pode haver alguma duplicação de recursos, mas também pode ser um caminho de transição WPF -> UWP.
3. A dissociação das versões do Windows faz sentido, mas também é normal assumir um Win10 relativamente atualizado, dado que o Win7 já terá passado do EOL quando este trabalho for concluído.

Xaml é o nome da estrutura de interface do usuário. Daí Windows.UI.Xaml ...

Xaml é o nome da estrutura de interface do usuário

Xaml era uma tecnologia em WPF que permitia aos desenvolvedores descrever e construir poderosamente não apenas cenas de apresentação em seus aplicativos, mas os próprios aplicativos. Ou seja, você pode descrever os elementos da IU _ assim como os POCOs_. Se fosse .NET, poderia ser descrito com detalhes com Xaml e carregado em um contexto de aplicativo.

Para que não esqueçamos (e parece que esquecemos) que Xaml significa eXtended Application Markup Language, o que significa que é uma linguagem de marcação que permite que você descreva de forma elegante e eficiente os componentes do .NET _application_. Embora tenha sido usado principalmente para descrever os elementos da interface do usuário, na prática não foi rebaixado ou restringido como tal.

Pessoalmente, acabei usando Xaml para descrever toda a configuração do meu aplicativo, removendo e substituindo App.config - e sim, até mesmo Web.config - a complexidade, exceto em casos de APIs externas que absolutamente a exigiam.

Xaml é _não_ UI. Eles são dois conceitos totalmente diferentes, mas infelizmente foram combinados há anos sob o UWP. Eu, pelo menos, adoraria ver o termo "Xaml" desvinculado desses esforços, mas não estou muito confiante de que tais medidas seriam consideradas, muito menos tomadas.

@charlesroddie Eu meio que concordo que a nomenclatura é realmente arbitrária. Apenas uma tangente, se você alguma vez inspecionar os rastros de pilha de coisas originadas no namespace WUXaml, é na verdade internamente em um namespace DirectUI. Adoraria saber a história do Win8 se alguém aqui estivesse por perto naquela época, porque imagino que tenha sido uma história diferente. DirectComp para camadas de composição, DirectManipulation para rolagem suave e faixas elásticas e, em seguida, Direct2D / DirectWrite como o mecanismo de gráficos vetoriais com DirectUI na parte superior para reunir tudo. Então, por algum motivo, parte dele foi portado de volta para Win7, apenas os bits Xaml foram expostos por meio do sistema WinRT, enquanto todas as outras APIs foram deixadas como interfaces de comunicação criptografadas com fábricas e padrões estranhos que você precisava para ver exemplos explicando como invocar.

Na verdade, pensando bem, seria muito bom se, assim como o WUComposition expôs DirectComp e DirectManipulation por meio do WinRT (ou é uma reescrita), o Direct2D / DirectWrite também tivesse uma casa formal aqui. Todos eles trabalham juntos para permitir vários níveis de escotilhas de fuga e pontos de contato de fidelidade, se você estiver procurando por isso. O Win2D está realmente incompleto e também não é uma boa API.

Windows.UI.Composition é uma reescrita de DirectComposition, eu acredito. As APIs são semelhantes, mas não iguais.

Pare de assumir que todos os monitores são mais sRGB.
Trate todas as cores de aplicativos legados como sRGB e faça a conversão para cada monitor durante a composição.

Isso pode ser um pouco fora do tópico, mas suponha que você já tenha um grande appliation Win32 escrito em C ++, você deseja modernizar o sistema de interface do usuário, então você pode querer usar WinUI ou Comp com dependência mínima, como usar Comp apenas sem in conjunto de controle de caixa, ou mesmo sem XAML .

Isso já é possível agora, não precisamos esperar pelo WinUI 3.0 para isso.

Obrigado a todos pelo feedback sobre nomenclatura. Conforme observado, hoje temos uma distinção entre a "plataforma Xaml" e a "linguagem Xaml" (com suas próprias especificações / dialetos diferentes), o que pode ser confuso. Não acho que uma grande mudança de marca esteja nos cartões, mas definitivamente estamos discutindo nomes e namespaces.

Use Windows.UI.Composition em um aplicativo C ++ Win32 sem XAML para modernizar os aplicativos existentes (como o Photoshop). Eles já têm uma arquitetura de IU.

Isso pode ser um pouco fora do tópico, mas suponha que você já tenha um grande appliation Win32 escrito em C ++, você deseja modernizar o sistema de interface do usuário, então você pode querer usar WinUI ou Comp com dependência mínima, como usar Comp apenas sem in conjunto de controle de caixa, ou mesmo sem XAML.

Obrigado pelo feedback sobre isso - eu acho que isso deve ser possível no final com WinUI 3, semelhante a um aplicativo "sem estrutura" usando Windows.UI.Composition que você já pode fazer hoje. Manteremos isso em mente enquanto determinamos como estruturar o (s) pacote (s) e dependências do NuGet WinUI.

Pare de assumir que todos os monitores são mais sRGB.
Trate todas as cores de aplicativos legados como sRGB e faça a conversão para cada monitor durante a composição.

@reli-msft você poderia abrir um problema separado para rastrear isso?

@jesbis 👉 # 67

A Apple anunciou hoje o SwiftUI ...

Que tal se o Xaml Direct recebesse modelos do Visual Studio para permitir que os desenvolvedores optassem por fazer aplicativos usando código em vez de XAML e code behind.

Não acho que uma grande mudança de marca esteja nos cartões, mas definitivamente estamos discutindo nomes e namespaces.

Obrigado @jesbis , agradeço por estar tão envolvido neste tópico. Normalmente, parece que alguém fará uma postagem / anúncio como este e depois o deixará morto (ou para que outros gerenciem de maneira esparsa), então é encorajador ver que você, como autor do tópico, não está apenas engajado, mas também atento a o que os outros estão dizendo. Especialmente quando esses outros são _me_. 😆

E você está certo: existe a 1) plataforma de interface do usuário e 2) o mecanismo de linguagem / marcação / descrição. Em minhas observações críticas, direi que nunca dou crédito suficiente para a (primeira) plataforma de interface do usuário, pois sei que tem havido um grande trabalho da equipe do Windows em torno disso. Isso nunca foi motivo de preocupação para mim, pessoalmente. É a segunda área que atrai minha ira e consternação (e de outros), e vemos isso nos problemas do UserVoice que surgiram ao longo dos anos.

Tudo isso dito, eu pelo menos pediria (imploro, mesmo 😅) para considerar mais os esforços de branding para melhor categorizar essas duas esferas. Acho que "Xaml Direct" é o auge da confusão aqui, já que o nome implica "Linguagem de marcação" - está bem no nome! - mas não há nada disso em seu uso real. Terrivelmente confuso e enganoso, e no limite do abuso de marca, eu diria.

E por falar em Xaml Direct, @mdtauk :

Que tal se o Xaml Direct recebesse modelos do Visual Studio para permitir que os desenvolvedores optassem por fazer aplicativos usando código em vez de XAML e code behind.

Algo como CSharpForMarkup ?

Um nome muito melhor e adequado do que Xaml Direct, eu sugeriria. Claro, _qualquer_ nome seria. 😉

E por falar em Xaml Direct, @mdtauk :

Que tal se o Xaml Direct recebesse modelos do Visual Studio para permitir que os desenvolvedores optassem por fazer aplicativos usando código em vez de XAML e code behind.

Algo como CSharpForMarkup ?

Um nome muito melhor e adequado do que Xaml Direct, eu sugeriria. Claro, _qualquer_ nome seria. 😉

@ Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Ele é projetado para middleware para escrever IU XAML a partir do código, mas e se houvesse modelos para usá-lo em vez de arquivos XAML? Apenas um pensamento para colocar lá ...

@mdtauk SIM! O SwiftUI se parece com o Xaml, mas feito em código. Eu realmente amo a ideia de tudo em código da maneira como o React faz. É uma espécie de velha escola dividir seus arquivos de design e, em seguida, vinculá-los a algum tipo de code-behind, e acho que isso torna difícil de manter.

Um amigo acabou de mencionar que eles precisam do mecanismo de layout SwiftUI para funcionar com a tela de 120 Hz do iPad Pro. Então é nisso que eles estão focados. Muito fascinante, na verdade.

Eu fiz uma nova edição # 804 onde a discussão sobre mudanças inspiradas no SwiftUI poderia ir @ eklipse2k8

NÃO SE

Deixe o WPF construir as camadas inferiores do _on_ WinUI 3!

@ reli-msft que benefícios você gostaria de obter com a atualização do WPF?

Se houver recursos WPF específicos nos quais você confia e que gostaria de ver no WinUI, adoraríamos saber mais no tópico "Recursos WPF que deveriam estar no WinRT [WinUI]": https://github.com/microsoft / microsoft-ui-xaml / issues / 719

Fechamento em favor do novo problema fixado # 888

Estou realmente ansioso por isso. Resolverá muitos problemas, especialmente relacionados à versão.

@weitzhandler [em 16 de maio de 2019

Para mim, todos os detalhes técnicos são menos importantes.
UWP, WPF ou qualquer estrutura apenas do Windows, por mais incrível que seja, não vai ser suficiente, desde que não seja executado em todas as plataformas (pelo menos Windows, Droid, iOS e web) e seja amigável com qualquer tamanho de tela.

De acordo com WinUI e XAML em geral, adoraria ver melhorias nos seguintes aspectos, alguns dos quais considero irritantes e tornam meu trabalho mais lento.

• MUITO mais conversores embutidos Deve haver uma tonelada de conversores, alguns dos quais devem até ser usados ​​como uma extensão de marcação para reduzir o detalhamento. Isso também deve incluir a negação de ação aritmética simples, objeto para conversor booleano (falso por valor semântico, ou seja, string vazia, coleção vazia, visibilidade oculta etc. por contexto).
• O mesmo que acima, mas com comportamentos. Deve haver uma porta fácil entre vinculação e eventos / ações. Seria muito mais fácil se isso fosse integrado e não deixasse o desenvolvedor em dúvida sobre qual NuGet não testado usar.
• Todas as coisas que faltam no WPF, como alguns tipos de ligação, extensões de marcação, visualizações genéricas e outros.

Obrigado!

MUITO mais conversores integrados

Desde a máquina analítica de Babbage e a teoria da computação universal de Turing, é possível que um único computador execute qualquer programa que qualquer computador possa executar. Você quer voltar a uma época em que temos que criar um novo computador para cada cálculo que você deseja fazer.

Todo o negócio de conversores deve ser abandonado sem cerimônia.

objeto para conversor booleano

booleanos são booleanos. Outros objetos não são booleanos. E não há conversão natural de objetos em booleanos. Os tipos são importantes em .Net e outros sistemas não digitados não devem ser expostos aos usuários.

Sim, e os sistemas não tipificados existentes, como ligações, também devem ser descartados.

Todo o negócio de conversores deve ser abandonado sem cerimônia.

Quero dizer, quais são suas alternativas?
Meu ponto problemático com os conversores é apenas que você mesmo precisa reescrevê-los / escolher a partir do NuGet, e que eles são tão prolixos. Além de não serem flexíveis, não permitem expressões como aritmética ou negação, etc.

booleanos são booleanos. Outros objetos não são booleanos.

Você está certo, mas quando se trata de interface do usuário, isso realmente não importa.
Você quer mostrar / ocultar coisas com base no estado convencional do objeto. Nem tudo deve ter uma propriedade de visibilidade dedicada.

sistemas não tipificados existentes, como ligações, também devem ser descartados.

Huh? Na verdade, acho que tem uma vantagem. O acoplamento fraco entre V e VM pode ser bom.

sistemas não tipificados existentes, como ligações, também devem ser descartados.

O acoplamento fraco entre V e VM pode ser bom.

Para projetos pequenos, talvez, mas há abstrações melhores para acoplamento fraco do que literalmente desligar a assistência do compilador. Se você já teve que manter um grande aplicativo com dezenas a centenas de visualizações e deseja refatorar algo que pode ser usado em vários sites, não fazer com que o compilador verifique a exatidão dos caminhos de ligação é uma grande degradação na experiência do desenvolvedor. Há uma razão pela qual temos sistemas de tipos em nossas linguagens, grandes projetos são literalmente impossíveis de manter sem ferramentas para auxiliar o programador, atualmente as linguagens de interface do usuário estão ficando para trás muito.

As ligações compiladas ajudam muito para isso.

@weitzhandler , quais são suas alternativas?
... Nem tudo deve ter uma propriedade de visibilidade dedicada.
Huh? Na verdade, acho que [ligações] tem uma vantagem. O acoplamento fraco entre V e VM pode ser bom.

Em uma boa estrutura reativa, você pode definir variáveis ​​observáveis ​​(no código) como name:Mutable<string> e, em seguida, mapeá-las para let visibility = name.map(fun s -> s <> "") e, em seguida, vinculá-las para visualizar as propriedades com visibility.bind someView.set_IsVisible ou name.bind(fun s -> someView.IsVisible <- s <> "") .

Eu uso https://github.com/ReedCopsey/Gjallarhorn, mas existem várias estruturas reativas por aí.

Observe que: 1. tudo é digitado, ao contrário das ligações. 2. Coisas (funções, propriedades, visualizações) são chamadas de objetos, não passando nomes de strings ao redor, 3. funções são apenas funções, muito menos desajeitadas do que conversores, 4. boilerplate de vinculação, onde propriedades de objeto simples precisam ser fornecidas extras "propriedades vinculáveis" etc., podem ser removidas.

As visualizações ainda podem ser escritas em Xaml, especialmente se forem layouts simples, em sua maioria estáticos, com a desvantagem de strings mágicas em todos os lugares, mas a vantagem de ter um designer para fornecer uma visualização ao vivo. Melhor seria ter um código que fornecesse uma visualização ao vivo. Muito possível com um intérprete.

Por falar em frameworks reativos, verifique Chain Reactive e diga se devo abri-lo.

Olá, a equipe do ms pode resolver todos os bugs / recursos do uservoice ?
Se o fizesse, seria um grande passo, mais do que WinUI 3.0.

@ hupo376787 Acho que você recebeu downvotes porque este não é o tópico para discutir a plataforma de desenvolvimento do Windows de forma mais ampla, e mesmo este repo provavelmente não é o lugar certo, já que se concentra em apenas um aspecto desta plataforma.

Mas é um problema que não há lugar para discussão aberta das plataformas de desenvolvimento do Windows em que a microsoft e os desenvolvedores podem participar, e é um problema que o grupo da microsoft relevante não mantém nenhum mecanismo de feedback, não tendo atualizado ou respondido a isso uservoice por vários anos.

@charlesroddie Sim, parece que a voz do usuário foi abandonada. Vou enviar minha voz para o Centro de Feedback. Talvez a senhora os ignore, mas farei meu trabalho.

O UserVoice está sendo totalmente desativado este mês.

Para produtos específicos, os repositórios do GitHub (como este) são o melhor lugar para feedback, já que as equipes de engenharia relevantes os estão usando ativamente.

Para feedback que não está relacionado a um produto de repo específico, use o Hub de Feedback. Há uma categoria "Plataforma de desenvolvedor" com várias subcategorias especificamente para feedback sobre APIs e ferramentas de desenvolvedor.

Eu sei que há muito histórico e feedback anterior atualmente no UserVoice (dos quais ainda vamos acompanhar), mas tanto o GitHub quanto o Hub de Feedback fornecem um caminho mais direto para nossas equipes de engenharia e rastreamento de itens de trabalho do que o UserVoice jamais poderia, então esperamos que isso deve ser uma mudança positiva. Estamos atualizando vários links de suporte e feedback.

Vemos tudo o que vem de qualquer um dos canais e realmente apreciamos os comentários e os relatórios de erros!

@jesbis OK, entendi.

Para WinForms, ao usar o novo modelo de projeto WinUI, a janela Propriedades ainda funcionará e será capaz de definir as propriedades dos controles WinUI? Posso codificar HTML o dia todo sem problemas (normalmente MVC do Asp.net), mas quando há tantas configurações disponíveis para controles, tenho gostado de usar a janela de propriedades nos últimos 20 anos.

@ Dean-NC Acho que você está perguntando sobre o designer XAML, nada de WinFoms / Windows Forms, certo? Em caso afirmativo, sim, o painel de propriedades ainda funcionará para controles WinUI quando você seleciona um item no designer XAML.

@ marb2000 Acho que ingenuamente pensei que o WinUI 3 traria os novos controles para o WinForms no sentido de que seria na maior parte do tempo, e que eu poderia ter um formulário com controles herdados e WinUI nele, e que a janela de propriedades funcionaria para controles herdados e WinUI.

Eu li a postagem inteira acima, e tenho seguido isso com muito entusiasmo (como um desenvolvedor WinForms), mas acho que não entendi o fluxo de trabalho de alto nível de como isso funcionará (novamente, do ponto de vista do WinForms )

Eu disse há muito tempo que WinForms ainda pode ser uma coisa ótima nos próximos anos, mas sua maior fraqueza é que seus controles básicos parecem desatualizados (a caixa de texto não permite preenchimento, por isso parece fino, pequeno botão de rádio e caixa de seleção , etc.). Apenas os princípios básicos dos controles do Win 10 (caixa de texto, rádio, caixa de seleção) já ajudariam muito a trazer uma nova vida ao WinForms.
Existe algum artigo, ou você se importa em dar uma breve descrição de como seria o fluxo de trabalho para um novo projeto WinForms que deseja usar tanto os controles legados quanto os novos?
Obrigado.

@ marb2000 Acho que ingenuamente pensei que o WinUI 3 traria os novos controles para o WinForms no sentido de que seria na maior parte do tempo, e que eu poderia ter um formulário com controles herdados e WinUI nele, e que a janela de propriedades funcionaria para controles herdados e WinUI.

Eu li a postagem inteira acima, e tenho seguido isso com muito entusiasmo (como um desenvolvedor WinForms), mas acho que não entendi o fluxo de trabalho de alto nível de como isso funcionará (novamente, do ponto de vista do WinForms )

Eu disse há muito tempo que WinForms ainda pode ser uma coisa ótima nos próximos anos, mas sua maior fraqueza é que seus controles básicos parecem desatualizados (a caixa de texto não permite preenchimento, por isso parece fino, pequeno botão de rádio e caixa de seleção , etc.). Apenas os princípios básicos dos controles do Win 10 (caixa de texto, rádio, caixa de seleção) já ajudariam muito a trazer uma nova vida ao WinForms.
Existe algum artigo, ou você se importa em dar uma breve descrição de como seria o fluxo de trabalho para um novo projeto WinForms que deseja usar tanto os controles legados quanto os novos?
Obrigado.

É mais provável que você consiga pegar seu projeto de aplicativo, adicionar janelas e páginas WinUI e usar a interface de usuário XAML moderna para substituir sua interface de usuário totalmente ou pouco a pouco.

E há ilhas XAML para inserir XAML em Winforms e interfaces de usuário WPF existentes

Sua equipe do Blazor deve trabalhar com o Uno para obter alguns de seus modelos de hospedagem incluídos no Uno (em particular o lado do servidor), e / ou para obter a interface de usuário Uno (e, portanto, WinUI 3) camada de renderização / visual utilizável pelo Blazor .... e / ou talvez Ilhas Xaml para Blazor?

Eu me sinto um pouco desconcertado aqui, porque a maior parte do feedback vem de desenvolvedores que trabalham principalmente no espaço xaml. Eles geralmente parecem estar procurando uma versão melhor do que já possuem. Isso pode ser bom para usuários existentes, mas não sei se puxará muitos desenvolvedores que evitaram o UWP até o momento.

Minha equipe desenvolveu apenas 1 aplicativo UWP. Não estaremos mais desenvolvendo.

O obstáculo intransponível é a falta de um redator de relatório tabulado integrado. Testamos todos os redatores de relatórios terceirizados no mercado que afirmam apoiar UWP. Infelizmente, nenhum deles funciona bem com UWP. Sua oferta UWP é geralmente um hack rápido de sua variante WPF / WinForms e não funciona corretamente.

Usamos Stimulsoft Reports em nosso produto UWP. É muito problemático e eles nos disseram que não irão consertar os bugs, pois a aceitação de UWP é muito baixa.

Vejo que você tem visualização de dados na lista. Mas a razão pela qual ainda existem milhões de aplicativos cinza de batalha naval é que muitas empresas não se importam muito com o visual de aplicativos internos. Eles querem colunas de números com subtotais.

Portanto, se o WinUI pretende finalmente atrair os formulários sobre os desenvolvedores de dados, precisamos de um redator de relatórios tabulados integrado.

Espero que isso não ofenda as pessoas visuais :-)

Eu concordo totalmente. Como podemos desenvolver aplicativos de negócios modernos sem um sistema de relatórios que possa ser facilmente integrado ao aplicativo? é um enorme desfiladeiro que impedirá os desenvolvedores de se moverem.

Os usuários de negócios precisam ser capazes de interagir com dados tabulados e, em seguida, imprimi-los ou exportá-los para outros formatos. Eles também precisam ser capazes de criar faturas, orçamentos, extratos e outros documentos instrumentais.

É meu entendimento que os negócios / empresas ainda são os maiores consumidores do Windows. Por que algo tão fundamental para o ecossistema do Windows não está sendo desenvolvido para UWP?

Obrigado pelo feedback @VagueGit e @Elmarcotoro ! Os controles corporativos são uma lacuna para nós agora. Mas seu tempo é bom, estamos coletando feedback para o projeto de um controle DataGrid. Por favor, leia e dê feedback aqui: # 1500.

Da mesma forma, ao lado do controle de dados tabulares quadrados, precisamos de um controle de gráfico UWP de código aberto para democratizar de forma criativa a maneira de compartilhar relacionamentos complexos por meio do controle de diagrama

Para um sistema de relatórios, acho que Telerik UI é a melhor escolha atualmente. Um provérbio chinês que diz "Algumas pessoas se especializam em algumas profissões, enquanto outras em outras profissões.". Telerik, DevExpress ou outra pessoa são bons em reportagem.

Pela falta de vários controles, não devemos culpar essa equipe, mas sim toda a estratégia do MS. Desde o começo da Satya abandonaram o mobile, eles preferiram iOS e Android, pois chefes como eles. Todo o ecossistema UWP se torna cada vez mais fraco.

Por enquanto, há um argumento chamado "UWP está morto" no Twitter, acho que o MS deveria esclarecer isso e declarar seu caminho uwp.

Por enquanto, há um argumento chamado "UWP está morto" no Twitter, acho que o MS deveria esclarecer isso e declarar seu caminho uwp.

Você acabou de postar isso no tópico do roteiro ...

@jevansaks Obrigado pela informação sobre o controle Datagrid. Isso não trata das questões de impressão de relatórios e paginação, exportação e tal. Esses são cenários de negócios da vida real que precisam ser tratados, não se algum botão é animado (por mais legal e legal que isso possa ser).

@ hupo376787
"Para um sistema de relatórios, acho que Telerik UI é a melhor escolha atualmente."

Pelo que posso ver, Dev Express são os únicos que fornecem atualmente uma pilha completa para criar e visualizar relatórios para UWP, e seus preços parecem ser premium. Todos os outros, incluindo a Telerik, têm lacunas em suas ferramentas, o que significa que os relatórios para UWP não podem ser criados. Estou disposto (esperando) ser corrigido sobre isso.

Para um sistema de relatórios, acho que Telerik UI é a melhor escolha atualmente. Um provérbio chinês que diz "Algumas pessoas se especializam em algumas profissões, enquanto outras em outras profissões.". Telerik, DevExpress ou outra pessoa são bons em reportagem.

@ hupo376787 por favor, tome cuidado extra para verificar seus fatos antes de sugerir que uma postagem está incorreta. Telerik Reporting tem um designer de relatório para WPF e WinForms, mas não UWP.

DevExpress também tem um designer de relatório para WinForms e WPF, mas não UWP

Portanto, verifique seus fatos antes de cometer um erro que será preservado para sempre e amplamente divulgado. Ei, isso parece um velho provérbio um dia 😉

@ hupo376787 por favor, tome cuidado extra para verificar seus fatos antes de sugerir que uma postagem está incorreta. Telerik Reporting tem um designer de relatório para WPF e WinForms, mas não UWP.

DevExpress também tem um designer de relatório para WinForms e WPF, mas não UWP

Portanto, verifique seus fatos antes de cometer um erro que será preservado para sempre e amplamente divulgado. Ei, isso parece um velho provérbio um dia 😉

OK, acho que temos um entendimento diferente sobre Relatórios. Quero dizer https://www.telerik.com/universal-windows-platform-ui e https://www.devexpress.com/products/net/controls/win10apps/.

Eu estava incorreto, Dev Express não fornece relatórios para UWP. Parece que nenhum desenvolvedor de ferramentas de terceiros faz! Entrei em contato com o Dev Express por meio de seu bate-papo, para saber se eles tinham um roteiro para fornecer relatórios para UWP.
Eles disseram,
"O XtraReports Suite usa a funcionalidade fornecida pelo assembly System.Drawing e o que nos impede de implementar o mesmo conjunto de ferramentas para aplicativos de janela universal é que esse assembly não está disponível lá (https://stackoverflow.com/questions / 31545389 / windows-universal-app-with-system-drawing-and-possible-alternative). Portanto, ainda não estabelecemos nossos planos futuros nesta área. "

@jevansaks , parece que há uma falta de comunicação entre a equipe de IU da Microsoft e esses fornecedores de ferramentas de terceiros. Ficaríamos felizes em usar ferramentas de terceiros, mas parece que a plataforma UWP torna difícil para essas empresas integrar as ferramentas que possuem para outras plataformas na UWP.

Eles me pediram para entrar em contato com seu [email protected] com nossos requisitos de relatórios. Pode ser útil para a equipe do Win UI 3.0 entrar em contato com eles e ver se há uma maneira de ajudá-los na implementação. Não vejo como você obterá desenvolvedores de negócios na plataforma universal sem as ferramentas de relatório adequadas.

https://www.devexpress.com/subscriptions/reporting/

Relatórios: apenas da perspectiva do WinForms, usei o Telerik e o DevExpress (até mesmo suas versões mais recentes) e, embora o Telerik fosse bom, acho que o DevExpress não só tem um designer e experiência geral melhores, mas tem muitos recursos mais sutis que me permitiu fazer layouts mais complexos do que Telerik. Acho que a tecnologia de renderização DevExpress é mais avançada.

pode ser útil para a equipe do Win UI 3.0 entrar em contato com eles e ver se há uma maneira de ajudá-los na implementação.

Obrigado pela chamada. Também entraremos em contato com eles.

Obrigado pela chamada. Também entraremos em contato com eles.

Pode valer a pena conversar com todos eles e ver quais são os bloqueios? Telerik, Grapecity, DevExpress etc.

Obrigado pela chamada. Também entraremos em contato com eles.

Pode valer a pena conversar com todos eles e ver quais são os bloqueios? Telerik, Grapecity, DevExpress etc.

Com certeza, esse é o nosso plano.

Somos um pouco diferentes da maioria dos desenvolvedores que criam para o Windows. Desenvolvemos principalmente aplicativos de quiosque (aplicativos destinados a serem executados por usuários que não sejam o proprietário do computador, e normalmente em tela inteira sem qualquer acesso ao sistema mais amplo). Os aplicativos geralmente são construídos de acordo com os requisitos específicos do cliente, sem intenção de distribuí-los pela loja ou equivalente.

Como os aplicativos são executados em tela inteira, há um valor muito limitado nos controles integrados que mantêm a aparência de outros aplicativos do Windows; em vez disso, eles tendem a ser altamente marcados para cada cliente. Ainda precisamos de muitos _comportamento_ e controles comuns de aplicativos padrão do Windows, mas normalmente fazemos muitas personalizações nos modelos de controle de cada um ou, pelo menos, substituímos seus estilos principais. Por muito tempo, construímos muitos aplicativos como back-ends de WinForms com front-ends de Flash incorporados para IU.

Em termos gerais, quase todos os aplicativos que escrevemos integram algum tipo de back-end baseado na web com alguma peça de hardware (por exemplo, uma impressora, um leitor de código de barras, um leitor de tarja magnética, um leitor RFID, uma câmera, hardware de pagamento com cartão, pagamento em dinheiro no estilo de venda componentes etc.), e a grande maioria desses componentes historicamente vem com SDKs do Win32 e não com UWP.

Por essas duas razões, a maioria de nossos aplicativos históricos são aplicativos WinForms, e a maioria de nossos aplicativos modernos são WPF. Construímos alguns aplicativos UWP (em grande parte para nos beneficiar dos recursos realmente interessantes de acesso atribuído / modo quiosque do Windows), mas eles costumam ser difíceis de trabalhar em comparação com o WPF, e normalmente não podemos obter SDKs de hardware compatíveis de qualquer maneira .

No entanto, estamos muito intrigados com as ilhas XAML, que nos permitem escrever aplicativos compatíveis com Win32 com IU moderna (embora a vantagem de UWP sobre WPF para nós nem sempre seja clara, especialmente se não estivermos usando controles padrão ou específicos da Microsoft efeitos como Fluente, etc.).

Para responder às suas perguntas específicas:

Quais modelos seriam mais interessantes para você?

C # com .NET Core, Win32 com WinUI 3.0 sobreposto seria bom.

Você conhecia as Ilhas Xaml para modernizar aplicativos de desktop?

Sim, e fiquei relativamente feliz com eles quando joguei com eles, embora não seja provável que usemos um controle _único_, tanto quanto tomar uma decisão para toda a IU personalizada.

A principal razão de eu estar ciente disso era porque obteríamos suporte de

Essa compatibilidade com versões anteriores expandida no Windows 10 torna as Ilhas Xaml mais úteis para você?

Na verdade; quase sempre controlamos os PCs de destino e podemos garantir que estamos sempre recebendo a versão compatível mais recente.

Ajudaria se o Visual Studio ou outra ferramenta atualizasse automaticamente os namespaces para você?

sim.

Quão importante para você é a compatibilidade total entre os componentes UWP Xaml existentes e os aplicativos WinUI 3.0?

Muito mínimo. A principal dor de cabeça de compatibilidade que teríamos seriam as chaves StaticResource alteradas para estilizar os elementos principais.

Você cria ou usa bibliotecas de controle UWP Xaml ou componentes WinRT que não podem ser facilmente recompilados e atualizados junto com o código do aplicativo?

Sim, usamos a biblioteca de controle Syncfusion UWP no passado.

Qual seria sua solução preferida para usar componentes UWP Xaml com WinUI 3?

A solução preferida seria ter mais controles padrão disponíveis no próprio WinUI, em vez de recorrer a fontes externas (por exemplo, visualizadores de documentos), mas espero que essas bibliotecas de componentes externos sejam mais progressivas na atualização de suas bibliotecas do que quando mudá-las WinUI 3 de qualquer maneira na maior parte.

O que você acha do plano geral 3.0 delineado acima e no roteiro? Isso permitiria que você usasse o WinUI para seus aplicativos do Windows novos e existentes?

Estou animado para ver os controles UWP sendo mais claramente separados do aplicativo UWP e do modelo de segurança que historicamente nos bloqueou devido a razões de compatibilidade de hardware, especialmente porque o WinUI está sendo projetado e desenvolvido de forma aberta.

Com uma orientação tão clara sobre como a Microsoft nos recomenda construir UIs de aplicativos, eu esperaria que todos os nossos aplicativos terminassem com front-ends WinUI, independentemente de qual back-end podemos oferecer suporte.

Para que tipo de aplicativo você gostaria de usar o WinUI 3.0? Criando um novo aplicativo Win32 e empacotando-o com o MSIX? Adicionando novas visualizações a um aplicativo WPF? Modernizando um aplicativo C ++ MFC com Fluent UI?

Principalmente sobre como obter acesso a bibliotecas de controles mantidas de forma mais ativa em meus aplicativos mais antigos, com documentação mais agradável e óbvia (ou até mesmo acesso ao código subjacente para o controle padrão) torna muito mais fácil descobrir quando posso adaptar um controle padrão e quando preciso lançar meu próprio controle de usuário. Por exemplo, em um aplicativo recente desenvolvido no WPF, eu tinha alguns selecionadores de data; fazer com que esse controle funcionasse bem para o toque e personalizar o tamanho, a fonte, o ícone pop-up etc. era extremamente irritante. Eu estaria inclinado a usar o WinUI para esse tipo de aplicativo _default_ no futuro, dado o roteiro acima, porque:

1. Posso estar razoavelmente certo de que há um controle seletor de data nativo que é pelo menos moderadamente amigável ao toque
2. Posso examinar os modelos nativos / originais desse controle, etc., facilmente para ver o que preciso substituir para fazer com que ele corresponda às provas de design para a aparência do cliente (como um exemplo mais ou menos representativo, talvez eu queira para descobrir a maneira mais limpa de definir o estilo do tipo - tamanho da fonte, peso, família - de um cabeçalho de controle TextBox independentemente de seu texto de entrada; o HeaderTemplate padrão usa recursos estáticos mágicos que posso redefinir ou preciso substituir o próprio modelo? Se eu substituir o modelo, qual será a aparência da marcação do modelo padrão; ela oferece / suporta algo que eu não considerei?).

Vejo que isso foi encerrado, mas há algumas questões levantadas por nossos usuários que, na minha opinião, valeria a pena abordar. Eles são melhorias de produtividade para usuários que trabalham com grandes quantidades de dados.

Caixa de texto:
Se um usuário precisar editar um TextBox, ele primeiro terá que clicar no TextBox para exibir o botão Clear e, em seguida, clicar no botão Clear para limpar o TextBox. Isso é muito ineficiente ao trabalhar com grandes quantidades de dados. Seria bom se, quando o usuário clica ou tabula no TextBox, o texto possa ser destacado e pronto para ser sobrescrito.

Gridview / ListView:
O Gridview e o ListView não parecem permitir que o usuário efetue Tab através da coleção.
O ListView permite que Tab se mova para os controles na mesma linha, mas não vai para a próxima linha de controles. Em vez disso, o ListView perde o foco e Tab se move para o próximo controle na árvore visual.

Essas são duas questões levantadas por nossos usuários como muito irritantes.

@Elmarcotoro

Eu recomendo que você crie um novo problema para cada uma das melhorias mencionadas. A equipe WinUI fará uma triagem para determinar se eles exigirão que o WinUI 3 seja lançado antes da implementação ou não.

Esse problema existia principalmente para obter feedback sobre as 2 "Perguntas gerais" no início da postagem.

Suporta o modelo de hospedagem Blazor nativo em WinUI. Isso permitiria que um controle Blazor fosse usado diretamente na web Cliente / Servidor, ou usado diretamente no WinUI. O roteiro do Blazor tem esse conceito futuro sem usar um controle WebView. Dessa forma, a IU do controle é executada de forma nativa com a parte .Net Standard do código também executando de forma nativa.

Suporte ao modelo de hospedagem Blazor nativo em WinUI

Discutido no lado do Blazor, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

Com certeza, esse é o nosso plano.

@jevansaks Seria ótimo entrar no ciclo também.

Eu gostaria de uma melhor consistência de Menus de bandeja / Menus de ícone com WinUI 3.0. Cada aplicativo tem um espaçamento diferente e os aplicativos Win32 não seguem a renderização / espaçamento / temas da fonte de forma consistente. Por favor, corrija isso já!

WinUi na área de trabalho completamente inútil para mim devido à falta de qualquer possibilidade de gerenciamento de janelas: mostrar / ocultar janelas, posição das janelas, tamanho das janelas, encaixar / desencaixar ...

@alexandrevk ainda é uma prévia. Você viu o design da API em janelas? https://github.com/microsoft/ProjectReunion/issues/157

Obrigado @dotMorten por

@alexandrevk - estamos reunindo APIs para Reunion que permitirão que você faça esse tipo de operação de janelas tanto no Win32 quanto no UWP com conteúdo WinUI, bem como ao usar outros frameworks / conteúdo de swapchain em sua janela. Alguns desses recursos de janelas podem então ser abstraídos na classe de janela WinUI para facilitar o acesso também, mas isso está mais adiante. As especificações de recursos para a área de janelas estão no tubo, fique atento.

Falando estritamente como um usuário individual (ou seja: não corporativo / empresa) e apenas c ++, mesmo que eu seja apenas uma voz solitária gritando no vazio, sinto a necessidade de dizer que, enquanto qualquer um desses novos sistemas de IU forem vinculados à UWP e àquele sistema de empacotamento horrível no qual eles se inserem, então eu temo que sempre ficará no escuro, faça o que fizer. (Falando da experiência do WinRT, ainda não experimentei o WinUI, mas parece quase o mesmo para mim).
Certamente, deve-se saber que pouco ou ninguém realmente usa aplicativos UWP? (na verdade, odiado por muitos afaik) então se vai ser chamado de 'nativo', então por que não é realmente 'nativo', ou seja: alguns #inclui, vincule um .lib ou dois e construa seu aplicativo em C ++ PADRÃO.
Ter que recorrer a coisas como Qt quando cross-plat não é uma preocupação, apenas para evitar embrulhar win32 pela milésima vez está ficando meio velho para ser justo.
Enfim só meus 2 centavos, de alguém que usa a língua todos os dias, mas provavelmente não tem lugar para comentar aqui.

@ nl-n você deve ficar feliz em saber que um dos grandes negócios com o WinUI é que ele não requer a execução como um aplicativo UWP. Na verdade, isso foi possível desde a visualização 2.
_Atualmente_ requer empacotamento como msix, mas msix é realmente uma maneira bastante decente de distribuir (e atualizar) seus aplicativos.

@dotMorten Esse é um dos grandes problemas: exigir carregamento lateral / instalação por meio da loja. Não conheço uma única pessoa que não desabilite / retire a loja antes (ou logo depois) de instalar o Windows, então como vamos distribuí-lo?
Eu sei que isso é um tanto retórico, mas serve ao ponto. Devo ser capaz de compactar o diretório de compilação e distribuí-lo (ou um instalador, se garantido).
Depois, há o problema de compatibilidade, muitas pessoas ainda se recusam a até mesmo instalar o W10, então há isso também ...
É bom, no entanto, saber que é a direção que o 3.0 está tomando, embora, por mais que eu odeie o xaml, seria uma adição bem-vinda.
Talvez pudéssemos obtê-lo sem precisar instalar toda a carga de trabalho UWP de 50 GB no VS também? 🙏 (exagerando eu sei, mas ainda assim)

Para citar @MarkIngramUK perto do início deste tópico:

É 2019, quero uma IU nativa rápida e não quero ter que pensar seriamente em criar uma interface de usuário com CreateWindowExW , GDI, etc.

que (curiosamente) estou literalmente tendo que fazer agora, e sim, é tão doloroso quanto parece :)

@ nl-n quem disse alguma coisa sobre a loja? MSIX não é realmente diferente de instalar a partir do MSI. É apenas um instalador de aplicativo. Clique duas vezes para instalar. Nenhuma loja necessária. Garante uma desinstalação 100% limpa também (ao contrário do MSI, que faz uma grande bagunça)

Eu não conheço uma única pessoa que não desative / esvazie a loja

Porém, não é comum.

como devemos distribuí-los

Em primeiro lugar, você precisa informar aos usuários para não desabilitar a loja)

Devo ser capaz de compactar o diretório de compilação e distribuí-lo

O MSIX pode ser instalado sem armazenamento. Com as versões mais recentes do Windows, o usuário não precisa habilitar nada para isso. Claro, se o pacote foi assinado antes com um certificado confiável. Mas sim, se o usuário removeu a loja do PC, ele também poderia remover o MSIX / APPX AppInstaller dele. Nesse caso, eles provavelmente não querem toda a variabilidade de aplicativos.

muitas pessoas ainda se recusam a instalar o W10,

É sua escolha. Disse Nuff.

carga de trabalho UWP de 50 GB no VS também

O SDK único tem cerca de 3 GB. Não é necessário baixar todos a partir de 10240 um.

@ nl-n quem disse alguma coisa sobre a loja? MSIX não é realmente diferente de instalar a partir do MSI. É apenas um instalador de aplicativo. Clique duas vezes para instalar. Nenhuma loja necessária. Garante uma desinstalação 100% limpa também (ao contrário do MSI, que faz uma grande bagunça)

Essa foi a descrição que o visual studio fornece, 'para sideload / instalação através da loja da microsoft', as únicas outras informações que encontrei no msix são do msdn, que basicamente diz: os pacotes do msix são aplicativos 'appx' em sandbox / virtualizados , que é praticamente um assassino para qualquer coisa que trabalhe diretamente com o winapi. E precisam de assinatura para serem instaláveis? ...

Também podem ser fios cruzados, suponho, teminologias muito diferentes, e não sei muito sobre UWP.

Porém, não é comum.

Mais comum do que você pensa, e com razão 😄

De qualquer forma, não era minha intenção atrapalhar, então vou voltar a escrever minhas coisas do CreateWindowExW por enquanto 🤣