Microsoft-ui-xaml: 👩‍💻📞 Chamada da comunidade WinUI (19 de fevereiro de 2020)

Tenho uma pergunta sobre o desenvolvimento do Windows 10X. Para desenvolver para isso preciso do emulador, quando haverá suporte para processadores AMD (virtualização aninhada)? Podemos contar com a versão Windows 10 2003?

Mais relacionado ao WinUI, baseado em # 1958, qual é o futuro do Live Tiles?

O suporte do AMD Ryzen está me impedindo de executar o emulador, então qualquer palavra sobre quando isso será retificado será bom ouvir.

@ jp-weber @mdtauk

Este é o texto oficial (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):

Os processadores AMD não são suportados no momento. A virtualização aninhada é necessária para executar o Windows 10X no emulador e o Windows ainda não oferece suporte para isso nos processadores AMD. Fique ligado!

Se quiser mais informações, você provavelmente deve entrar em contato com [email protected]. Duvido que o WinUI seja a equipe correta para fazer perguntas específicas ao Emulador.

Obrigado @ Felix-Dev - isso mesmo, os documentos são o melhor lugar para obter o status mais recente no emulador 10X e esse endereço de e-mail é o melhor contato para outras questões 10X que não são específicas do WinUI.

Muito justo, terá que esperar até que a Microsoft esteja pronta para falar sobre isso.

Olhando para o Windows 10X, os aplicativos Win32 são executados em um contêiner VEIL. E os aplicativos WinUI 3.0 não UWP?

Eles parecerão ser executados como aplicativos UWP nativos em 10X?

@mdtauk Como os aplicativos WinUI Desktop não são aplicativos UWP nativos, não acho que eles serão executados no contêiner UWP. Acredito que eles serão executados no contêiner Win32 mencionado, pois terão (todos) os recursos dos aplicativos Win32.

Também estou interessado em saber qual é o plano para o isolamento do aplicativo WinUI daqui para frente. De uma perspectiva corporativa, precisamos de isolamento / sandbox e controle de capacidade (não opt-in do usuário). Então, colocando isso aí como um tópico para o Miguel ..

@mdtauk Como os aplicativos WinUI Desktop não são aplicativos UWP nativos, não acho que eles serão executados no contêiner UWP. Acredito que eles serão executados no contêiner Win32 mencionado, pois terão (todos) os recursos dos aplicativos Win32.

Isso é um pouco decepcionante. Os aplicativos Win32 parecem exibir diferentes comportamentos de janelas e escurecem a tela quando estão em primeiro plano. Portanto, a mudança também se comporta de maneira diferente.

Usando uma IU Xaml, esperamos que um aplicativo WinUI Desktop seja o melhor dos dois cenários, pelo menos na superfície para o usuário

@mdtauk Como a imagem do emulador 10X atual liberada para nós ainda é muito recente, tenho certeza que os problemas / comportamento que você notou (eu também percebi em meus testes) serão resolvidos / alterados até o lançamento (ou seja, também tenho aplicativos Win32 que apenas não carregue agora).

Dito isso, ficarei feliz em ser corrigido no contêiner do aplicativo WinUI Desktop no 10X. Meu pensamento atual é baseado no que ouvimos sobre WinUI Desktop até agora (modelo de aplicativo Win32), a apresentação 10X How Windows 10X runs UWP and Win32 apps e aplicativos de teste de ponte de desktop. Infelizmente, meus aplicativos de teste da Ilha XAML falham ao carregar no emulador atualmente (preso no estágio App Launch Initialized ), portanto, não posso verificar qual contêiner eles usarão. Eu ficaria surpreso se não fosse o contêiner Win32, já que eles ainda são aplicativos Win32. Tudo isso me leva a acreditar que os aplicativos do WinUI Desktop serão executados no contêiner Win32 em 10X.

Certamente é uma boa pergunta para fazer à equipe!

@ Felix-Dev de acordo com o mesmo vídeo que você mencionou (Como o Windows 10X executa aplicativos UWP e Win32) aos minutos 20:18 diz que aplicativos híbridos (Win32 / UWP) não são suportados (ainda?) E, no meu entender, é um aplicativo que usa XAML Island é um aplicativo híbrido.

Q1) Quando SwapchainPanel estará disponível no WinUI? Isso é absolutamente essencial para o que eu e muitos outros fazemos.

Q2) Visto que o SharpDX não é mais suportado por seu criador, a Microsoft irá aumentar e fornecer compatibilidade entre o SharpDX e as superfícies de renderização de hardware do WinUI? A MS ao menos vê uma história para renderização de hardware com C # sem SharpDX? E eu não me importo com o Unity, quero dizer, para o desenvolvimento de gráficos de forma livre e irrestrita, para fazer nossas próprias ferramentas gráficas, motores e jogos não-Unity em C #. E também não me refiro a Win2d, eu preciso de capacidade total de renderização de hardware (DirectX).

P3) Os aplicativos não têm a capacidade de desligar os pop-ups TaskBar e TitleBar quando o mouse é movido para as extremidades superior e inferior da tela. Isso é um problema para muitos jogos (e talvez alguns aplicativos) que utilizam a borda da tela em sua própria IU para coisas como panorâmica da câmera ou pop-ups. Quando isso será corrigido (pode ser um problema do Windows, mas precisa ser orientado por uma API, por isso é relevante para o WinUI).

P4) Podemos fazer com que o WinUI inclua o modelo de aplicativo CoreWindow (IFrameworkView) para quando quisermos ignorar o Xaml e renderizar diretamente para um Swapchain vinculado à janela.

Pode parecer um pouco estranho solicitar que o WinUI forneça uma superfície não Xaml. Mas acho que CoreWindow pertence ao XamlWindow (chamado de Window em UWP) na mesma biblioteca, também separada de UWP para torná-lo disponível em .net 5. Supondo que .net 5 será capaz de direcionar não-uwp, bem como uwp. Atualmente, não existe um modelo de aplicativo C ++ moderno fora do UWP - os desenvolvedores de jogos devem usar o código c legado (Win32) para escrever camadas de aplicativos para jogos ou aplicativos gráficos. Também não existe um modelo de aplicativo de desktop moderno no núcleo .net. A solução da UWP para CoreWindow é eficaz e confortável de usar. Ele só precisa existir fora do UWP (para C ++ / não-uwp e .net 5). Outro benefício de retirar o CoreWindow do UWP é que ele fornece uma maneira de transportar o código diretamente do UWP para .net 5 (e C ++ se algum dia receber um modelo de aplicativo moderno não uwp).

Os desenvolvedores de jogos não podem usar UWP até que o comportamento das janelas seja alterado e a história de distribuição seja resolvida. Já faz tanto tempo que parece que a Microsoft nem mesmo entende o problema. Portanto, temos que tentar puxar essas APIs para fora da UWP. Se o UWP fosse corrigido, não seria necessário.

E mais comentários da edição 1215

Se você substituir a janela Win32 por CoreWindow para cenários não contidos / não Xaml e também fornecer CoreWindow para .Net 5 não UWP, poderemos ter um modelo de aplicativo / janela unificado no Windows para trabalho não Xaml. Isso faz mais sentido do que segurar o Win32 PARA SEMPRE ou inventar novos modelos de aplicativos.

