Podemos falar sobre o suporte para tipos de dados anuláveis ​​em controles e valores padrão? Como exemplo, há DatePicker que retorna DateTimeOffset e CalendarDatePicker que retorna DateTimeOffset ?.

• Por que um desses é anulável e o outro não? Será que o DatePicker foi desenvolvido usando APIs anteriores no período de tempo do Windows 8?
• Devemos considerar a adição de uma propriedade de configuração para permitir / não permitir nulo nos controles?
• Deve uma propriedade DefaultValue ser considerada para novos controles, como NumberBox, deve NaN ser mantido como padrão, ou devemos mudar para um duplo anulável com o nulo padrão?
• Existem limitações WinRT / OS XAML com o retorno e suporte a valores anuláveis ​​que impediriam que a propriedade Value NumberBox fosse anulável? Em caso afirmativo, como CalendarDatePicker foi implementado?
• Isso está diretamente relacionado às discussões da NumberBox nos números 1721 e 1708

Além disso, qual é o roteiro para corrigir os problemas abertos na NumberBox que não dependem do WinUI 3.0? Seria ótimo começar a usar esse controle no WinUI 2.4 em vez de ter que esperar mais. Na minha opinião, ainda não está totalmente pronto e fico desconfortável em colocar isso em aplicativos de produção.

Outra ideia interessante para discutir sobre a qual me pergunto: Qual será a política da Microsoft sobre mudanças interrompidas agora que o WinUI 3.0 está se tornando o código-fonte aberto?

No passado, a Microsoft virtualmente nunca fez alterações significativas. Isso geralmente é bom até que toda a desordem se acumule após alguns (ou 10) anos. Também não é o padrão para projetos de código aberto. Por exemplo, eventualmente ListBox deve ser eliminado para ListView e MessageDialog para ContentDialog, etc. Tenho certeza de que há muitas pequenas limpezas mais agradáveis ​​na API também.

Eu sei que as empresas odeiam mudanças - por um bom motivo. Também DEVE haver uma substituição drop-in relativamente fácil (funcionalmente equivalente) disponível para tornar a portabilidade para novas APIs simples. Isso precisaria ser avaliado caso a caso e feito um julgamento.

Estou me perguntando se poderíamos estabelecer versões principais (WinUI 4.0, por exemplo), permitindo alterações significativas. Isso permitirá que o projeto continue crescendo sem ter que conviver com todos os erros do passado. Essencialmente, a Microsoft já decidiu fazer isso com o .NET 5, baseando-o no .NET Core e descartando o que era o .NET Framework completo.

Isso pode ser bom para documentar uma vez que seja discutido.

Com base no progresso feito desde a última chamada, quando a equipe pensa realisticamente que o WinUI 3 estará pronto para o lançamento:

• Build 2020 (abril a maio)
• Ignite 2020 (outubro-novembro)
• ~ 2021

Além disso, o quão dependente é o seu trabalho na equipe .NET que cria uma nova solução AOT e .NET 5?

Por último, há pressão do lado do Windows para tê-lo pronto para o lançamento do Windows10X e / ou antes disso para que os desenvolvedores façam aplicativos especializados?

Haverá / deverá haver uma ferramenta para converter facilmente projetos WinUI 2.X para WinUI 3.0 (já que fazer isso manualmente pode ser muito trabalhoso para projetos grandes)?

