Microsoft está em processo de tornar o WinUI, framework de interface do usuário do Windows 11, em código aberto
(neowin.net)- A Microsoft anunciou um plano em etapas para tornar o WinUI, o framework de interface do usuário do Windows 11, de código aberto
- O WinUI não pode ser aberto imediatamente por causa de sua estrutura complexa e da quantidade de código proprietário, exigindo a separação do que pode e do que não pode ser compartilhado
- A abertura terá quatro etapas:
- 1ª etapa: aumento da frequência de espelhamento: após a liberação do WASDK 1.8 (fim de agosto), os commits internos serão sincronizados com maior frequência com o GitHub para compartilhar transparência e progresso de desenvolvimento
- 2ª etapa: build local por desenvolvedores externos: será possível para desenvolvedores externos clonar o código e construir localmente, com fornecimento também da documentação de configuração e dependências
- 3ª etapa: contribuição e teste externos: contribuidores da comunidade poderão enviar Pull Requests e executar testes locais, e também é previsto limpar dependências internas e disponibilizar a infraestrutura de testes
- 4ª etapa: transição para um sistema de desenvolvimento centrado no GitHub: finalmente, o GitHub se tornará o foco principal de desenvolvimento, gestão de issues e comunicação da comunidade, enquanto o sistema interno de mirror será desativado gradualmente
- O roteiro de open source do WinUI é mantido publicamente no quadro de projetos do GitHub
- Desenvolvedores e usuários podem contribuir para o avanço do WinUI com feedback, criação de issues claras e votação em sugestões existentes
3 comentários
Também não gosto nem do COM nem de Webview... queria uma GUI que fosse realmente utilizável.
Até agora, entre as interfaces para Windows que já testei, a que mais gostei foi a Qt4. A partir do Qt5, a sensação mudou bastante.
Na verdade, se não me engano, o MFC também não era tão ruim... kkk
Opinião no Hacker News
Preocupado com o futuro da tecnologia de UI nativa do Windows. Desenvolvedores de sistema operacional normalmente criaram apps nativos consistentes e funcionais nos produtos que usam. Mas no Windows 11 aconteceu exatamente o contrário. No Windows 10 havia, no mínimo, um app de email e calendário padrão que funcionava; na atualização mais recente do Windows 11, esse app desapareceu e foi substituído por um wrapper WebView lento, levando vários segundos para abrir.
Ao olhar para as community calls do WinUI, parece que a maioria dos novos contratados não tem nenhuma experiência com Windows, e a liderança também não se importa com isso, então ninguém aprende o básico. Até em perguntas que qualquer desenvolvedor Windows deveria saber responder, eles também não conseguem responder e parecem não entender por que a pergunta foi feita. Esses fatores fazem com que instâncias do WebView2 apareçam por toda parte no Windows 11.
O problema de UI do Windows 11 é que há uma obsessão excessiva por apps e recursos novos, enquanto as ferramentas antigas não são atualizadas. Por exemplo, o Painel de Controle está praticamente com o mesmo visual desde o Windows 7. Quando você vai mais fundo, encontra ferramentas antigas escondidas em todos os cantos, como aquele meme do clipe no cabelo do Homer Simpson. A interface pode parecer nova na superfície, mas suas limitações aparecem rápido no uso.
Em algum ponto, talvez o MSO (Office) seja completamente refeito com tecnologias como Dart e WASM. Em uma forma completamente independente do toolkit nativo, é possível reproduzir todas as funcionalidades do Excel e disponibilizar como um plano premium da O365 para acesso em qualquer lugar. No fim, o Windows talvez acabe virando algo parecido com o ChromeOS, onde só precisa de uma UI nativa simples em áreas como tela de bloqueio/login, enquanto o restante é tratado de forma mais leve.
Se você entende a luta por poder e a política interna implacável na Microsoft, consegue enxergar por que isso acontece. Os departamentos estão em competição para obter vantagem entre si.
O Windows tem a sensação de misturar no mínimo 10 frameworks de UI diferentes. O Windows 11 parece uma visita a um museu de história natural. Há apps com design preso à era do Windows 2000, como o MSC, e também UIs robustas e primárias com influência do Metro. O estilo moderno do Win11 pode parecer convincente, mas na prática é quase “botar batom em porco”. O menu de contexto de clique direito é um exemplo clássico: parece bonito, mas falta funcionalidade e você precisa clicar em “Ver mais” para ver mais opções no estilo antigo. Tudo fica uma bagunça.
Das declarações da Microsoft do tipo “alinhamento com as metas da Microsoft” e “alocação cautelosa de recursos”, não consigo perceber sinceridade. No fim, parece uma política de terceirizar o framework e retirar recursos, esperando que desenvolvedores externos, cheios de entusiasmo, cuidem da manutenção.
A expressão “vencidos por paixão” é muito negativa. Mesmo se eu concordar com a leitura cínica de que não me interesso pela UI do Win11 ou de que esta abertura de código é só para reduzir custos, ainda assim quero render algum respeito a quem está tentando manter esse trabalho.
Sejamos francos: isso soa como linguagem corporativa de “sem garantia de suporte, sem planos de atualização além de bugs de segurança, use por sua conta e risco”.
Fica a vontade de brincar “quando vai sair o Apache Windows”. Falando sério, toolkit de UI de desktop não é mais uma vantagem competitiva ou barreira de entrada. Isso acontece porque só no Windows já existem oficialmente 3 a 4 estilos diferentes. Mas segurança e estabilidade ainda são cruciais para o Windows sobreviver no mundo corporativo, financeiro e de governo.
Entendo por que abrir o framework de UI de outra empresa pode fazer sentido. Por exemplo, Atlassian ou AWS, já que são usados no Jira/AWS e valem para B2B SaaS. Mas para este framework específico, não entendo por que alguém deveria usá-lo. Se não for para fazer app nativo só para Windows, já acho que há escolhas melhores.
Eu acho que WinUI falhou.
Na comunidade de desenvolvimento Windows, quase não há pessoas de fato interessadas em WinUI, e só ficam presos os que já investiram em WinRT/UWP e não conseguem sair. Desde o Windows 8, houve muitas pontes quebradas e a confiança da comunidade se perdeu. Na prática, parece que a Microsoft está delegando os problemas para a comunidade, em vez de resolvê-los.
Se empresas como DevExpress e Progress Telerik também não investem em controles WinUI próprios, isso sinaliza que elas também não acreditam no futuro do WinUI. No momento, para apps empresariais, apenas WinForms e WPF parecem alternativas reais. Na prática, nunca vi um app em operação criado com WinUI3.
Sinceramente, quem vai usar qualquer framework UI da Microsoft de forma séria agora? Mesmo os frameworks que já eram usados antes nunca são concluídos, ficam meio abandonados e, antes de amadurecerem, a galera migra para algo novo e brilhante e tudo é esquecido. Um framework open source cross-platform, por outro lado, tende a ser bem mais completo em fundamentos e funcionalidades, com manutenção melhor feita. Este WinUI provavelmente será apenas mais um UWP esquecido e ignorado.
O Windows já é complicado demais para contar quantos frameworks de UI há. Fica a dúvida sobre o que exatamente se espera com a abertura de código. Será só uma vitrine de “estar aberto” ou há ganho real para desenvolvedores que miram Windows?
WinUI é uma evolução do UWP, e o UWP em si é uma evolução do WinRT. A intenção do WinUI é clara, e é uma tecnologia que evoluiu ao longo do tempo (atualmente na versão WinUI 3). MAUI é menos um concorrente e mais uma opção cross-platform. Ainda assim, sem reestruturar todo o OS — especialmente as ferramentas de gerenciamento — com WinUI, é difícil construir confiança de longo prazo.
Quando vi tantas siglas e explicações acima, inicialmente pensei que fosse sátira. WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt etc. Tantas versões e nomes de frameworks misturados deixam a explicação longa e confusa.
Talvez a Microsoft, como sempre, esteja focada na nova tendência (agora IA!), encontrando ao mesmo tempo uma forma de “aposentar” tecnologias antigas sem muita resistência. Na prática, parece que as pessoas que vão se opor são minoria.
No fim, o Windows tem três frameworks de UI, e apenas dois estão realmente vivos. O restante é basicamente repetição evolutiva das duas linhas Win32/Native e WPF/Managed. WinUI3 surgiu justamente para cobrir essa lacuna.
A longo prazo, o MFC ainda parece a opção mais duradoura. Hoje não há atualizações, mas ele provavelmente vai durar mais 20 anos tranquilamente.
Preferia que a Microsoft tivesse continuado evoluindo o WPF. Já usei em muitos projetos durante bastante tempo; apesar da curva de aprendizado, Data Binding, ViewModel e XAML continuam indo bem. Só que o WPF precisa de alguns ajustes para ficar mais completo. Testei novos frameworks da Microsoft e open source recentes (como Avalonia, Uno etc.), mas, ou as amostras não rodavam, ou a forma de desenvolvimento não se encaixava. No fim, acabo voltando para o WPF conhecido. A ideia principal de melhoria do WPF é tornar o sistema de Data Binding geração de código em tempo de compilação .NET em vez de Reflection em runtime. Com isso dá para fazer build AOT de verdade, a performance melhora bastante, e vêm vantagens como tipagem de XAML e suporte cross-platform. Quis fazer isso em open source, mas não tive tempo e há trabalho demais.
O segundo parágrafo que citei acima se encaixa perfeitamente no Avalonia. Avalonia já suporta AOT, erros de binding em tempo de compilação e recursos cross-platform. Se você não tem visto atualizações recentes, vale conferir Avalonia compile-time data binding docs e projeto XamlX.
Com essa abordagem também é possível fazer assembly trimming. Para deployment independente, hoje as bibliotecas .NET adicionam mais de 200 MB, mas assim dá para reduzir bem mais.
Quando avaliei o WinUI3 antes, a experiência de dev era muito ruim. Para depurar o app que quero distribuir, era preciso instalá-lo no sistema. Isso acabava deixando muitas entradas inúteis no menu Iniciar e bagunçando o registro. Em um exemplo de código, ao clicar no botão, o app simplesmente travava imediatamente. Para desenvolvimento de apps Windows, ainda faço em Win32+WTL.
Como muita gente comentou, frameworks de UI para Windows ficaram desorganizados por anos, aumentando a confusão. Infelizmente, no open source cross-platform ocorre a mesma história. O GTK também ficou uma bagunça por um tempo, e o Qt, embora tenha muitos recursos, tem modelo de licença inviável para uso profissional. (Na fase da Nokia havia esperança, depois o Qt mudou de proprietário e desapareceu). Em alguns cenários, soluções como Dear Imgui são boas, mas no geral, entre frameworks UI/widget nativos e cross-platform com licença permissiva, compilação nativa, boa composição de widgets e suporte a renderização 3D Vulkan, quase não existe alternativa.
Queria que o Windows 11 trouxesse de volta a barra de tarefas vertical nativa. Esse recurso existia desde o Windows 98, mas foi removido no 11. Existem ferramentas de terceiros como Windhawk (forçar taskbar horizontal) ou StartAllBack (restauração de código do Windows 10), mas nenhuma é perfeita.
Abrir o framework de UI não fará com que os recursos da barra de tarefas cresçam. Contribuições externas nessa área só são possíveis se for a própria taskbar — isto é, o explorer.exe — a ser aberta.
Só por referência, no início, a barra vertical já estava disponível como opção desde o Windows 95.
A funcionalidade da barra de tarefas pertence ao explorer.exe. O anúncio de open source em discussão agora não tem relação com o explorer.
Fica a dúvida se o time do Windows está mesmo fazendo uma UI desktop nativa de verdade com WinUI.
O desenvolvimento de UI para Windows hoje está sendo feito com Win32, GDI e DirectDraw. Com CsWin32 e C# moderno (ref returns), ficou muito mais fácil acessar. Antes costumava ser necessário montar projeto separado em C++, mas agora basta escrever no NativeMethods.txt as funções necessárias e o codegen faz o resto. Win32 é definitivamente mais low-level que outros frameworks de UI, mas também é difícil para a Microsoft mexer ou descartar. Em perspectiva de longo prazo, não há API que tenha sobrevivido tão bem. A plataforma web nem entra nesse comparativo.
Mesmo assim, ainda é preciso C++ em muitos pontos. É por conta da teimosia da equipe do Windows com COM. Os Windows Runtime Components foram uma oportunidade de elevar o nível do ecossistema .NET, mas foi desperdiçada. Extensões de shell, extensões de menu de contexto e semelhantes precisam ser feitas em C++, e para fazer isso em .NET acaba tendo de ficar uma chamada a processo .NET via stub em C++.
Para mim, discutir API de baixo nível é mais interessante do que discutir frameworks de alto nível. Entendo que a pilha completa de renderização do Windows é construída sobre GDI/DirectX, e o Win32 em si está no topo do GDI. Se formos discutir a pilha de UI do Windows mais próxima do metal, começa a fazer mais sentido partir do DirectX.
Do ponto de vista do usuário, Win32 já é suficientemente high-level. Até hoje, a única toolkit que desenha corretamente botões, barras de rolagem etc. é o Win32.
Gostaria que a comunidade criasse um bom framework para desenvolvimento nativo de Windows, mas a verdade é que a comunidade com esse tamanho não existe.
O que mais senti falta no desenvolvimento de UI antiga do Windows foi a capacidade de fazer apps que se encaixassem naturalmente como se tivessem sido feitos pela própria Microsoft. Desde a entrada de tecnologias web, a consistência da experiência UI do Windows se rompeu bastante. O problema não é só não modernizar apps antigos, é que os novos ferramentas também não fornecem uma biblioteca alinhada ao guia de estilo. Isso já aparecia desde o Vista, e no MSDN o material de exemplo rico do tipo “use este recurso dessa forma” foi diminuindo aos poucos.