Por que deveríamos ter que reescrever a camada de aplicativo apenas porque queremos alternar entre execução contida e não contida (por exemplo, entre UWP e Win32) - esse é um problema típico que os desenvolvedores de jogos enfrentam hoje, eles não podem se comprometer com UWP porque precisa de liberdade de distribuição Win32. Portanto, eles são forçados a usar modelos de aplicativos HWnd ou .Net Framework. Se o modelo de aplicativo / janela UWP foi disponibilizado para aplicativos não contidos em uwp, sem problemas, poderíamos escrever o mesmo código para a camada de aplicativo e compilar para o MS Store e outros armazenamentos da mesma base de código.

@leoniDEV Muito disso ainda é especulação sobre o que exatamente se entende por "aplicativos híbridos". Veja este tópico do Twitter, por exemplo, onde é dito que os aplicativos da Ilha XAML não pertencem a essa categoria (Matteo Pagani trabalha na Microsoft como Windows AppConsult Engineer ). Um funcionário da MS na comunidade UWP disse que o suporte para aplicativos UWP executando um processo de confiança total do Win32 não será suportado um dia 1, mas está planejado para ser adicionado mais tarde.

@ Gavin-Williams Haverá dois tipos de WinUI: WinUI UWP e WinUI Desktop. Com o WinUI UWP, você poderá criar aplicativos UWP completos que serão executados no contêiner UWP no Windows 10X. Depois, há o WinUI Desktop, que permitirá que os aplicativos Win32 tenham acesso total às APIs da IU UWP (XAML, composição, entrada, ... - excluindo algumas APIs como CoreWindow ) também. Esses tipos de aplicativos não precisam lidar com a área restrita da UWP ou outras restrições de design da UWP. Como eles não são aplicativos UWP, no entanto, seu aplicativo WinUI Desktop não será capaz de atingir a ampla gama de categorias de dispositivos do Windows 10 que um aplicativo UWP pode.
Veja a imagem abaixo tirada do roteiro WinUI para uma boa visão geral:

WinUI foi escrito em C ++ desde o início para que possa ser usado em um contexto de aplicativo não gerenciado.

Como enfatizei acima, minha escrita I believe they will run in the mentioned Win32 container é puramente baseada em meu conhecimento atual do WinUI Desktop, os aplicativos de teste de ponte de vídeo e desktop 10X que executei no 10X. Não tenho conhecimento interno. A equipe WinUI certamente nos informará qual é o plano com os aplicativos WinUI Desktop e o contêiner 10X usado e estou feliz em ser corrigido aqui e ser informado de que sim, os aplicativos WinUI Desktop serão executados no contêiner UWP no 10X.

Eu gostaria de ouvir mais sobre qualquer ideia sobre a possibilidade de usar outras linguagens de programação, como Java, Python, JavaScript etc, ao construir aplicativos usando WinUI / Microsoft UI.

Eu sei que existe um projeto chamado Xlang (cross-lang) - que essencialmente parece o que o .NET deveria ter sido, um COM melhor.

Como isso se relaciona com o WinUI?

xlang é essencialmente uma versão de código aberto para várias plataformas do Windows Runtime (WinRT), embora não fosse totalmente compatível. O objetivo do WinRT é o que você disse, interoperabilidade entre linguagens e é baseado em COM. As APIs do WinUI são construídas no WinRT, que é como ele oferece suporte a C ++ e C #. Existem outras linguagens com vários níveis de suporte para WinRT, incluindo Python , Rust (esta é uma em que eu trabalhei pessoalmente) e JavaScript , mas até onde eu sei nenhuma delas (ainda) suporta WinUI - suportar WinUI é particularmente difícil porque suas APIs de composição e XAML dependem fortemente de um recurso de sistema de tipo chamado tipos composíveis (essencialmente uma forma de herança de implementação) que outras APIs WinRT e UWP não usam e que pode ser difícil de mapear para sistemas de tipo de outras linguagens.
Kenny Kerr, o criador do C ++ / WinRT, está trabalhando em uma nova projeção Rust WinRT agora.

Na verdade, tenho pensado muito recentemente sobre como o Rust poderia dar melhor suporte a tipos composíveis (e, portanto, WinUI). Certamente é possível, mas ainda não tenho certeza de quão natural posso considerá-lo para os desenvolvedores. Basicamente, qualquer linguagem deve ser capaz de suportar WinRT se alguém trabalhar para criar uma projeção, mas dependendo do design da linguagem, às vezes pode ser difícil mapear as construções do sistema de tipos WinRT para o sistema de tipos da linguagem de uma maneira isso parece natural.

xlang parece morto para mim. C ++ / WinRT nunca foi realmente concluído - ficou com bugs e uma história de uso muito estranha, tornando-o indesejável para o desenvolvedor médio. Lutei por muitas e muitas horas para fazer o C ++ / WinRT funcionar e não consegui fazer o que fiz em 30 minutos com C ++ / CX. E C ++ / CX era muito mais fácil de usar. Se a Microsoft deseja que essas ferramentas de linguagem cruzada sejam utilizáveis ​​pelo Joe Médio, eles precisam colocar uma equipe de pessoas para resolver o problema e não deixar que Kenny Kerr faça todo o trabalho sozinho. Ele tem ótimas ideias. Mas essas ferramentas precisam de amplo apelo, e acho que ele precisa de ajuda para amadurecer esses produtos e ser tudo o que podem ser.

Por enquanto, UWP e seu sucessor WinUI não está pronto para aplicativos LOB

Existem vários problemas que estamos enfrentando

• Desempenho ruim. Por exemplo, a propriedade de dependência WinUI é 50 vezes mais lenta do que https://github.com/microsoft/microsoft-ui-xaml/issues/1633 .
• Baixo desempenho de compilação. Várias vezes mais lento que wpf
• nativo dotnet
• Muitas mudanças importantes entre os lançamentos.
• Sandboxing e modelo de permissões
• Capacidade de personalização limitada para fornecedores de terceiros em comparação com wpf

Você acha que o WinUI pode superar essas limitações e se tornar o próximo framework pronto para LOB nos próximos 10 anos? Ou é hora de avançar para o aplicativo blazor de elétrons)

Eu tenho alguns problemas com o estado atual do WinUI.

C ++ / WinRT ainda é uma experiência de desenvolvedor muito pobre em comparação com as ferramentas C ++ / CX e a experiência geral do desenvolvedor. Se devemos lidar com componentes WinUI escritos em C ++, é de se esperar pelo menos uma cobertura de 1: 1 para o que as ferramentas C ++ / CX são capazes.

Ser C ++ 17 padrão não tem utilidade para mim se minha produtividade é prejudicada em vez de apenas usar C ++ / CX, e leva o dobro do tempo para escrever um componente UWP ou interface do usuário baseada em XAML.

O que leva à minha segunda pergunta, a principal razão para ter que lidar com C ++ em UWP / WinUI, é porque a Microsoft deixou cair a bola em qualquer tipo de vinculação DirectX para linguagens .NET. Então, o WinUI fornecerá suporte para substituição do tipo XNA ou gráfico de cenário WPF 3D? Aparentemente, só conseguimos silêncio de rádio aqui, e somos forçados a entrar em projetos comunitários como o MonoGame ou motores completos como o Unity.

Quando o Win2D finalmente fará parte do WinUI? Atualmente parece estar em modo de manutenção com futuro incerto.

Atualmente está ficando muito difícil continuar vendendo o sonho da UWP, pois a quantidade de listadores em volta da minha caixa de sabão continua diminuindo.

Quando os elementos da interface do usuário do Windows 10X chegarão ao Windows 10 para desktop?

@carmellolb 2022-2025?