O elefante na sala - WinRT (# 1856)

O elefante na sala - WinRT (# 1856)

Um modelo de aplicativo sem sandbox está chegando - que será executado da mesma maneira que o WPF (incluindo APIs Win32), mas com acesso a APIs WinRT modernas e interface de usuário e controles de código aberto com o novo XAML em execução no Direct X 12.

Um modelo de aplicativo sem sandbox está chegando - que será executado da mesma maneira que o WPF (incluindo APIs Win32), mas com acesso a APIs WinRT modernas e interface de usuário e controles de código aberto com o novo XAML em execução no Direct X 12.

Uau. Uau uau!!!!

Isso está além de incrível! Temos um ETA para isso, será discutido no call?

É incrivelmente incrível!

Um modelo de aplicativo sem sandbox está chegando - que será executado da mesma maneira que o WPF (incluindo APIs Win32), mas com acesso a APIs WinRT modernas e interface de usuário e controles de código aberto com o novo XAML em execução no Direct X 12.

Uau. Uau uau!!!!

Isso está além de incrível! Temos um ETA para isso, será discutido no call?

É incrivelmente incrível!

Foi a primeira coisa que aprendemos sobre WinUI. ETA é para este ano, eu suspeito que uma data definitiva será dada em // Build / - mas sinta-se à vontade para perguntar durante a ligação.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo Veja o roteiro do WinUI . Consulte também https://github.com/microsoft/microsoft-ui-xaml/issues/1045 para obter mais informações (como modelos de projeto VS).

@mdtauk @ Felix-Dev Vou reler esses documentos. Eu me lembro de perguntar isso antes - contanto que eu possa usar facilmente o win2d do meu aplicativo (sem sandbox), ficarei mais do que feliz!

@jesbis Desculpe pela pergunta noob - como faço para entrar na chamada?

Estamos configurando as informações para a ligação de amanhã mais tarde hoje - postarei as instruções em algumas horas.

O atraso se deve ao fato de ser a primeira vez que usamos um novo sistema de transmissão - depois disso, esperamos que ele fique mais suave e esteja pronto mais cedo 🙂

Acabei de ter um pensamento interessante (para mim, de qualquer maneira).

Olhando para a transmissão ao vivo do ASP.NET Community Standup de hoje, vi essencialmente 4 desenvolvedores MS fazendo uma transmissão ao vivo, embora fosse mais uma demonstração de tecnologia. Eu também ocasionalmente sintonizo @csharpfritz no Twitch, que faz sessões completas de codificação ao vivo.

Então, meu pensamento foi - depois que o WinUI 3 for lançado e a base de código (ou a maior parte dela) for totalmente de código aberto, algum membro da equipe estaria disposto a fazer transmissões ao vivo de vez em quando de alguns de seus trabalhos no WinUI?

Seria uma boa oportunidade de aumentar a exposição do WinUI, ajudar as pessoas a explorar casualmente a base de código, e as perguntas poderiam ser respondidas de vez em quando. ~ Eu não recomendaria um engajamento total no chat o tempo todo, pois isso seria muito contraproducente, mas talvez uma sessão de perguntas e respostas de vez em quando.

Não tenho ideia de quais são as políticas da MS sobre esse tipo de coisa, especialmente durante a jornada de trabalho. Seria interessante ouvir seus pensamentos.

Aqui está o link do evento ao vivo do YouTube para amanhã!

https://youtu.be/MXTVqgB4rW0

Obrigado por todos os comentários e perguntas até agora! Tentaremos chegar a tudo ou manter o controle para um acompanhamento se não tivermos tempo.

Há algo no guia sobre desempenho / fps da interface do usuário? Uma das maiores queixas que tenho com o Windows 10 moderno é que em uma máquina como o Surface Book você obtém um desempenho terrível em telas de alto DPI, que fica ainda pior quando você combina transparência e monitores adicionais. Pode estar fora do alcance do que é possível, mas há alguma consideração aqui sobre o quão fluido e bem ele funciona, especialmente sob essas condições?

Considere aumentar a prioridade de janelas sem bordas / transparentes (a la https://github.com/microsoft/microsoft-ui-xaml/issues/1247). Este é um bloqueador de adoção de WinUI para aplicativos como o nosso .

cc: @crutkas

Considere aumentar a prioridade de janelas sem bordas / transparentes (a la # 1247). Este é um bloqueador de adoção de WinUI para aplicativos como o nosso .

cc: @crutkas

Isso provavelmente exigiria que houvesse um elemento de janela de nível superior adicionado ao WinUI Xaml com propriedades, semelhantes ao WPF. # 1323

Aprender mais sobre o 'futuro das janelas' para WinUI seria bom - há uma série de solicitações relacionadas que seria bom, pelo menos, discutir / endereçar.

Provavelmente já foi perguntado antes.

Para mim, sempre foi uma questão de reutilização de código.
Isso leva a duas perguntas:

1. O suporte do .NET Core 3 e C # 8.0 chegará em breve?
2. Vamos ver outras etapas da equipe UWP / WinUI para facilitar o desenvolvimento de aplicativos da plataforma Uno?

Outro, quando veremos os bits ausentes do WPF com suporte em UWP?

Provavelmente já foi perguntado antes.

Para mim, sempre foi uma questão de reutilização de código.
Isso leva a duas perguntas:

1. O suporte do .NET Core 3 e C # 8.0 chegará em breve?
2. Vamos ver outras etapas da equipe UWP / WinUI para facilitar o desenvolvimento de aplicativos da plataforma Uno?

Outro, quando veremos os bits ausentes do WPF com suporte em UWP?

O código do .NET Core deve funcionar em ambos, portanto, um aplicativo WPF só precisa alterar o Xaml da interface do usuário e o código da interface do usuário.

Os aplicativos UWP devem funcionar bem com uma alteração de namespace para WinUI 3.0 - sair da sandbox pode precisar de mais trabalho, os detalhes ainda são desconhecidos.

Os bits ausentes do WPF não foram confirmados, mas eu fiz um problema sobre isso. # 719

@weitzhandler

Embora não seja oficialmente suportado e nem todos os recursos do C # 8 funcionem, você já pode usar a maior parte do C # 8 com WinUI / UWP. Veja aqui .

Eu faço isso e não tive nenhum problema. "Membros da interface padrão e índices e intervalos" parecem ser os únicos bits que faltam, embora eu não tenha tentado de tudo.

Apenas ampliando o que kmgallahan disse sobre o uso de C # 8. Tenho usado muitos dos novos recursos, mas realmente queria membros de interface padrão, que ainda não foram implementados.

Obrigado pessoal.
Se ainda posso acrescentar, o antigo tipo de csproj também é um pouco irritante.

@jesbis

Acabei de abrir esse problema na Galeria de controles XAML. Pode ser algo para discutir durante a chamada, se desejar.

Obrigado, tentaremos responder a todas as questões!

Há algo no guia sobre desempenho / fps da interface do usuário?

@ryvanvel , temos algumas orientações de desempenho aqui:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

E algumas outras postagens de blog e vídeos que podem ajudar, por exemplo:

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

Pelo que me lembro, esse bug está ocorrendo com o Windows 10, espero que seja resolvido antes: https://github.com/microsoft/microsoft-ui-xaml/issues/597

Infelizmente não poderei sintonizar a tempo, haverá uma gravação?

Editar: a gravação da chamada pode ser encontrada aqui: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis aqui :

Aqui está o link do evento ao vivo do YouTube para amanhã!
https://youtu.be/MXTVqgB4rW0

Seguindo o link do YT, parece que só vai começar no final desta hora, uma hora depois do horário normal, é verdade?

@weitzhandler A hora de início está na parte superior da postagem. Esta também é apenas a terceira chamada, então "regular" é um exagero.

@weitzhandler Tenho certeza de que todas as três ligações até agora foram agendadas para começar às 9h, horário do Pacífico.

Obrigado a vocês dois e desculpe pelo incômodo. Vejo você em breve.

Eu estava curioso para saber se WebView2 Chromium também exporá um evento como WebResourceRequested do WebView atual, para permitir que os desenvolvedores filtrem solicitações individuais da web. Eu confio muito nesse recurso específico em um dos meus aplicativos e estava me perguntando se ele ainda estaria por aí com o novo controle, e funcionando da mesma maneira.

Obrigado pessoal por todo o trabalho duro! 😄🚀

Haverá alguma ferramenta para gerar PDFs? O Win2D já tem muitas ferramentas incríveis, a capacidade de gerar PDF a partir de CanvasRenderTarget será uma grande adição.

não entendi - como instalar o vsix? onde baixar?

Talvez seja só eu, mas fiquei desapontado com a ligação de hoje. Por favor inclua mais pessoas técnicas. O PM deve manter a discussão focada e seguindo o cronograma, mas delegar as respostas aos especialistas (como foi feito mais no final).

Suponho que todos nesta chamada são desenvolvedores e precisamos saber e discutir os detalhes. Os PMs estão se concentrando em tópicos muito básicos e não são capazes de entrar em detalhes. Por exemplo, as discussões no início da chamada sobre documentação / WebView / ProgressRing são boas no conceito, mas muito básicas que não são úteis para nós, eu acho. Temos usado o XAML por anos / décadas e você está falando para um público especializado (é importante adaptar as apresentações ao público).

@SavoySchuler Parafraseando, você basicamente disse, diga-nos como estamos usando os controles, inclua nossa empresa e nossos aplicativos. Você precisa disso para separar as necessidades de materiais e o que é bom ter. Isso ajuda você a priorizar recursos em recursos. Você precisa pensar sobre isso de forma diferente por duas coisas:

1. Características - neste caso, o que você disse está amplamente correto
2. Bugs / problemas - neste caso, não, você não precisa que a comunidade dê exemplos para ajudar a priorizar. Ao entregar qualquer produto, a qualidade é sua prioridade número 1. Estamos contando a você os bugs e você está dizendo, bem, sim, é bom ter. Prove que você precisa consertar. É um bug. Talvez você nunca tenha enviado aplicativos aos consumidores? Qualquer pequena coisa errada em TODOS afeta sua imagem e percepção, que é a parte mais valiosa de uma empresa. A indústria de aplicativos é muito competitiva.

Assim que os bugs forem relatados pela comunidade, você deve programá-los para serem corrigidos. Pare de enviar controles incompletos sem planos para consertá-los. Isso está começando a soar muito familiar - é o que aconteceu com a UWP anos atrás.

Na chamada, eu mencionei o janelamento duas vezes e foi mencionado que:

• isso está sendo feito para WinUI 3 (apesar do problema estar congelado https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• o projeto Feature Tracking (atualizado ontem) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) está rastreando apenas o WinUI 2 ???

Podemos obter alguma clareza aqui? Existe outro local para ver o backlog do WinUI 3? É extremamente crítico para fins de planejamento saber o que está por vir e o que não está. Obrigado!

@SavoySchuler @jesbis e o resto da adorável equipe do WinUI, eu pessoalmente quero agradecer a vocês por seu excelente trabalho e esforços massivos e dizer o quão grato eu sou por tornar o WinUI tão incrível e também por responder a todas as minhas perguntas.

Um grande obrigado a todos que puderam sintonizar!

E desculpe novamente pelos problemas de áudio e de equipes - achamos que identificamos um problema de hardware e esperamos ter tudo resolvido para o próximo mês.

A gravação está ao vivo agora também para qualquer um que não pudesse comparecer.

Estamos analisando as perguntas e tentaremos encontrar qualquer coisa que tenhamos perdido neste tópico.

Algumas perguntas:

Haverá alguma ferramenta para gerar PDFs?

@MuziburRahman

Não teremos tempo para chegar a isso para WinUI 3.0 RTM, mas estamos rastreando isso no backlog com # 672 - fique à vontade para adicionar um comentário a esse problema sobre como você o usaria!

como instalar o vsix? onde baixar?

@hannespreishuber

As instruções de uso do WinUI 2.x para aplicativos de produção estão aqui: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

As instruções do WinUI 3.0 Alpha para instalar e experimentar o vsix estão aqui:
https://aka.ms/winui/alpha

Talvez seja só eu, mas fiquei desapontado com a ligação de hoje. Por favor inclua mais pessoas técnicas. O PM deve manter a discussão focada [...] Temos usado XAML por anos / décadas e você está falando para um público especialista (é importante adaptar as apresentações ao público).

@robloo obrigado pelo feedback sobre isso. Podemos incluir mais desenvolvedores e fazer análises mais aprofundadas sobre tópicos específicos para chamadas futuras, se isso for do interesse de todos - não queríamos tentar isso na primeira chamada, pois já faz um tempo e queríamos fazer um apanhado geral acima.

Também recebemos feedback no passado de que às vezes ficamos muito técnicos e aprofundados porque grande parte do público ainda não está muito familiarizado com o WinUI - então, estamos tentando equilibrar esse feedback também.

Além disso, se ajuda observar: muitos de nossos PMs nas equipes de plataforma de desenvolvedor são supertécnicos e têm experiência em escrever código de produção para as principais plataformas e aplicativos reais. Alguns deles eram desenvolvedores em tempo integral na Microsoft e em outras empresas. Também ainda escrevemos código o tempo todo como PMs, mas não é nosso único foco 🙂

Por fim, sobre bugs e qualidade: qualidade é super importante para nós e gastamos muito tempo com bugs, testes e infraestrutura de qualidade. Você pode ver a relação entre as correções de qualidade e os novos recursos no log de confirmação do WinUI 2 e, uma vez que ele seja de código aberto, você poderá ver o mesmo para o WinUI 3. Dito isso, nenhuma base de código principal está livre de bugs e nós sempre tem que equilibrar as prioridades de negócios.

Se os controles parecerem incompletos, abra questões para eles.

Na chamada, eu mencionei o janelamento duas vezes e foi mencionado que:
na verdade, isso está sendo trabalhado para WinUI 3 (apesar do problema estar congelado # 1247)
o projeto Feature Tracking (atualizado ontem) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) está rastreando apenas o WinUI 2 ???
Podemos obter alguma clareza aqui? Existe outro local para ver o backlog do WinUI 3? É extremamente crítico para fins de planejamento saber o que está por vir e o que não está. Obrigado!

@riverar, esse quadro de projeto é atualmente para WinUI 2, pois é o único código no repo atualmente.

Usamos o rótulo needs-winui-3 para problemas que terão que esperar pelo WinUI 3 antes que possam ser resolvidos adequadamente, mas ainda não temos rastreamento público para o nosso trabalho com o WinUI 3.

Continuaremos a postar propostas de recursos para itens principais - como a especificação Chromium WebView no repositório de especificações separado:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

e assim que formos capazes de abrir o código-fonte do WinUI 3 Xaml, podemos começar a mover o rastreamento para o GitHub, mas a maior parte do nosso rastreamento de itens de trabalho do dia-a-dia irá realisticamente permanecer interno durante o desenvolvimento do 3.0 por vários motivos (temos muitos de dependências privadas do sistema operacional para desemaranhar, necessidade de interagir de perto com outras equipes de desenvolvimento de componentes do sistema operacional, etc.)

Posso dizer, porém, que a maioria dessas sugestões de recursos marcados não serão abordadas para a versão 3.0 inicial - nossas principais áreas de foco são:

• obter WinUI desacoplado do sistema operacional e enviado separadamente
• abrir o código do framework Xaml
• criar uma boa experiência de desenvolvimento de aplicativos de desktop WinUI (uso do win32, empacotamento, janelas, etc.)
• habilitando o Windows 10X
• habilitando aplicativos .NET Core / 5 + WinUI

e não queremos atrasar ou desestabilizar isso tentando fazer uma tonelada de desenvolvimento de novos recursos adicionais ao mesmo tempo.

Conforme fazemos progressos concretos em grandes áreas, como suporte para desktop / janelas, postaremos propostas e atualizações para o repo.

e assim que formos capazes de abrir o código-fonte do WinUI 3 Xaml, podemos começar a mover o rastreamento para o GitHub, mas a maior parte do nosso rastreamento de itens de trabalho do dia-a-dia irá realisticamente permanecer interno durante o desenvolvimento do 3.0 por vários motivos (temos muitos de dependências privadas do sistema operacional para desemaranhar, necessidade de interagir de perto com outras equipes de desenvolvimento de componentes do sistema operacional, etc.)

Seria possível listar esses itens de trabalho internos publicamente, mesmo se eles aparecerem como entradas em branco com algum nome genérico como Problema Interno ? Vê-los passar de A fazer, para Em andamento e para Concluído - indicaria algum grau de progresso para todo o projeto.

Posso dizer, porém, que a maioria dessas sugestões de recursos marcados não serão abordadas para a versão 3.0 inicial - nossas principais áreas de foco são:

• obter WinUI desacoplado do sistema operacional e enviado separadamente
• abrir o código do framework Xaml

Este é, obviamente, o núcleo do esforço, mas pode ser possível resolver vários problemas ou questões com a implementação atual, à medida que está sendo extraído do código do sistema operacional.

• criar uma boa experiência de desenvolvimento de aplicativos de desktop WinUI (uso do win32, empacotamento, janelas, etc.)
• habilitando o Windows 10X

Isso será essencial para acertar e exigirá colocar essas duas coisas nas mãos de usuários e desenvolvedores, com a mente aberta para aceitar feedback. Também será difícil porque o tempo de execução do aplicativo e o modal do aplicativo não são de propriedade desta equipe WinUI e, portanto, é necessário ativar o feedback para filtrar os responsáveis ​​por eles.

• habilitando aplicativos .NET Core / 5 + WinUI

O suporte nativo atual vem na forma de código C ++ e APIs Win32 - mas isso significa que qualquer desenvolvedor C # precisa ter como alvo o .NET? O modelo de aplicativo sem área restrita permitirá a codificação C # sem .NET?

e não queremos atrasar ou desestabilizar isso tentando fazer uma tonelada de desenvolvimento de novos recursos adicionais ao mesmo tempo.

Conforme fazemos progressos concretos em grandes áreas, como suporte para desktop / janelas, postaremos propostas e atualizações para o repo.

Sem o CoreWindow (que será UWP apenas daqui para frente) - o janelamento é uma daquelas coisas que precisará estar em vigor desde o primeiro dia. O WPF tem um objeto Window em XAML que lida com os controles, estilo visual, transparência etc. Ele lida com redimensionamento, minimização, etc. Frameworks Win32 mais antigos exigem pintura manual de superfícies que não são uma coisa para IUs XAML - então, como essa lacuna é eliminada ?

Isso é antes mesmo de chegarmos aos dispositivos com tela dupla, e como um modelo de aplicativo não UWP e uma configuração de janela se adaptariam a isso.

Seria possível listar esses itens de trabalho internos publicamente, mesmo se eles aparecerem como entradas em branco com algum nome genérico como Problema Interno?

Nosso objetivo é definitivamente mover nossos processos (incluindo rastreamento de problemas) para código aberto, além do código.

Para começar, temos um marco WinUI 3.0 para rastreamento de alto nível e, conforme migramos o código WinUI 3 Xaml para o código aberto, também abriremos mais problemas de "nível de recurso" nesse marco.

No entanto, isso não incluirá todas as nossas tarefas de desenvolvimento diárias do WinUI 3.0 imediatamente - para referência, estamos rastreando milhares de dias de trabalho de desenvolvimento relacionado para 2020 e ainda não estamos prontos para mover todos nosso rastreamento supergranular para o GitHub hoje. No entanto, chegaremos a isso com o tempo, como fizemos com o WinUI 2.

Portanto, começaremos com problemas de nível de recurso (como os iniciados até agora - por exemplo, WebView) e migraremos totalmente nossos processos para o GitHub com o tempo.

O suporte nativo atual vem na forma de código C ++ e APIs Win32 - mas isso significa que qualquer desenvolvedor C # precisa ter como alvo o .NET? O modelo de aplicativo sem sandbox permitirá a codificação C # sem .NET?

Você está perguntando sobre o .NET Native ou nenhum .NET? Tecnicamente, acho que a especificação C # como linguagem não depende do .NET, mas atualmente não temos planos de transpilar para C ++ ou algo parecido.

Sem o CoreWindow (que será UWP apenas daqui para frente) - o janelamento é uma daquelas coisas que precisará estar em vigor desde o primeiro dia. O WPF tem um objeto Window em XAML que lida com os controles, estilo visual, transparência etc. Ele lida com redimensionamento, minimização, etc. Frameworks Win32 mais antigos exigem pintura manual de superfícies que não são uma coisa para IUs XAML - então, como essa lacuna é eliminada ?

@ marb2000 está trabalhando nisso e poderá compartilhar mais informações disponíveis.

Isso é antes mesmo de chegarmos aos dispositivos com tela dupla, e como um modelo de aplicativo não UWP e uma configuração de janela se adaptariam a isso.

Para ser claro, o WinUI 3 não trará todos os desktops win32 para outras plataformas como o HoloLens: aplicativos universais e APIs ainda serão o caminho a percorrer ao se direcionar a vários dispositivos.

Postado muito cedo. Comentário completo:

@robloo - Quero começar concordando com muito de seu sentimento e agradeço por você ter

Carta e recursos

Sei que pisar em qualquer assunto como este nunca será popular, mas acredito na transparência e quero ser franco com vocês, como comunidade, sobre os desafios que enfrentamos, para que possam fazer parte da discussão e nos ajudar a decidir como os resolveremos . Este desafio particular concentra-se na divisão de tempos e ativos de recursos. Existem três iniciativas principais nas quais nossa equipe está dividida:

1. Avançando WinUI 2
2. Entregando WinUI 3
3. WinUI 3 de código aberto

Como você sabe, estamos direcionados firmemente para 2 e 3 porque A) esses são objetivos acoplados e B) WinUI de código aberto significa que todos podem parar de ser bloqueados pelos recursos finitos de nossa equipe porque o WinUI finalmente terá poderes para aceitar solicitações de pull da comunidade.

Se estamos marcados demais para a frente sobre os objectivos 2 e 3 a um ponto onde WinUI 2 é sub-servindo os membros da comunidade, podemos ter essa conversa e estamos abertos a reprioritizing. Apenas saiba que resolver todos os bugs em nosso backlog atrasaria o lançamento do WinUI 3 no mercado em aproximadamente 6 meses. Devemos priorizar 2 e 3, que não apenas abrem o código do WinUI, mas expandem sua relevância para nossa enorme base de desenvolvedores Win32, seremos capazes de limpar nosso acúmulo de bugs _e_ solicitações de recursos com o poder da comunidade de código aberto e de nossa equipe atenção total nos apoiando. Para esse fim, nosso raciocínio atual é que o plano de abordagem não apenas moveria essa plataforma para frente mais rápido, mas também de forma mais abrangente. Quando pedi que você nos ajudasse a priorizar os bugs, a pergunta não era "eles são importantes o suficiente para serem resolvidos por nossa equipe?" mas em vez disso, "isso é importante do que abrir o código do WinUI mais cedo?" No status quo, temos um subconjunto de desenvolvedores trabalhando para avançar a prioridade 1 e você pode ver o impacto deles em nosso histórico de commits e problemas ativos, mas eles enfrentam a necessidade de priorizar dentro desse objetivo da mesma forma. Esta noção de "diga-nos como isso é importante para você" nos ajuda a filtrar as necessidades (por exemplo, meu produto está bloqueado e eu não posso esperar pelo WinUI 3) versus sutilezas (por exemplo, percebi este erro técnico, mas nenhum desenvolvimento existente está bloqueado nele para que possa esperar pelo WinUI 3).

A outra coisa que eu quero dizer claramente é que todo o trabalho vai para a apresentação de WinUI 2 erros, preenchendo pedidos de recurso, etc., irá _ não _ ser perdida por nós. Quando o WinUI 3 for lançado, teremos um subconjunto significativo de nossa equipe livre para retornar aos itens de trabalho que avançam a plataforma, além de capacitar a comunidade para enviar código também. Isso significa que agora estamos preparando um backlog que toda a força de nossa equipe resolverá com a ajuda de nossa comunidade UWP existente e, em breve, do Win32 também.

Uma coisa adicional a estar ciente é que, enquanto estamos migrando o código do sistema operacional para o WinUI 3, estamos tomando medidas para simplificar e limpar o código onde pudermos. Isso significa que certas adições de recursos e correções de bugs exigirão mensuravelmente menos tempo e esforço se resolvidas no WinUI 3.

NumberBox

Recursos

Voltemos a NumberBox. Você está factualmente correto ao dizer que V1 é um subconjunto dos recursos desejados.
Os recursos planejados da V1 foram atrasados ​​até a V2 devido a dependências de coisas como validação de entrada (que, a propósito, está em visualização no WinUI 3 alfa). Tentamos ser completos em nossa especificação reconhecendo tudo o que achamos que merecia ser V1 na especificação (aqui) e planejamos cumprir totalmente esse compromisso com uma versão WinUI 3 V2 do controle.

Ao abraçar o espírito do código aberto, meu desejo (e diga se estou errado ao fazer isso) é preferir lançar código confiável e útil o mais rápido possível e construir conjuntos de recursos de forma incremental. Na aplicação, isso significava preferir lançar nosso _principalmente_ V1 completo no WinUI 2 e segui-lo com um lançamento completo com validação de entrada como podemos com o WinUI 3.

Insetos

Como @jesbis disse, nenhuma base de código está livre de bugs, mas a qualidade é absolutamente a nossa @jesbis observou, você pode ver a relação entre as correções de qualidade e os novos recursos no log de confirmação do WinUI 2 e, uma vez que esteja com o código aberto, você poderá ver o mesmo para o WinUI 3.

Continuo empenhado em ajudar a resolver esses bugs com a NumberBox e estou reservando o resto do meu dia para responder a problemas em aberto, bugs e perguntas em que posso ser um trunfo. Vou reservar um dia na próxima semana também. Sinta-se encorajado a me enviar perguntas no Twitter ou conversar comigo sobre isso aqui no repo.

Próximos passos

Para nós, o código aberto é a promessa de abraçar a comunidade como membros da equipe, como se estivessem aqui em nosso escritório em Redmond. Estamos ouvindo ouvindo. Vamos conversar sobre essas decisões juntos para que possamos nos concentrar em construir coisas incríveis como uma grande equipe. 🙂

Nós ❤️ WinUI

Ao abraçar o espírito do código aberto, meu desejo (e diga se estou errado ao fazer isso) é preferir lançar código confiável e útil o mais rápido possível e construir conjuntos de recursos de forma incremental. Na aplicação, isso significava preferir lançar nosso V1 quase completo no WinUI 2 e segui-lo com um lançamento completo com validação de entrada, como podemos com o WinUI 3.

Poderia ser apenas eu, mas sinto que, embora seja importante enviar o código o mais rápido possível, existem certos tipos de problemas que devem ser resolvidos antes de enviar qualquer coisa, por exemplo # 1846 é algo que deve ser resolvido antes de enviar V1 e ali pode haver alguns outros também.

@yaichenbaum Eu poderia ter escolhido melhor minhas palavras lá. 🙂

Se AD é _deve ter_ recursos e EH é _agradável de ter_ recursos, minha prioridade é fazer o AD sair da porta e adicionar EH incrementalmente possível.

O motivo pelo qual fazemos teste em um branch de visualização com parceiros de validação é detectar bugs como o # 1846 antes que os controles sejam enviados para uma versão estável. Desculpe por termos falhado nisso, irei trabalhar com

Em um ponto da chamada, foi mencionado que os aplicativos WinUI permitiriam o sandbox por meio do AppDomain.

Alguém pode falar sobre como o WinUI 3.0+ posicionará Capabilities vs. AppDomain para isolamento de aplicativos e controle de recursos?

Além disso, da última vez que soube para .Net Core, o suporte total para AppDomain não estava acontecendo.

Talvez eu esteja sem contato, mas você está dizendo que o .Net 5 terá suporte total para AppDomain?

Obrigado por organizar esta chamada hoje!

Alguém pode falar sobre como o WinUI 3.0+ posicionará Capabilities vs. AppDomain para isolamento de aplicativos e controle de recursos?

Desculpe se não ficou claro na chamada, mas eu estava falando sobre AppContainer , não AppDomain.

Ah, ok, obrigado pelo esclarecimento Jesse.

Em primeiro lugar, obrigado @SavoySchuler e @jesbis (e todo o resto da equipe WinUI) por organizar a chamada da comunidade de hoje! Embora tenha havido algumas dificuldades técnicas, esta chamada foi muito esclarecedora !!!

Como @jesbis mencionou, há um problema ao rastrear as ferramentas e recursos solicitados para WinUI 3.0. Seria melhor dividir a solicitação de uma ferramenta de conversão WinUI 2.x para 3.0 em um problema separado para facilitar o rastreamento? Também já existem planos? Existem planos para tornar a ferramenta de código aberto para que outros desenvolvedores possam ajudar a desenvolvê-la?

Outra questão mais geral (que também seria para outros membros da equipe não WinUI) é sobre a contribuição. Há algum obstáculo que esteja impedindo as pessoas de contribuir? Um guia de primeiros passos melhor para colaboradores ajudaria?

Na minha opinião, se você começar a contribuir com o projeto, o Projeto VS pode ser um pouco opressor, e não há muita documentação sobre como desenvolver, qual projeto de teste deve ser usado para quê etc ...

Talvez as melhorias nessa área tornassem mais fácil para as pessoas contribuírem 😅

Como é feita a camada de renderização do WinUI 3.0? Faz uso direto de D3D11, D2D, camada de abstração ou o quê? Ele tem uma camada de renderização de software ou faz uso do D3D WARP para isso?

@chingucoding

Vou repetir os pontos que acabei de mencionar aqui :

• Não tendo usado a linguagem para sempre
• Não tenho ideia de quanta mudança de código está acontecendo em segundo plano para a versão WinUI 3 que iria sobrescrever as alterações feitas hoje
• Sem acesso a um monte de código-fonte que seria necessário e / ou ajudaria tremendamente a resolver os problemas

Edit: Vou dar um exemplo. # 1555 e # 1849 são aparentemente os principais problemas com um controle principal (TextBox) que impedem a entrada e seleção de texto durante a multitarefa.

Eles estão no topo da minha lista de questões importantes que devem ser resolvidas, mas não tenho ideia por onde começar. Também não sei se o código que desejo / preciso percorrer para depurar está disponível.

@SavoySchuler

Se formos direcionados muito para a frente nos objetivos 2 e 3 a um ponto onde o WinUI 2 está servindo mal os membros da comunidade, podemos ter essa conversa e estamos abertos para redefinir a prioridade. Apenas saiba que resolver todos os bugs em nosso backlog atrasaria o lançamento do WinUI 3 no mercado em aproximadamente 6 meses.

Eu certamente entendo. No entanto, NumberBox é um pouco diferente aqui em minha mente e certamente não estou dizendo que devemos nos concentrar em todos os bugs. No momento, falarei apenas no contexto da NumberBox. Embora certamente haja algumas outras questões gritantes que precisam ser abordadas.

NumberBox é um controle recém-desenvolvido para WinUI 2.3 e não um controle legado que todos têm que aceitar neste momento. Por que não faríamos isso corretamente para começar? Este é um teste decisivo do novo modelo de desenvolvimento.

Se AD deve ter recursos e EH é bom ter recursos, minha prioridade é lançar o AD e adicionar EH incrementalmente possível.

Eu concordo totalmente com você aqui. Mas você deve entender a diferença entre recursos e bugs. Preocupa-me que você esteja pensando apenas em termos de recursos / mão de obra para a Microsoft. No entanto, você já pensou que os desenvolvedores de aplicativos perdem horas incontáveis ​​tentando contornar bugs nos controles? É muito mais eficiente consertar essas coisas na fonte e também ajuda muito a percepção da plataforma / ferramentas.

A outra coisa que quero dizer com clareza é que todo o trabalho que vai para o arquivamento de bugs do WinUI 2, preenchimento de solicitações de recursos, etc., não será perdido por nós. Quando o WinUI 3 for lançado, teremos um subconjunto significativo de nossa equipe livre para retornar aos itens de trabalho que avançam a plataforma, além de capacitar a comunidade para enviar código também.

A Microsoft tem um histórico péssimo de lançar softwares incompletos e então passar para a próxima e melhor tecnologia antes de ter a chance de concluir a última. Por favor, perdoe-me por ser cético em relação à sua promessa.

Voltemos a NumberBox. Você está factualmente correto ao dizer que V1 é um subconjunto dos recursos desejados.
... Ao abraçar o espírito do código aberto, meu desejo (e, por favor, diga se estou errado ao fazer isso) é preferir totalmente o lançamento de código confiável e útil o mais rápido possível e construir os conjuntos de recursos de forma incremental.

Totalmente na mesma página com você em termos de recursos. Os insetos são diferentes. Você precisa resolver os bugs de maneira diferente dos recursos e comprometer mais recursos com eles. Parece ruim lançar um controle totalmente novo como o NumberBox e então dizer que você não pode comprometer recursos para consertar bugs até um ano a partir de agora.

Estou pedindo que você resolva os bugs na V1 do controle que não dependem do WinUI 3.0. Alguns são bastante básicos e outros são erros gritantes de design (como NaN travando dados de duas vias). Depois de se comprometer a lançar um recurso / controle, você deve trabalhar rapidamente para fechar os bugs. SEMPRE há bugs quando o software é lançado pela primeira vez, você só precisa planejar os recursos para fazer uma rápida correção de bug V2 (como o resto de nós, desenvolvedores de aplicativos). Como concordamos que a qualidade é uma prioridade, corrija os seguintes problemas com a NumberBox antes de prosseguir com outras coisas.

1708 - O texto do espaço reservado é absolutamente necessário com qualquer uso de formulário do controle e um dos recursos básicos já na especificação. Se isso foi realmente corrigido para NaN, devemos fechá-lo. O suporte nulo é um tópico diferente abaixo.

1721 - Um grande problema com UWP era o suporte incompleto para vinculação de dados em determinados controles. Muitos desenvolvedores de aplicativos investiram no design do MVVM anos atrás e, em seguida, tentando pular para os controles UWP, a vinculação de dados descoberta era apenas parcialmente suportada. Este é um grande ponto de dor e é inaceitável, considerando o quão fundamental é o MVVM para as práticas recomendadas da Microsoft. A velha equipe de ferramentas do desenvolvedor do Windows nunca aceitaria isso - esse é o pensamento nativo do Windows aqui.

1839 - Coisas básicas aqui. Esses são apenas bugs básicos no modelo de controle e DEVEM ser corrigidos. Sem desculpas.

1846 - Já tivemos esse problema em muitos outros controles anteriormente. Por que não existe uma lista de verificação de lançamento que testa isso agora? Novamente, coisas básicas que precisam ser consertadas. Afeta a usabilidade de todos os aplicativos que usam este controle.

1852, # 1853, # 1854 - Novamente, eles não são excessivamente complicados e foram deixados de lado na primeira implementação. No entanto, é um requisito legal oferecer suporte à acessibilidade em softwares vendidos em certas regiões ou desenvolvidos para o governo. Como plataforma, você deve corrigir isso imediatamente para que os desenvolvedores de aplicativos possam usar o controle. Novamente, eu não deveria ter que debater esse tipo de coisa com você, são coisas básicas.

Uma coisa adicional a estar ciente é que, enquanto estamos migrando o código do sistema operacional para o WinUI 3, estamos tomando medidas para simplificar e limpar o código onde pudermos. Isso significa que certas adições de recursos e correções de bugs exigirão mensuravelmente menos tempo e esforço se resolvidas no WinUI 3.

Compreenda em alto nível. No entanto, corrigir os problemas acima não vai atrasar o WinUI 3.0 por 6 meses. Eles também não dependem do WinUI 3.0 para serem endereçados (exceto potencialmente para # 1721). Você está estabelecendo um precedente perigoso ao lançar o NumberBox e não insistir nele para fechar a primeira rodada de bugs. Você já deve ter aprendido esta lição com a própria UWP.

Talvez melhorias nessa área tornem mais fácil para as pessoas contribuírem

Adoraria contribuir. Não adoro trabalhar com C ++ / WinRT e certamente não me sinto qualificado para mexer na base de código como já vi. Se os controles fossem gerenciados em C #, você teria muito mais contribuições. Eu entendo porque a arquitetura é o que é, mas uma das consequências são menos contribuições da comunidade. Não somos desenvolvedores de sistema aqui, somos desenvolvedores de aplicativos para usuários finais.

RE: contribuindo:

Outra questão mais geral (que também seria para outros membros da equipe não WinUI) é sobre a contribuição. Há algum obstáculo que esteja impedindo as pessoas de contribuir? Um guia de primeiros passos melhor para colaboradores ajudaria?
Na minha opinião, se você começar a contribuir com o projeto, o Projeto VS pode ser um pouco opressor, e não há muita documentação sobre como desenvolver, qual projeto de teste deve ser usado para quê etc ...
Talvez melhorias nessa área tornem mais fácil para as pessoas contribuírem

Nada deve impedir as pessoas de contribuir para o WinUI 2, que é a base de código atualmente no repo. Se houver um problema com o WinUI 2 que você deseja trabalhar, informe-nos e podemos atribuí-lo a você!

Temos muitos itens marcados com boa primeira edição e precisamos de ajuda se alguém quiser ajudar com itens que devem ser (relativamente) fáceis de começar 🙂

Para correções de bugs, você pode apenas abrir um PR. Se for um novo recurso importante, então também temos um pouco de processo para revisar o problema primeiro para ter certeza de que a proposta é adequada para WinUI.

Concordo totalmente que o guia do contribuidor poderia ser melhor e que é difícil começar - recentemente passei pelo exercício de tentar segui-lo para implementar um novo recurso ( RadialGradientBrush ) e descobri que ele poderia

Vou dar um exemplo. # 1555 e # 1849 são aparentemente os principais problemas com um controle principal (TextBox) que impedem a entrada e seleção de texto durante a multitarefa.
Eles estão no topo da minha lista de questões importantes que devem ser resolvidas, mas não tenho ideia por onde começar. Também não sei se o código que desejo / preciso percorrer para depurar está disponível.

Eles ainda precisam ser triados (categorizados) pelos nossos proprietários de desenvolvimento (daí o rótulo "triagem de necessidades" - no momento, estou acompanhando por que eles ainda não foram, desculpe), mas espero que, uma vez que TextBox não está em WinUI 2 aqueles terão que esperar pelo WinUI3.

Depois de fazer a triagem, eles devem ter o rótulo needs-winui-3 aplicado, o que indica que eles terão que esperar pelo WinUI 3 antes que possamos resolvê-los.

Depois que o WinUI 3 for de código aberto, qualquer pessoa também poderá ajudar a resolver esses problemas.

Não adoro trabalhar com C ++ / WinRT e certamente não me sinto qualificado para mexer na base de código como já vi. Se os controles fossem gerenciados em C #, você teria muito mais contribuições.

Sabemos que C ++ é uma barreira maior do que C #, mas o plano é que o WinUI continue sendo uma plataforma C ++.

Outro grande projeto com o qual contribuir é o Windows Community Toolkit, com o qual é mais fácil contribuir porque é C # e tem alguns requisitos flexíveis.

Trabalhamos com os mantenedores e frequentemente usamos o Community Toolkit para incubar novos controles que eventualmente migram para a plataforma Xaml (o que envolve reimplementação em C ++).

O WinUI requer C ++ / CX? Se assim for, parece que este é um problema para o Win32 e outros destinos futuros?

Como é feita a camada de renderização do WinUI 3.0? Faz uso direto de D3D11, D2D, camada de abstração ou o quê? Ele tem uma camada de renderização de software ou faz uso do D3D WARP para isso?

A renderização da estrutura WinUI Xaml é implementada principalmente no mecanismo de composição do

No final, isso geralmente significa renderização acelerada por hardware usando Direct3D, Direct2D e DirectWrite, com renderização por software em alguns casos onde faz sentido.

Você também pode incluir seu próprio conteúdo DirectX personalizado usando APIs de interoperabilidade.

O WinUI requer C ++ / CX? Se assim for, parece que este é um problema para o Win32 e outros destinos futuros?

Não - a plataforma WinUI é escrita em C ++, mas seus aplicativos definitivamente não precisam ser!

Com o WinUI 2 hoje você pode criar aplicativos UWP usando .NET (C #, VB.NET) ou C ++.

Com o WinUI 3, nosso objetivo é que você possa criar aplicativos que usam APIs UWP e / ou win32 usando o .NET 5 ou C ++ que está por vir.

@jesbis , acho que você pode estar entendendo um pouco a intenção das minhas perguntas.

1) Eu sei que o WinUI é escrito em C ++, mas algum código WinUI requer extensões VC ++ / CX do Windows apenas? Se ele requer extensões CX, vejo isso como uma causa de problemas de portabilidade no futuro, caso o WinUI deseje expandir para outras plataformas. Isso pode tornar difícil para a equipe UNO adotar o código, por exemplo.

2) Sobre o sistema de renderização. Algumas coisas aqui.

2.a) A "camada visual" é uma API de abstração removida longe o suficiente das APIs DirectX para que posteriormente pudesse suportar um back-end Vulkan, por exemplo? (Tenho certeza que esta pergunta será respondida quando a fonte for divulgada, mas estou apenas pensando)

2.b) Minha pergunta sobre rasterização de software foi mais na linha: O WinUI 3.0 suportará renderização de software completa (não apenas renderização de texto ou sei lá)? Às vezes, o software de compartilhamento de tela tem problemas com aplicativos acelerados por GPU (pelo menos com D3D9 / WPF) e forçar a renderização do software corrige o problema nessas situações). Ou se o aplicativo for executado em uma VM sem GPU de hardware.

As instruções do WinUI 3.0 Alpha para instalar e experimentar o vsix estão aqui:
https://aka.ms/winui/alpha

fiz isso com o Edge New o link de download não apareceu, repetiu com o Chrome- download aqui

fiz isso com o Edge New o link de download não apareceu, repetiu com o Chrome- download aqui

@hannespreishuber o link para download deve estar na última página da pesquisa. Você quer dizer que a pesquisa não funcionou no Chromium Edge, mas funcionou no Chrome?

o link para download deve estar na última página da pesquisa. Você quer dizer que a pesquisa não funcionou no Chromium Edge, mas funcionou no Chrome?

fiz a pesquisa em ambos - mas a última página foi diferente, talvez minha culpa.

fiz a pesquisa em ambos - mas a última página foi diferente, talvez minha culpa.

Ok, obrigado - testamos a pesquisa em ambas as versões do Edge e parecia funcionar, então se alguém tiver problemas com o download, informe-nos e também relate o problema no Edge se o conteúdo da página for processado de maneira diferente do Chrome (Configurações> Ajuda e Feedback> Enviar feedback) 🙂

Eu sei que WinUI é escrito em C ++, mas algum código WinUI requer extensões VC ++ / CX do Windows apenas? Se requer extensões CX, vejo isso como uma causa de problemas de portabilidade