Edit: MS provavelmente irá excluir isso, porque propõe um cronograma para entrega do produto, que não existe e, portanto, é enganoso;)

@ Felix-Dev "WinUI Desktop .. permitirá que aplicativos Win32 tenham acesso total às APIs de IU UWP .. excluindo algumas APIs como CoreWindow.

Excluindo CoreWindow? OMG - Essa é a primeira e mais importante API que deve ser retirada da UWP. É a API mais básica que fornece a funcionalidade básica da janela. Ele precisa ser universal, dentro e fora do contêiner UWP. Até que seja lançado, não podemos ter uma base de código comum para a camada de aplicativo e estamos presos ao código Win32 c legado em C ++ ou qualquer outro .net core irá fornecer (outra classe Window novamente?) Para C #.

Por favor, Microsoft - Assim como você está fornecendo XamlWindow dentro e fora da UWP, forneça também CoreWindow dentro e fora da UWP.

Sobre a ligação: por que você se afastou do Teams? O YouTube não funcionou muito bem no último.

@ Gavin-Williams

De https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216:

Nossa abordagem é que o WinUI 3 usará CoreWindow quando executado em UWP e Win32 Window (HWind) quando executado em Desktop (Win32).

WinUI 3 em aplicativos UWP será capaz de usar APIs AppWindow. Para Desktop, será necessário fazer algo semelhante. Ainda estamos projetando isso, então não tenho mais detalhes até agora.

A equipe também disse que está procurando fornecer APIs como CoreApplicationViewTitleBar.ExtendViewIntoTitleBar para WinUI Desktop, para que possamos obter o melhor dos dois mundos. Todo o poder do design de janelas Win32 (ou seja, sem barra de título / barra de título 100% personalizada, janela do aplicativo <tamanho mínimo necessário, sem botão da barra de tarefas, ...) e as novas APIs de personalização UWP modernas. (Para UWP, provavelmente teremos que esperar que o AppWindow V2 tenha recursos de janelamento semelhantes aos atuais do Win32.)

@jesbis Pergunta sobre WinUI Desktop: Em questão https://github.com/microsoft/microsoft-ui-xaml/issues/1939 , foi apontado que a ativação de notificação do sistema não funciona para aplicativos de desktop empacotados MSIX em (pelo menos) 1909 conforme mencionado nos documentos :

Para aplicativos Desktop Bridge, basta enviar notificações do sistema como um aplicativo UWP faria. Quando o usuário clica em seu brinde, seu aplicativo será iniciado na linha de comando com os argumentos de inicialização que você especificou no brinde.

Enquanto eu tenho que esperar e ver se a correção mencionada será retransportada para versões de SO afetadas para aplicativos de ponte de desktop, minha pergunta é: Os aplicativos de desktop WinUI fornecerão o recurso de ativação de notificação pronto para uso citado acima (sem ter que usar um ativador COM) em todas as versões do Windows 10 destinadas ao WinUI? (Ou qualquer conceito de ativação de brinde semelhante.)

@ Felix-Dev Pela documentação parece que a Ilha XAML não implica estritamente em um aplicativo híbrido, você poderia chamar a API de hospedagem XAML UWP diretamente de seu aplicativo Win32 ao custo de perder algumas funcionalidades, como o uso de controles personalizados, se eu entendi corretamente os documentos (e a nota nos documentos):

Hospedar um controle UWP padrão em um aplicativo WPF usando ilhas XAML

Componentes necessários

O projeto e o código-fonte do seu aplicativo. O uso do controle WindowsXamlHost para hospedar controles UWP originais padrão é compatível com aplicativos que visam o .NET Framework ou .NET Core 3.

Um projeto de aplicativo UWP que define uma classe de aplicativo raiz que deriva de XamlApplication . Seu projeto WPF ou Windows Forms deve ter acesso a uma instância da classe Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication fornecida pelo Windows Community Toolkit. Este objeto atua como um provedor de metadados raiz para carregar metadados para tipos UWP XAML personalizados em assemblies no diretório atual de seu aplicativo.

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

Lutei por muitas e muitas horas para fazer o C ++ / WinRT funcionar e não consegui fazer o que fiz em 30 minutos com C ++ / CX

Se devemos lidar com componentes WinUI escritos em C ++, é de se esperar pelo menos uma cobertura de 1: 1 para o que as ferramentas C ++ / CX são capazes.

@ Gavin-Williams, @pjmlp você abriu questões no repositório cppwinrt para os problemas que está encontrando? Ou são problemas específicos do WinUI para os quais você poderia abrir questões neste repo? Estamos trabalhando ativamente no suporte C ++ / WinRT, então seria ótimo ouvir todos os detalhes sobre o que não está funcionando bem para você. Também estamos usando - os novos recursos do WinUI estão todos em C ++ / WinRT, assim como nossos aplicativos o estão usando (por exemplo, calculadora ).

Sobre a ligação: por que você se afastou do Teams? O YouTube não funcionou muito bem no último.

Se você se refere aos problemas de áudio: achamos que tivemos um cabo ruim no mês passado e esperamos que esteja melhor amanhã. O YouTube parecia ser mais acessível para a maioria das pessoas, e o estúdio Channel9 tem áudio e vídeo muito melhores do que a sala de conferência que estávamos usando para as equipes.

RE: CoreWindow, suporte para win32, containers - falaremos sobre nossa direção atual durante a chamada da comunidade amanhã com @ marb2000 :)

Também tentaremos chegar a outras questões até agora (por exemplo, status atual na linha do tempo SwapChainPanel, Win2D / DirectX, ilhas, etc.) - obrigado pelos comentários e perguntas até agora!

@jesbis Obrigado por entrar em

Não há problemas para abrir, porque a abordagem do C ++ / WinRT para o desenvolvimento é completamente reversa em relação à produtividade oferecida pelo C ++ / CX.

Com C ++ / CX, inicialmente pensei que a Microsoft estava finalmente vendendo Visual C ++ da maneira certa, 25 anos depois Visual C ++ pegou com a experiência RAD de C ++ Builder.

Em vez disso, o que C ++ / WinRT me oferece é um retorno aos dias ATL / WTL, onde eu tenho que escrever MIDL clichê, embora o MIDL 3.0 seja de alguma forma melhor que o MIDL original, tenho que escrever manualmente o clichê de ligações UWP que C ++ / CX trata para mim.

Não que C ++ / CX seja perfeito, a maneira como ele lida com os manipuladores de eventos ainda falha em relação ao C # / VB.NET ou ao C ++ Builder.

UWP é de qualquer maneira vinculado ao Windows, portanto, ter uma vinculação C ++ pura não é algo que me leva para C ++ / Winrt, em vez de ser capaz de fazer exatamente o mesmo que em C # ou VB.NET, sem ter que lidar com o código que ainda parece ATL / WTL.

E, como mencionei, estou ocupado apenas com C ++ porque os apelos para expor o DirectX como um conjunto de componentes de tempo de execução UWP continuam sendo ignorados.

Portanto, não acho que a abertura de problemas no cppwinrt irá melhorar a capacidade de usar C ++ / Winrt no Blend e Visual Studio tão fácil quanto C ++ / CX, idealmente tão fácil quanto C # e VB.NET, pois espero que a equipe cppwinrt mude o problema na equipe do Visual Studio e, tradicionalmente (MFC / ATL / WTL), a equipe de ferramentas C ++ nunca se preocupou em fornecer as mesmas ferramentas de alto nível que as linguagens .NET oferecem, embora outras empresas sejam capazes de fazer isso com C ++ (Qt, Embarcadero).