@ zezba9000 , implementamos os controles e recursos do WinUI 2 (o novo código atualmente no repo) usando C ++ / WinRT que é o C ++ 17 padrão, mas o resto do WinUI 3 é uma base de código muito maior e mais antiga que ainda dependerá no WRL etc. Não estamos nos concentrando na portabilidade no momento, mas estamos abertos para discutir isso no futuro.

A "camada visual" é uma API de abstração removida longe o suficiente das APIs DirectX para que posteriormente pudesse oferecer suporte a um back-end Vulkan, por exemplo? (Tenho certeza que esta pergunta será respondida quando a fonte for divulgada, mas estou apenas pensando)

Não estamos focando na portabilidade neste momento para a camada visual. Existem alguns acoplamentos frouxos entre a camada Visual e as APIs DirectX (sem contar a implementação), mas é principalmente abstraído. Além disso, para esclarecer sobre o código aberto: nosso alvo inicial para código de código aberto e nossos processos de desenvolvimento do dia a dia é a estrutura Xaml, que não incluirá código aberto na camada visual neste momento.

Minha pergunta sobre a rasterização de software foi mais na linha de: O WinUI 3.0 suportará renderização de software completa (não apenas renderização de texto ou sei lá)? Às vezes, o software de compartilhamento de tela tem problemas com aplicativos acelerados por GPU (pelo menos com D3D9 / WPF) e forçar a renderização do software corrige o problema nessas situações). Ou se o aplicativo for executado em uma VM sem GPU de hardware.

Sim, a renderização por compartilhamento de tela, em VMs etc. deve funcionar. Para a maior parte do conteúdo, não deve haver diferença visível. Se você examinar o código WinUI 2 no repo, também poderá ver o uso de uma API que usamos para consultar se certos efeitos são suportados / "rápidos" em tempo de execução e voltar para uma renderização mais simples de certos efeitos em alguns casos, mas os aplicativos não devem não precisa fazer nada especial para oferecer suporte à renderização de software ao usar os controles e recursos padrão da plataforma.

Eu concordo totalmente com você aqui. Mas você deve entender a diferença entre recursos e bugs. Preocupa-me que você esteja pensando apenas em termos de recursos / mão de obra para a Microsoft. No entanto, você já pensou que os desenvolvedores de aplicativos perdem horas incontáveis ​​tentando contornar bugs nos controles? É muito mais eficiente consertar essas coisas na fonte e também ajuda muito a percepção da plataforma / ferramentas.

Concordo 100% - nem quero me lembrar do número de horas que gasto resolvendo bugs do UWP / WinRT.

Jesse,

Estou principalmente preocupado com o desenvolvimento de aplicativos corporativos. Atualmente, estou usando o WinUI 3.0 Alpha para construir uma prova de conceito para demonstrar como Xaml, GPRC, várias janelas e multithreading podem oferecer à empresa e ao usuário empresarial uma experiência de aplicativo mais produtiva.