@pjmlp obrigado pelos detalhes - estou verificando com algumas pessoas para ver se há mais informações para compartilhar sobre as ferramentas C ++ / WinRT, embora provavelmente não tenha boas respostas amanhã. Estamos focados em C ++ / WinRT para novos desenvolvimentos, mas temos isso em nosso roteiro para ter modelos C ++ / CX para WinUI 3 também, se isso ajudar.

Também estou interessado em saber qual é o plano para o isolamento do aplicativo WinUI daqui para frente. De uma perspectiva corporativa, precisamos de isolamento / sandbox e controle de capacidade (não opt-in do usuário). Então, colocando isso aí como um tópico para o Miguel ..

@infoequipt você poderia explicar melhor o que entende por isolamento? Por exemplo, como o suporte do AppContainer ?

Por enquanto, UWP e seu sucessor WinUI não está pronto para aplicativos LOB

• Muitas mudanças importantes entre os lançamentos.

@Xarlot que mudanças significativas estavam causando problemas para você? Com as APIs UWP, tentamos manter um alto grau de compatibilidade a cada lançamento.

@ Gavin-Williams Com relação a SharpDX sendo descontinuado, você pode querer dar uma olhada em Vortice.Windows , que é uma ótima alternativa para isso. @Aminator está usando-o atualmente em seu próprio mecanismo de jogo e editor totalmente UWP / C # / XAML DX12, DX12GameEngine .
Esperançosamente, isso atende às suas necessidades em seus aplicativos! 😄

Em relação às perguntas para a chamada, tenho uma que é um pequeno detalhe, mas já que estamos nisso: poderíamos usar a mudança para WinUI 3 para também corrigir alguns pequenos bugs de IU legada que podem ser considerados "alterações interruptivas", como o StackPanel aplicando a propriedade Spacing incorretamente a itens recolhidos?