Porque? Porque precisamos de uma alternativa para aplicativos de tela pequena / baseados em navegador. Tenho muito mais a dizer sobre esse assunto, mas vou KISS aqui.

O que eu gostaria da equipe WinUI e, na verdade, da Microsoft, é abraçar e apoiar a criação de aplicativos de desktop para empresas.

Houve três razões principais pelas quais os aplicativos da web foram adotados na empresa tão rapidamente - suporte para várias plataformas, segurança e fácil implantação. Para ser uma alternativa viável, os aplicativos de desktop precisam de respostas para essas perguntas.

Parece que a maior parte da indústria de desenvolvimento de software está focada em entregar aplicativos para o navegador e / ou formato móvel / tablet.

Os aplicativos corporativos são executados em estações de trabalho com muita CPU, tamanho de tela, memória, armazenamento, gráficos e largura de banda quando comparados com os aplicativos “móveis primeiro”. Os usuários desses aplicativos LOB podem se engajar por horas e horas seguidas. Precisamos de orientações sobre o design do aplicativo para lidar com esses fatores.

Existem outras dimensões em aplicativos corporativos que não recebem muita discussão - longevidade e conjunto de habilidades. Novamente, muito a dizer aqui, mas vou resumir. As empresas investem dinheiro na criação de aplicativos e planejam usá-los por “muito” tempo. Isso significa que a tecnologia subjacente precisa ser suportada por décadas. Gostaria de ver o WinUI como a próxima tecnologia de longa duração a substituir o Win32 / MFC e o WinForms.

Os departamentos de TI lutam constantemente para encontrar SEs com o conjunto de habilidades certo. A tecnologia da Web tornou isso ainda mais desafiador. Eu gostaria de ver uma nova pilha C #, Xaml e SQL (C # XS) que identifica um foco na construção de aplicativos de desktop.

Há também um ponto menor que eu gostaria de fazer com relação ao estilo. Os aplicativos corporativos WinUI devem exigir um mínimo de estilo “pronto para uso” para serem funcionais. Além disso, e isso pode ser direcionado diretamente para Fluent, mas não esconda os controles (como barras de rolagem). Os usuários corporativos têm muitas telas em estado real e não se importam com o quão “linda” uma IU é se eles não sabem que há mais em uma página.

Precisamos de um controle de datagrid robusto (gratuito). Não posso enfatizar isso o suficiente.

Tenho mais ideias para compartilhar se você estiver interessado, mas vou parar por aqui e resumir:

• A Microsoft precisa fornecer uma solução abrangente de desenvolvimento de aplicativos de desktop.
• O WinUI / Fluent precisa atender aos requisitos do usuário de negócios, como função / formulário, UX para desktop, exemplos de código / modelos de projeto que demonstram várias janelas, multithreading verdadeiro, validação de dados, páginas “semelhantes a formulários”.
• A Microsoft precisa deixar claro que está oferecendo o WinUI para construir aplicativos LOB de negócios altamente produtivos e duradouros. Além disso, por que .Net 5 + WinUI NÃO será outro inferno DLL.
• Deixe claro que o WinUI é o substituto do Win32 / MFC e do WinForms.
• Empurre C # XS como um conjunto de habilidades para TI.
• Datagrid (gratuito)

Espero que você tenha achado isso útil.

@robloo Descanse com calma - sem necessidade de debate! 🙂 Eu me comprometi a corrigir esse lapso em meu comentário anterior e isso ainda é verdade. Acho que também cometi um erro antes ao continuar generalizando. Vamos falar sobre os bugs que você listou. Dois foram registrados um pouco antes do nosso feriado principal aqui (não posso falar por @teaP , mas fiquei offline a maior parte de dezembro) e passamos por uma mudança de gerenciamento em nosso lado de engenharia (parabéns, @ranjeshj!). Não é desculpa e peço desculpas que esses dois bugs não tenham sido atendidos mais rapidamente durante essas mudanças e ausências. Os outros listados aqui foram todos protocolados nos últimos 10 dias ou menos.

Para tê-lo apontou que NumberBox em particular, é um culpado e que estes estão se acumulando nos ajuda a ser estratégica com o nosso tempo, então obrigado por nos ajudar a ver isso. Agendei um horário no início da próxima semana para revisar nossa lista de bugs pendentes da NumberBox com nosso NumberBox dev @teaP e nosso (recém-intitulado) gerente de engenharia @ranjesh para que possamos resolvê-los coletivamente o mais rápido possível.

@SavoySchuler Obrigado!

@SavoySchuler , parece que você está preso em uma posição difícil de escolher entre:

a) Corrigir bugs no WinUI 2.x e atrasar o lançamento do WinUI 3.0
ou
b) Deixe o WinUI 2.x para a comunidade e dedique recursos internos para o WinUI 3.0 para atingir a data de lançamento mais próxima

Eu acho que muitos usuários WinUI 2.x existentes vão querer que você corrija os bugs primeiro, já que eles estão afetados atualmente, mas talvez isso pudesse ser atenuado oferecendo uma expectativa realista de quando WinUI 3.0 _pode_ estar disponível, dados recursos suficientes ( e assumindo que o WinUI 3.0 oferecerá correções adicionais sobre 2.x).

Pessoalmente, não gostaria de ver um atraso no lançamento do WinUI 3.0 e acho razoável que a comunidade se envolva na solução de quaisquer problemas que sejam críticos no WinUI 2.x (afinal, é código aberto). Algumas pessoas têm a expectativa de que, por ser um projeto da Microsoft, elas devem fazer todo o trabalho. Infelizmente, isso não é realista, e também não é como funcionam outros projetos de código aberto.

@jesbis , é interessante ouvir sobre a Camada Visual em relação ao WinUI 3.0. Você está dizendo que para as versões iniciais, o WinUI 3.0 terá uma dependência de Windows.UI.Composition classes? Existe a possibilidade de adicionar mais recursos ao sistema operacional para oferecer suporte à Camada Visual antes da extração para o WinUI 3.0?

Para referência, coisas que estou interessante em:

• Modelo Win32 "AppContainer". Somos totalmente compatíveis com sandbox em outros sistemas operacionais, mas gostaríamos de acessar APIs "modernas"
• A camada visual ( Windows|Microsoft.UI.Composition )
• DXGI Trocar cadeias na camada visual / SwapChainPanel
• APIs de gerenciamento de janela (AppWindow etc)

@infoequipt, obrigado pelas notas detalhadas! Definitivamente útil. @ marb2000 para visibilidade

é interessante ouvir sobre a Camada Visual em relação ao WinUI 3.0. Você está dizendo que, para as versões iniciais, o WinUI 3.0 terá uma dependência das classes Windows.UI.Composition?