Ie. se você tiver alguns itens recolhidos em StackPanel , ele ainda aplicará o espaçamento entre eles, forçando você a voltar para o preenchimento / margem manual entre os itens se houver alguns de seus itens que possam ser mostrados / ocultados de maneira programática. Corrigi este bug específico em um PR para WrapPanel no Windows Community Toolkit ( # 2838 ) e, aparentemente, esse comportamento no StackPanel era um problema conhecido reconhecido por alguns outros engenheiros da MS também. 🤔

Continue com o ótimo trabalho! 🚀

@leoniDEV Obrigado por apontar isso. Vamos ver se teremos algumas respostas definitivas amanhã 🙂

@jesbis Mais duas perguntas sobre WinUI Desktop (relacionadas entre si):

1. Os aplicativos WinUI Desktop terão uma opção embutida entre várias instâncias (padrão Win32) e instância única (padrão UWP)? No momento, se quisermos que um aplicativo Win32 seja de instância única, temos que implementar esse comportamento nós mesmos. Isso pode exigir não apenas um bloqueio de aplicativo (como um mutex para verificar se uma instância já está em execução), mas também uma API Win32 como SendMessage para passar operações de uma segunda instância de aplicativo para a instância de aplicativo primária (consulte a pergunta 2). Seria ótimo se pudéssemos ter a opção de ter o comportamento de instância única de aplicativos UWP para aplicativos WinUI Desktop.

1. Os aplicativos WinUI Desktop poderão usar a API UWP Jumplist ? Atualmente, os aplicativos de ponte de desktop não podem usá-los com eficácia porque o aplicativo aparentemente não pode ser ativado (consulte Problema do Terminal do Windows https://github.com/microsoft/terminal/issues/576 para uma breve visão geral dos problemas). Eu gostaria de suporte total a esta API para aplicativos WinUI Desktop porque eles são muito mais fáceis de trabalhar do que as APIs Win32 / WPF. Por exemplo, ícones de tarefa jumplist podem ser facilmente configurados usando os esquemas de URI ms-appx:/// ou ms-appdata:/// vez de criar um .exe ou .dll contendo as imagens e, em seguida, definir o caminho para esse arquivo binário e também um deslocamento no arquivo para o ícone específico .

   Os documentos resumem as vantagens da API UWP Jumplist:

   Como alternativa, use as APIs UWP Windows.UI.StartScreen.JumpList, que permitem fazer referência a ativos de string e imagem usando o esquema de URI de recurso ms relativo ao pacote (que também reconhece idioma, DPI e alto contraste).

O comportamento de instância única de aplicativos UWP também torna potencialmente o trabalho com jumplists muito mais fácil. Se você tiver uma tarefa jumplist que deve operar na instância do aplicativo em execução no WPF / Win32, uma segunda instância do aplicativo é iniciada e precisa usar, por exemplo, a API SendMessage Win32 para enviar a operação solicitada para a instância do aplicativo principal. Usando o comportamento de instância única em UWP, o aplicativo em execução obtém facilmente a tarefa de salto invocada. sem todo o trabalho adicional no caso do Win32.

@pjmlp outra coisa que pode ser de interesse se você ainda não viu é esta sessão de Kenny Kerr e Scott Jones da última conferência Build, particularmente os últimos 11 minutos, onde eles falam sobre algumas melhorias prototipadas para ligações e um pouco de C ++ especificações técnicas para adicionar reflexão e suporte de metaclasse que podem remover completamente os requisitos atuais de codegen de IDL e metadados:

https://youtu.be/X41j_gzSwOY?t=2659

Se tivermos tempo, podemos falar um pouco sobre isso na teleconferência de amanhã.

Obrigado @jesbis , estou ciente dessa conversa. Ainda está muito longe no futuro, pelo que posso dizer.

No momento, parece mais provável que eu irei portar meu código DirectX existente para algo como a biblioteca Vortice, apontada por @ Sergio0694, do que esperar que essas ferramentas

Eu admiro seus esforços, mas aqui das trincheiras, depois de Silverlight, XNA, WinRT, UAP, UWP, WinUI, .NET Framework, WCF, EF6, eventualmente ficamos cansados ​​de continuar fazendo reescritas.

WinUI deve ser melhor do que WPF em todos os sentidos, e se formos forçados a usar C ++ por motivos, então seu conjunto de ferramentas deve estar no mesmo nível que os desenvolvedores .NET aprenderam a amar, para realmente valer a pena ir além do WPF ou fazer um aponte para evitar que os negócios queiram usar aplicativos estilo Electron.

Como @ Sergio0694 já perguntou, o WinUi 3.0 será usado não apenas para alternar namespaces, mas também conterá outras alterações importantes, que são necessárias para corrigir bugs, como espaços aplicados incorretamente?

Nesse caso, haveria uma chance de renomear a propriedade NavigationView.IsBackButtonVisible para BackButtonVisibility pois o nome e o tipo atualmente não estão alinhados (IsBackButtonVisible é um enum NavigationViewBackButtonVisible, não um bool). Isso também foi discutido aqui .

@chingucoding Lembro-me que a equipe disse que, para o WinUI 3.0 em si, as alterações significativas devem ser mínimas para tornar a portabilidade de aplicativos existentes (UWP) para ele o mais simples possível. Suspeito que essas mudanças, se aprovadas, serão implementadas em versões subsequentes do WinUI 3.x / 4/5 / .....

P: O WinUI 3.x oferecerá suporte a AcrylicBrush com HostBackdrop ? Atualmente, ele está quebrado no alfa, mas estou curioso para saber se está no roteiro para ser consertado antes do lançamento.

P: O WinUI Desktop permitirá que os desenvolvedores de aplicativos de desktop _finalmente_ usem AcrylicBrush com HostBackdrop ? Anteriormente, usamos o atributo de composição WCA_ACCENT_POLICY com ACCENT_ENABLE_ACRYLICBLURBEHIND mas a Microsoft quebrou isso criticamente em 19H1 + e nosso aplicativo está sofrendo desde então. (Ele também afetou coisas como o Seletor de Emoji, mas a Microsoft fez a manutenção desses componentes para usar um método não acrílico.)

Sobre WebView2:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"A visualização do desenvolvedor está disponível para Win32 C ++ no Windows 10, Windows 8.1, Windows 8 e Windows 7. No futuro, planejamos oferecer suporte ao WebView2 no .NET e XAML."

Minha pergunta é .. Está planejado que a versão .NET do WebView2 SDK seja aplicável para Win8.1, 8 e 7?
Tenho a preocupação de que o parhaps WebView2 no .NET seja compatível apenas com o WinUI3. No meu entendimento, o suporte do aplicativo WinUI3 WinForms é aplicável apenas para .NET Core e apenas para Win10.
Deixe-me explicar minha situação. Meu cliente tem muitos aplicativos de desktop WinForm que usam o IE BrowserControl. Mas o IE está obsoleto e deseja migrar para navegadores modernos. E, estes aplicativos DEVEM suportar Win7, 8, 8.1. (não me culpe pelo suporte de sistema operacional antigo)

Se possível:

• Win32 ETA em uma versão de visualização para WinUI 3.0

• Se o código-fonte não estiver pronto para ser compartilhado, talvez seja legal mostrar aos colegas de trabalho um demo exe já compilado de alguns elementos da IU em execução, que possamos baixar e brincar.

• O WinUI 3.0 oferece suporte a efeitos de sombreamento personalizados como o WPF / Silverlight? Se não, há alguma ideia de adicioná-los mais tarde? A camada de renderização usada pelo WinUI é capaz disso?

@leoniDEV Eu fui em frente e criei um projeto de Ilha XAML como você destacou (portanto, nenhum projeto UWP separado). Ele contém um único controle de caixa de entrada UWP (um botão) e funciona bem em 10X. Nenhuma surpresa para a história do contêiner ... ele é executado no contêiner Win32 conforme o esperado.

Portanto, parece que pelo menos agora não há suporte completo para aplicativos XAML Island que consomem um projeto UWP separado.

Estou olhando para fazer v-next de um aplicativo WPF legado. Provavelmente posso usar o .NET Core WPF, mas realmente quero usar o WinUI. Estou tendo problemas com libs como Prism ainda derivando de Windows.UI.Xaml (em oposição a Microsoft.UI.Xaml). Parece que esses tipos de problemas são fundamentais. Ainda existe uma orientação PnP sólida para WinUI ou é muito cedo?

É possível fazer com que alguém da equipe do shell ou da equipe de aplicativos de caixa de entrada fale sobre por que o menu iniciar e o explorador de arquivos no Windows 10x são baseados na Web em vez de usar o WinUI?

Tudo que eu preciso é uma experiência de portabilidade perfeita de nosso aplicativo UWP atual (com extensão de desktop) para um aplicativo WinUI Desktop (sem a extensão de desktop). Isso será possível? Quais são as armadilhas neste cenário?

Se isso for difícil, será possível no futuro melhorar o UWP (para aplicativos em execução na área de trabalho) para sempre executar aplicativos em segundo plano e permitir que eles chamem todas as APIs win32 por meio de P / Invoke e permitir que dlls carreguem outra dll sem LoadPackagedLibrary (mas com LoadLibrary).

Qual é a probabilidade de o WinUI 3.0 estar pronto para ser iniciado quando os primeiros dispositivos Windows 10X forem iniciados? Estou interessado em entrar no mundo de desenvolvimento do Windows e estou tentando decidir qual abordagem faz mais sentido neste momento.

Obrigado a todos pelas perguntas e por assistirem se vocês pudessem comparecer! A gravação é ao vivo no mesmo link.

Não respondemos muitas perguntas. Vou tentar resumi-las e postar algumas respostas aqui em breve.

Bom show galera, obrigado pela pergunta e pela apresentação do Miguel.

Vou adicionar mais algumas perguntas, na esperança de que sejam respondidas.

1. Os aplicativos Win32 tradicionais são desenhados na tela em WM_PAINT. Os aplicativos XAML estão no modo retido. Desenhamos muitas coisas na tela para criar objetos / controles individuais. Ainda haverá um equivalente WM_PAINT para me permitir desenhar na janela, mas com uma API mais moderna? Win2D ou alguma outra API de modo imediato?

2. A acessibilidade é tratada de maneira diferente no Win32 (APIs COM) e, digamos, no WPF (pares de automação). Se eu escrever um aplicativo Win32 + WinUI, poderei aumentar ou controlar a árvore de acessibilidade com mais facilidade? Ou vou ficar com as APIs COM antigas? Como eu mesclaria meu conteúdo desenhado personalizado com controles acessíveis na árvore de acessibilidade?

3. Hoje, imprimimos desenhando em uma impressora DC. Existe uma nova impressão com Win32 + WinUI?

4. Ainda estou um pouco perplexo com relação à relação entre um HWND, um CoreWindow e o que vem a seguir para WinUI. Os HWNDs ainda existirão ou substituiremos as chamadas CreateWindow por outra coisa? Suponho que sim ... mas se for esse o caso, suponho que ainda deve haver um HWND subjacente para os casos em que devemos entregar um para componentes externos (HWND pai, por exemplo).

5. O WebView2 usará em um aplicativo Win32 + WinUI terá os problemas de espaço aéreo que encontramos com o controle do IE integrado?

Começando a pôr em dia algumas perguntas:

WinUI é apenas desenvolvimento UWP, mas uma especificação mais moderna? Eu vejo conversas sobre WinUI e não tenho 100% de certeza se elas estão falando sobre UWP dev, bibliotecas específicas em UWP dev ou algo totalmente diferente

WinUI é especificamente a camada de IU e não inclui outros aspectos da plataforma de aplicativo UWP, como o modelo de aplicativo para suspender / retomar, tarefas em segundo plano, etc.

Para aplicativos UWP, ele pode substituir especificamente Windows.UI.Xaml , Windows.UI.Composition e partes de Windows.UI.Input .

Os aplicativos WinUI terão uma opção embutida entre várias instâncias (padrão Win32) e instância única (padrão UWP)?

@ Felix-Dev, ainda não exploramos a ideia de um melhor suporte de instância única para aplicativos win32 - se você tiver uma proposta, sinta-se à vontade para abrir um problema neste repositório para ela!

O WinUI 3.x oferecerá suporte ao AcrylicBrush com HostBackdrop? Atualmente, ele está quebrado no alfa, mas estou curioso para saber se está no roteiro para ser consertado antes do lançamento. O WinUI Desktop permitirá que os desenvolvedores de aplicativos de desktop finalmente usem o AcrylicBrush com o HostBackdrop?

@riverar, infelizmente, isso não está nos planos para WinUI 3.0 RTM. Há desafios em dar suporte a isso em uma plataforma de IU desacoplada do sistema operacional, mas planejamos revisitar isso após a 3.0.

Sobre o WebView2: Minha pergunta é ... Está planejado que a versão .NET do WebView2 SDK seja aplicável para Win8.1, 8 e 7?
Tenho a preocupação de que o parhaps WebView2 no .NET seja compatível apenas com o WinUI3.

@ pnp0a03 o controle

https://docs.microsoft.com/microsoft-edge/hosting/webview2

Estou tendo problemas com libs como Prism ainda derivando de Windows.UI.Xaml (em oposição a Microsoft.UI.Xaml). Parece que esses tipos de problemas são fundamentais. Ainda existe uma orientação PnP sólida para WinUI ou é muito cedo?

@GraniteStateHacker Acho que é um pouco cedo - WinUI 3 ainda é muito novo para ter muito suporte de ecossistema (está apenas em alfa), mas @hassanuz está iniciando um fluxo de trabalho para investigar as opções de compatibilidade / migração de bibliotecas.

O WinUI é apenas para aplicativos da Store?

Não - você pode usá-lo de várias maneiras, por exemplo:

• inclua-o em um aplicativo win32 existente (WPF, WinForms, MFC, etc.) usando as ilhas Xaml
• construir um instalador MSIX e implantar como quiser
• criar um aplicativo descompactado e distribuí-lo via xcopy ou outros meios (não compatível com WinUI 3 ainda, mas planejado para RTM)

Qual é a probabilidade de o WinUI 3.0 estar pronto para ser iniciado quando os primeiros dispositivos Windows 10X forem iniciados? Estou interessado em entrar no mundo de desenvolvimento do Windows e estou tentando decidir qual abordagem faz mais sentido neste momento.

@dwalleck WinUI 3 já tem uma saída alfa e deve ter uma visualização mais funcional em torno do cronograma da conferência Build , e ambos têm como meta o final de 2020. Se você começar com UWP Xaml e / ou WinUI, então você deve estar em um bom caminho para o desenvolvimento 10X .

Os aplicativos Win32 tradicionais são desenhados na tela em WM_PAINT. Os aplicativos XAML estão no modo retido. Desenhamos muitas coisas na tela para criar objetos / controles individuais. Ainda haverá um equivalente WM_PAINT para me permitir desenhar na janela, mas com uma API mais moderna? Win2D ou alguma outra API de modo imediato?

@jschroedl Árvores e pincéis de elemento

• Camada de composição Visuals
• camada de composição Formas que permitem desenhar geometrias retidas de alto desempenho - também usadas para coisas como o controle WinUI AnimatedVisualPlayer que pode reproduzir formas / animações de Lottie
• Interoperabilidade DirectX com SwapChainPanel, SurfaceImageSource ou VirtualSurfaceImageSource (dependendo se você deseja uma cadeia de troca ou modelo de pincel virtualizado / não virtualizado)
• Win2D, que abstrai a interoperabilidade DirectX acima para você (com Direct2D, DirectWrite) e fornece uma API .NET

A acessibilidade é tratada de maneira diferente no Win32 (APIs COM) e, digamos, no WPF (pares de automação). Se eu escrever um aplicativo Win32 + WinUI, poderei aumentar ou controlar a árvore de acessibilidade com mais facilidade? Ou vou ficar com as APIs COM antigas? Como eu mesclaria meu conteúdo desenhado personalizado com controles acessíveis na árvore de acessibilidade?

Ótima pergunta! Paging @ marb2000 para garantir que isso seja abordado e fornecer as atualizações mais recentes. Em geral, as árvores WinUI Xaml devem usar AutomationPeers, mas ainda não tenho certeza se isso estenderá qualquer nova funcionalidade para conteúdo win32 não WinUI.

Hoje, imprimimos desenhando em uma impressora DC. Existe uma nova impressão com Win32 + WinUI?

A principal funcionalidade de impressão do conteúdo WinUI deve ser por meio de uma versão WinUI da API WinRT PrintDocument .

Ainda estou um pouco perplexo com relação à relação entre um HWND, um CoreWindow e o que vem a seguir para WinUI. Os HWNDs ainda existirão ou substituiremos as chamadas CreateWindow por outra coisa? Suponho que sim ... mas se for esse o caso, suponho que ainda deve haver um HWND subjacente para os casos em que devemos entregá-lo a componentes externos (HWND pai por exemplo

O WinUI não está substituindo os hwnds, mas o objetivo é abstrair seu uso para casos de uso comuns, fornecendo uma API Xaml - semelhante a como o WPF funciona. A API Xaml ainda usará hwnds / CoreWindows como um detalhe de implementação subjacente e provavelmente teremos APIs "backdoor" / "escape-hatch" para obter acesso direto a hwnds quando necessário. Devemos ter um rascunho da proposta em algumas semanas, o que tornará isso mais claro.

@jesbis Obrigado pela sua resposta, mas infelizmente a minha preocupação não foi resolvida.
Atualmente, a versão WebView2 SDK Win32 "C ++" (visualização) é lançada neste site. Suporta Win7, 8 e 8.1.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
Minha pergunta é sobre a versão .NET. Atualmente, a versão .NET só é compatível com WinUI 3, mas, como você sabe, não podemos usar WinUI 3 em Win7, 8 e 8.1 (está certo?).
Assim, postei minha dúvida conforme abaixo.

Minha pergunta é .. Está planejado que a versão .NET do WebView2 SDK seja aplicável para Win8.1, 8 e 7?

@jesbis Obrigado por responder às minhas perguntas, embora tenha

Tentando ser construtivo aqui.

Portanto, o melhor que a Microsoft pode oferecer em relação às ferramentas C ++ / WinRT é apontar algumas propostas que estão no ar, que com sorte podem chegar ao ISO em algum lugar entre C ++ 23 ou C ++ 26, se chegarem. E então espere que a equipe do Visual Studio eventualmente reconstrua o C ++ / CX sobre eles, o que o tornará em cerca de 6 anos a partir de agora.

Se eu quiser ótimas ferramentas de IU C ++, WinUI definitivamente não é, em vez de Qt ou C ++ Builder, com o benefício adicional de portabilidade de plataforma.

Então, depois de assistir à apresentação, e ainda com as cicatrizes do XNA (reescrever em C ++ com DirectXTK), WinRT 8.0, WinRT UAP 8.1, UWP W10, C ++ Direct2D em vez de System. Desenhando (até o Win2D aparecer, agora estagnado), WinUI é definitivamente algo que irei colocar em espera.

No futuro, aconselharei meus clientes a usar WPF ao usar .NET, Qt ao usar C ++ ou focar em PWAs, se possível com tecnologias da web.

O roteiro do WinUI 3.0 não inspira nenhuma confiança de que outra reinicialização está chegando, se a venda de UWP continuar falhando no mercado de desktop.

Em certo sentido, o que quero salientar é que a administração da Microsoft deve pensar em como nos vender a ideia de adotar o WinUI, depois de nos reprovar tantas vezes desde o lançamento do Windows 8.

@pjmlp O feedback geral sobre C ++ / WinRT é provavelmente mais bem direcionado para o repositório cppwinrt. As atualizações do padrão ISO levam tempo, mas espero que sejam menos do que os prazos que você mencionou - o suporte à reflexão é uma prioridade e eles estavam discutindo isso na conferência C ++ em Praga na semana passada.

O DirectXTK ainda está em desenvolvimento e recebe atualizações regulares.

Em termos de APIs de estrutura Xaml, WinUI é o caminho a seguir e tem uma linhagem de compatibilidade praticamente ininterrupta de volta ao Windows 8 - passamos muito tempo tentando manter um alto grau de compatibilidade 🙂 Existem algumas mudanças (devido à integração do shell, Estrutura do projeto VS, etc.), mas na maioria das vezes você poderia portar o Windows 8 Xaml para um aplicativo do Windows 10 atual, recompilá-lo e executá-lo no último vôo interno e funcionaria.

Alguns dos benefícios de alto nível do WinUI incluirão a remoção das barreiras entre UWP WinRT APIs e win32 APIs, suporte .NET 5, habilitação de suporte de nível inferior imediato para novos recursos, remoção da necessidade de fazer muitas verificações condicionais de versão do sistema operacional, habilitação de contribuições de OSS e permitindo atualizações incrementais para aplicativos win32 existentes usando ilhas Xaml.

@ pnp0a03 existem esforços para trazer elementos .NET para o mercado também. Não posso dar datas específicas, mas estamos cientes da demanda para isso e estamos trabalhando nos detalhes.

@jschroedl queremos eliminar problemas de espaço aéreo, estamos tentando elaborar um plano de renderização que nos ajudará a conseguir isso.

@jesbis Como mencionei, não acredito que reclamar no cppwinrt fará alguma coisa, prefiro reclamar por não adotar C ++ / WinRT a menos que para os casos de uso que não posso evitar, especificamente porque o roteiro é adotar um recurso que pode nem mesmo ser aceito em ISO.

Com relação ao DirectXTK, eu estava dando mais um exemplo de como a Microsoft nos forçou a reescrever nosso código C # em C ++, com ferramentas menos capazes, descartando o XNA e fornecendo o DirectXTK como "alternativa".

Felizmente, a comunidade de código aberto conseguiu criar o MonoGame e fazer o trabalho que a Microsoft se recusou a fazer com o XNA.

Eu vi durante a apresentação e em alguns dos comentários aqui, como C ++ é ótimo e divertido, como WinDev (mais uma vez desde que o Longhorn assumiu) continua vendendo C ++ primeiro, .NET depois.

Se eu quiser ótimas ferramentas C ++, Qt e C ++ Builder são meus ambientes de escolha, não Visual C ++.

Você realmente deve pedir à gerência para permitir que sua equipe dê uma olhada no que é possível hoje na competição, ao invés de esperar que algumas metaclasses e idéias de reflexão sejam aceitas na ISO.

Não só temos que nos preocupar com as APIs e bibliotecas de terceiros que não são transportadas do .NET Framework para o .NET Core, também temos que lidar com todos os problemas de migração do WPF / UWP para o WinUI e o "basta escrever em C ++ / WinRT, é legal e ficará melhor em alguns anos "mentalidade.

A administração da Microsoft realmente tem que pensar bem, como vender esta reescrita para desenvolvedores .NET queimados, caso contrário, não sairemos das pilhas que já fazem seu trabalho.

@pjmlp Por falar em DirectX, estou trabalhando ativamente em uma estrutura de gráficos, áudio e entrada C # portátil e agnóstica em meu tempo livre que será capaz de rodar D3D12 / 11 etc em uma visualização WinUI ... entre muitas outras coisas.

Ele suporta uma abordagem de renderização muito mais moderna e focada no desempenho em comparação com algo como o XNA. Não está pronto para uso, mas é algo que muitas pessoas queriam, incluindo eu ... então estou fazendo isso. D3D12 e Vulkan serão os primeiros alvos suportados. Você também poderá escrever sombreadores em C # em vez de HLSL ou GLSL etc.

Quando estiver pronto para uso, compartilharei mais, mas como se trata de uma estrutura e não de um enorme SDK ou mecanismo de jogo, será muito portátil e leve, mas poderoso e fácil de usar. Perfeito para renderizar conteúdo 3D em WinUI, WPF ou algum aplicativo nativo C # Win32 ou WinRT.

https://github.com/reignstudios/Orbital-Framework

@ zezba9000 Obrigado pela informação, muitas coisas impressionantes que você fez, parabéns!

Acho que no que diz respeito ao suporte gerenciado para DirectX, só podemos contar com os esforços de uma comunidade como a sua, depois de tanques DirectX e XNA gerenciados, a turma do C ++ MS assumiu os esforços de desenvolvimento do DirectX.

Pelo menos qualquer um desses projetos pode contar com a minha defesa, como marketing para mostrar aos outros que não precisa ser apenas "C ++ ou estrada", como WinDev gosta de empurrar. Aqui, eles poderiam tirar uma lição de OpenGL ES / Metal com Swift ou OpenGL ES / Vulkan com Java / Kotlin. Aparentemente, usar linguagens gerenciadas para programação 3D não foi um problema para as plataformas móveis ganharem do Windows (infelizmente, WP foi uma ótima experiência).

Boa sorte para seus esforços, escrever sombreadores em C # parece realmente atraente e eu não conhecia o CS2X.

@pjmlp Ya, a parte CS2X é o que permitirá a escrita de shaders de GPU agnósticos em C # (o que é legal porque você poderá fazer um teste de unidade em seus shaders em teoria). Para destinos que podem fazer uso de um subconjunto C #, o CS2X permite que eu / outros almejem plataformas fora do que os tempos de execução .NET atuais suportam com um tempo de execução muito leve, pois o CS2X pode compilar o subconjunto C # para um tempo de execução C89 ... e porque o Orbital-Framework pode ter como alvo o tempo de execução CS2X => C89, ele por sua vez pode ter como alvo essas plataformas também.

Grande projeto, mas é o que me interessa e estou dedicado a fazê-lo acontecer.

Será possível usar HwndHost com WinUI 2.4
Tentei na versão de pré-lançamento e não funcionou.
Também será possível com WinUI3 com todas essas novas janelas planejadas (janela XAML) e aplicativo (aplicativo XAML) e, se sim, quando podemos esperar a primeira visualização para ver isso.
Na verdade, se for possível no WinUI3, essa funcionalidade será adicionada aos novos lançamentos do WinUI 2, ou o WinUI 2 funcionará apenas em aplicativos Uwp.
Por exemplo, agora, temos o aplicativo WPF, que usa muito código C ++ por meio de HwndHost, e como estamos planejando mover tudo para o WinUI, essa parte é muito crítica para decidirmos ir com o WinUI ou outra coisa. Além disso, até o WinUI 2 parece bom para nós, a parte XAML é tão fácil de transferir, a API de composição funciona muito bem, o Uwp Community Toolkit funciona muito bem, só que não podemos usar o código HwndHost e c ++ Win32. Então é e quando o WinUI3 vai resolver isso? Também gosto muito do x: Bind, mas isso corre até mesmo risco para o lançamento do WinUI3.

@ zezba9000

Falando em DirectX, estou trabalhando ativamente em uma estrutura de gráficos, áudio e entrada C # portátil e agnóstica em meu tempo livre que será capaz de executar D3D12 / 11 etc em uma visualização WinUI ... entre muitas outras coisas.

Boa sorte com isso! É uma quantidade absurda de trabalho!

Será possível usar HwndHost com WinUI 2.4
Tentei na versão de pré-lançamento e não funcionou.
Também será possível com WinUI3 com todas essas novas janelas planejadas (janela XAML) e aplicativo (aplicativo XAML) e, se sim, quando podemos esperar a primeira visualização para ver isso.
Na verdade, se for possível no WinUI3, essa funcionalidade será adicionada aos novos lançamentos do WinUI 2, ou o WinUI 2 funcionará apenas em aplicativos Uwp.
Por exemplo, agora, temos o aplicativo WPF, que usa muito código C ++ por meio de HwndHost, e como estamos planejando mover tudo para o WinUI, essa parte é muito crítica para decidirmos ir com o WinUI ou outra coisa.

Há um problema aberto para uma maneira de hospedar user32 / comctl ou WPF UI dentro do WinUI XAML: https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Parece que não será feito antes do 3.0, se for feito.

Eu posto isso para # 1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833 mas vou copiar
aqui também: No momento, temos o aplicativo WPF que usa muito código c ++ por meio
Controle de HwndHost. Estamos planejando mover o aplicativo Wpf para WinUI e mover o Xaml
funciona muito bem sem problemas, mas e o HwndHost, isso vai ser
possível com WinUI3. Em nosso caso, estamos fazendo interoperabilidade com
DirectShow por meio de HwndHost e agora no WinUI 2, isso não é
possível. Qual será a data realista para usar o HwndHost no WinUI3? Também é
esta nova janela e aplicativo Xaml como discutido no último fevereiro
Chamada da comunidade WinUI, pode ajudar ou não?

El dom., 23 de fev. de 2020 a la (s) 13:42, Max Strini (
notificaçõ[email protected]) escribió:

Será possível usar HwndHost com WinUI 2.4
Tentei na versão de pré-lançamento e não funcionou.
Também será possível com WinUI3 com todos esses novos planejados
Janelas (janela XAML) e aplicativo (aplicativo XAML) e, se sim, quando
podemos esperar a primeira visualização para ver isso.
Na verdade, se isso for possível no WinUI3, essa funcionalidade
ser adicionado aos novos lançamentos do WinUI 2, ou o WinUI 2 funcionará apenas em aplicativos Uwp.
Por exemplo, agora, temos o aplicativo WPF, que usa muito código C ++ por meio
HwndHost, e porque estamos planejando mover tudo para WinUI, esta parte
é muito importante para nós decidirmos ir com WinUI ou outra coisa.

Há um problema aberto para uma maneira de hospedar user32 / comctl ou WPF UI dentro
WinUI XAML: # 1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Parece que não será feito antes do 3.0, se for feito.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMV2ZRQ#issuecomment-590064838 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

-
Mario Rancic
Engenheiro de software
Profissional Certificado Microsoft

Realmente uma boa chamada para a comunidade WinUI na semana passada! O conteúdo era muito interessante e detalhado / técnico o suficiente para fornecer muitos insights. As atualizações de roadmap / status de desenvolvimento também são extremamente valiosas para os consumidores de WinUI e nossos próprios roadmaps de desenvolvimento. Aguardo a próxima chamada!

Sobre o HwndHost no WinUI 3.
HwndHost permite hospedar conteúdo Win32 dentro do WPF. Infelizmente, não há nenhum plano no WinUI 3.0 para oferecer suporte a isso, incluindo no WinUI 3.0 Desktop ou nas ilhas WinUI. Sobre o cenário @ mariorancic01 descrito, você avaliou APIs UWP MediaPlayer em vez de DirectShow?

Bem, a câmera Uwp parece melhor, mas não tenho certeza se podemos usá-la em nosso cenário.
Estamos usando a câmera como uma câmera virtual com DirectShow e precisamos mostrar
vídeo, para pegar o stream da câmera para uma foto e também com o PjSip no
ao mesmo tempo, antes que pudéssemos fazer isso apenas com o DirectShow. Podemos usar este Uwp
MediaPlayer com PjSip.

El mié., 26 de fev. de 2020 a la (s) 23:47, Miguel Ramos (
notificaçõ[email protected]) escribió:

Sobre o HwndHost no WinUI 3.
HwndHost permite hospedar conteúdo Win32 dentro do WPF. Infelizmente lá
não há plano no WinUI 3.0 para oferecer suporte a isso, incluindo no WinUI 3.0 Desktop ou
Ilhas WinUI. Sobre o cenário @ mariorancic01
https://github.com/mariorancic01 descrito, você avaliou UWP
APIs de MediaPlayer em vez de DirectShow?

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCGCSY#issuecomment-591683915 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

-
Mario Rancic
Engenheiro de software
Profissional Certificado Microsoft

Tenho uma pergunta sobre a Windows Store for Business, isso parece muito legal e muito útil para aplicativos LOB, mas li que pode ser abandonado. Alguém pode dizer algo sobre os planos sobre isso.

@ marionrancic01 Não é realmente necessário, pois agora você pode distribuir aplicativos UWP por meio do pacote MSIX.

triste, como @ mariorancic01 também acho útil a Windows Store for Business 😞

@leoniDEV Estou honestamente curioso para saber por que você precisaria da Windows Store para empresas, quando você pode simplesmente publicar como msix, como @kmgallahan disse

@kmgallahan @jtorjo Suponho que o que eles estão procurando é ter um catálogo de aplicativos privado. MSIX não oferece o que eu acredito? A menos que você crie um site onde liste o MSIX que sua empresa fornece, ou use alguma ferramenta de gerenciamento para implantar coisas para seus usuários?
De maneira semelhante, os antigos instaladores MSI também não fornecem uma maneira de descobrir aplicativos.

Publicar na Windows Store não é um passeio no parque - é muito mais complexo do que você pensa. Primeiro, você precisa esperar por um certificado da MS - aquele que você usará para publicar (não me lembro das etapas exatas agora). Então, você precisa ter certeza de que seu aplicativo não viola nenhum dos requisitos da Store. Então, qualquer atualização que você fizer pode levar dias para ser aceita (ou pode ser rejeitada) e você contaria com o algoritmo da loja para que as pessoas encontrassem seu aplicativo.

Mas se você implantar sozinho, será um pouco difícil configurá-lo (eu saberia), mas uma vez feito isso, será fácil e fácil. Mas sim, você ficará encarregado de mostrar seu aplicativo para o mundo.

Como alguém que tem vários aplicativos na Microsoft Store, incluindo a loja para empresas, posso dizer que a publicação na loja da Microsoft ficou muito melhor nos últimos meses. A certificação para atualizações regulares às vezes acontece em poucas horas. As diretrizes da loja também são muito fáceis de cumprir.
Por outro lado, perturbar um msix autônomo pode ser complicado. Ao contrário da loja que assina pacotes para você, se você distribuir seu aplicativo fora da loja, precisará assiná-lo por conta própria.

@jtorjo Você não precisa de certificados.

Para ser claro, há problemas com a loja e o painel do desenvolvedor cai de vez em quando, mas meu ponto acima é que é muito conveniente ter a loja para aplicativos de negócios.

Como alguém que tem vários aplicativos na Microsoft Store, incluindo a loja para empresas, posso dizer que a publicação na loja da Microsoft ficou muito melhor nos últimos meses. A certificação para atualizações regulares às vezes acontece em poucas horas. As diretrizes da loja também são muito fáceis de cumprir.

@yaichenbaum Isso é definitivamente bom saber. Quando eu estava publicando (mais ou menos 2 anos atrás), era muito mais difícil. Sim, você precisa assiná-lo - na verdade, você compra um certificado e o assina como parte do processo de "Publicar". Assim, depois de configurá-lo, você pode esquecê-lo.

@riverar Quando eu estava publicando (mais ou menos 2 anos atrás), lembro que você precisa reservar um nome e, em seguida, esperar por algo que a MS usará para assinar seu aplicativo (que é o que eu quis dizer, por um certificado - > um que a MS emitirá para você).