@MarkIngramUK não, desculpe qualquer confusão - meu ponto anterior era apenas sobre código aberto.

Microsoft.UI.Composition fará parte do WinUI 3 e Microsoft.UI.Xaml dependerá dele. Esse já é o caso com o WinUI 3 Alpha.

Estamos trabalhando para abrir o código-fonte do Xaml, o que significa que o código do framework Xaml estará neste repositório e nossa equipe de engenharia estará fazendo todo o nosso trabalho diário no Xaml no GitHub daqui para frente. No entanto, o pacote Microsoft.UI.Composition do qual o Xaml depende ainda será desenvolvido internamente e atualizado apenas na forma binária.

Obrigado pelo esclarecimento @jesbis muito apreciado. Que métodos de distribuição você usará para isso? Somos um aplicativo de plataforma cruzada, portanto, usando CMake e temos uma dependência de Windows.UI.Composition, então adoraríamos uma maneira de trazer facilmente a nova dll, lib, cabeçalhos, etc.

Há alguma implicação de desempenho na extração da Camada Visual do sistema operacional? Ou seja, se você depender apenas da Camada Visual, haveria uma desvantagem em atualizar para uma nova biblioteca?

Existe um plano para abrir o código-fonte Microsoft.UI.Composition?

@MarkIngramUK Eu concordo amplamente com o que você está dizendo e com o que @SavoySchuler está dizendo em uma visão 'ampla'. Porém, como você apontou, é mais difícil para nós, usuários do WinUI 2.0, aceitar bugs, pois temos aplicativos de produção no momento. Precisamos encontrar um meio-termo entre consertar alguns bugs que não atrasarão o WinUI 3.0 e também manter o WinUI 3.0 nos trilhos. Houve uma frustração adicional de que o NumberBox era um controle totalmente novo que parecia ter sido imediatamente negligenciado - com um comentário de que a Microsoft não voltaria atrás por mais de um ano. Apesar de tudo, certamente concordo que o WinUI 3.0 é a prioridade e não gostaria que fosse atrasado em nenhuma capacidade significativa.

Eu provavelmente deveria dizer que aprecio todo o trabalho que a Microsoft está fazendo aqui e seus esforços para ser mais transparente e comunicativa com a direção.

Que métodos de distribuição você usará para isso? Somos um aplicativo de plataforma cruzada, portanto, usando CMake e temos uma dependência de Windows.UI.Composition, então adoraríamos uma maneira de trazer facilmente a nova dll, lib, cabeçalhos, etc.

@MarkIngramUK consumir pacotes NuGet funcionaria para você? Ou seja, o que estamos fazendo com o

Há alguma implicação de desempenho na extração da Camada Visual do sistema operacional? Ou seja, se você depender apenas da Camada Visual, haveria uma desvantagem em atualizar para uma nova biblioteca?

Fique ligado 🙂 O benchmarking e o trabalho de desempenho estão em nosso roteiro para o final deste ano, então é um pouco cedo para termos quaisquer números.

Existe um plano para abrir o código-fonte Microsoft.UI.Composition?

Está em nossa lista de pendências considerarmos, mas não temos um plano para isso.

@MarkIngramUK se eu pudesse perguntar: qual benefício você espera obter sendo o código-fonte aberto?

O código de composição e renderização pode ficar um pouco confuso, então estou curioso para saber se as pessoas realmente estariam interessadas em contribuir ou usar como referência.

é mais difícil para nós, usuários do WinUI 2.0, aceitar bugs, pois temos aplicativos de produção no momento. Precisamos encontrar um meio-termo entre consertar alguns bugs que não atrasarão o WinUI 3.0 e também manter o WinUI 3.0 nos trilhos. Houve uma frustração adicional de que o NumberBox era um controle totalmente novo que parecia ter sido imediatamente negligenciado - com um comentário de que a Microsoft não voltaria atrás por mais de um ano. Apesar de tudo, certamente concordo que o WinUI 3.0 é a prioridade e não gostaria que fosse atrasado em nenhuma capacidade significativa.
Eu provavelmente deveria dizer que aprecio todo o trabalho que a Microsoft está fazendo aqui e seus esforços para ser mais transparente e comunicativa com a direção.

@robloo obrigado! Estamos realmente tentando ser transparentes e é bom saber que isso é valioso 🙂

Apenas para reiterar o que Savoy mencionou, temos desenvolvedores trabalhando no WinUI 2.x (como pode ser visto no log de RP também), então definitivamente ainda estamos investindo no WinUI 2 e 3 em paralelo - é apenas que a maioria dos nossos os recursos estão no WinUI 3. Eu concordo que a NumberBox em particular precisa de alguma atenção e nosso líder de desenvolvimento de controles Xaml está examinando isso agora.

@robloo Você é o melhor! 😄 Desculpe novamente pela confusão - a única coisa sujeita a esse atraso de ~ 1 ano mencionado foram os modos de validação de entrada adicionais do NumberBox porque eles estão bloqueados em nosso trabalho completo de validação de entrada programado para 3.0. Caso contrário, @teaP , @ranjeshj e eu estaremos na lista de bugs da NumberBox a partir da próxima semana. 🙂

Acho que @jesbis cuida de todo o resto!

@jesbis ,

@MarkIngramUK consumir pacotes NuGet funcionaria para você? Ou seja, o que estamos fazendo com o

Serei honesto, não estou familiarizado com o NuGet, mas olhando para esta resposta do SO , parece que só funcionará se você usar o CMake para gerar arquivos de projeto VS, que não é como normalmente trabalhamos (normalmente apenas abra a pasta , que usa o Ninja como gerador). É uma pena que você não possa enviar o código-fonte, já que também pode usar o vcpkg . Para referência, construímos todas as bibliotecas a partir do código-fonte (o que evita quaisquer problemas de ABI em potencial, especialmente considerando que também construímos com Clang / LLVM no Windows).

Existe um plano para abrir o código-fonte Microsoft.UI.Composition?

Está em nossa lista de pendências considerarmos, mas não temos um plano para isso.

Tenho interesse nisso, então adoraria me envolver na discussão se / quando isso acontecer.

@MarkIngramUK se eu pudesse perguntar: qual benefício você espera obter sendo o código-fonte aberto?

O código de composição e renderização pode ficar um pouco confuso, então estou curioso para saber se as pessoas realmente estariam interessadas em contribuir ou usar como referência.

Os pensamentos iniciais são contribuir / expandir (como mencionei anteriormente, temos uma dependência do Windows.UI.Composition, mas não do Xaml Framework / UWP), embora pensando em voz alta, portando a camada visual para um back-end Vulkan ou Metal para cross- plataforma pode ser empolgante, mas eu só dei literalmente 30 segundos de consideração. Além disso, o código aberto aliviaria a preocupação persistente de adotar outra estrutura que eventualmente será abandonada pela Microsoft em alguns anos (nossos aplicativos atuais são construídos em WPF, nossos aplicativos anteriores foram construídos em MFC, tínhamos componentes da web usando Silverlight, então , você pode ver de onde estou vindo aqui ...).

NumberBox

Olá a todos! @teaP , @ranjeshj e eu trabalhamos em todos os nossos itens NumberBox abertos hoje.

• Já fechamos alguns.
• @teaP enviou um PR combinado para vários outros ( filtragem de rótulo aqui ).
• Temos um curso de ação decidido para o resto (com exceção do # 1721) e responderemos com as correções o mais rápido possível. # 1721 requer mais trabalho para diagnosticar o melhor caminho a seguir. Continuaremos trabalhando para resolver este.

Obrigado a todos por trabalharem conosco. 🙂 Nós ❤️ WinUI!

Existe um "calendário" para as chamadas da Comunidade WinUI? Ex: na forma de um calendário público que podemos adicionar / integrar ao nosso calendário live / google / *, para atualizações automáticas dos detalhes das chamadas.

Os eventos do YouTube são programados com antecedência para que você possa adicionar um lembrete do Google aqui em "próximas transmissões ao vivo":

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

Também tínhamos um convite do calendário .ics, mas ele estava causando problemas para algumas pessoas e não havia como atualizá-lo, então desistimos dele por enquanto.