Estudo de caso · Código aberto

Wintaskbar

Utilitário para Windows 11 que transforma a barra de tarefas em uma dock flutuante, com blur e cantos arredondados, e uma bandeja separada. Um pequeno aplicativo de bandeja em Go valida e compila o tema; um componente mínimo em C++/WinRT, carregado no Explorer, o aplica. Publicado sob licença MIT.

Papel
Autor único
Stack
Go · C++/WinRT · Win32
Licença
MIT
Código
Público no GitHub
O tema padrão em execução em uma área de trabalho do Windows 11.

Visão geral

O Windows 11 não oferece um caminho suportado para mudar a aparência da barra de tarefas: sem cantos arredondados, sem blur, sem dock flutuante. O Wintaskbar preenche essa lacuna. Ele lê um tema YAML simples — seletores, estilos e variáveis — e o aplica aos elementos reais da barra enquanto o Windows está em execução; o resultado é a própria barra do sistema, restilizada, e não uma substituta desenhada por cima. É um projeto pessoal de engenharia que trabalha, de propósito, sobre uma interface não documentada, e é publicado como código aberto para que a técnica e os seus riscos possam ser inspecionados, e não apenas afirmados.

Minha contribuição

Sou o único autor do repositório. Projetei a divisão entre o Agent em Go e o componente dentro do Explorer, escrevi o modelo, o validador e o compilador de temas, o aplicativo de bandeja com o menu próprio, o instalador, o componente C++/WinRT que aplica os estilos e as suítes de testes de cada parte. Também escrevi os scripts de build, o Makefile e a documentação do projeto, inclusive os registros de decisões de arquitetura.

O projeto existe para exercitar engenharia de sistemas: trabalhar entre uma linguagem gerenciada e código nativo, a superfície Win32 e COM, o ciclo de vida e a recuperação de processos, e manter um componente arriscado o menor e o mais fácil de raciocinar possível.

Arquitetura

Dois programas com um contrato estreito entre eles. O Agent é um único executável nativo em Go que vive na bandeja: valida o tema, compila-o em um arquivo simples e anexa o segundo programa ao Explorer. O TAP é uma DLL C++/WinRT que roda dentro do explorer.exe, lê esse arquivo compilado e aplica os estilos aos elementos XAML da barra de tarefas.

Como o Wintaskbar aplica um tema O usuário edita o theme.yaml. O Agent em Go o valida e grava o theme.compiled com seletores e valores resolvidos. O Agent encontra o Explorer pela janela Shell_TrayWnd e chama InitializeXamlDiagnosticsEx para carregar a DLL do TAP dentro do Explorer. O TAP lê o theme.compiled e aplica os estilos aos elementos XAML da barra de tarefas. O Agent também monitora o Explorer e reanexa o TAP quando ele reinicia. theme.yaml seletores, estilos, variáveis AGENT · GO Valida o tema antes de tocar no Explorer Compila o contrato theme.compiled, versionado Anexa o TAP InitializeXamlDiagnosticsEx Menu da bandeja + vigia reanexa se o Explorer reiniciar, inicialização, logs theme.compiled linhas simples, sem gramática EXPLORER.EXE TAP DLL C++/WinRT só lê e aplica XAML da barra dock, bandeja, quadro cantos arredondados, blur Tracejado: o Agent anexa o TAP ao Explorer em execução
Fluxo desenhado a partir da documentação do projeto e dos diretórios cmd/, internal/ e tap/.

Organização do código

  • cmd/wintaskbar compõe o aplicativo e os comandos de desenvolvimento.
  • cmd/setup é o instalador independente, com o Agent e o TAP embutidos.
  • internal/modules/theme contém o modelo, a validação, a leitura de YAML e a compilação.
  • internal/modules/agent contém a aplicação, a restauração e o monitoramento.
  • internal/platform/windows isola as APIs nativas, a bandeja, a inicialização e o shell.
  • tap é o componente C++/WinRT carregado no Explorer.

Stack

  • Agent: Go, um único executável nativo, sem runtime e sem serviço extra instalado.
  • Componente no Explorer: C++/WinRT compilado com clang/MinGW-w64.
  • Integração: API de diagnóstico XAML, bandeja Win32, inicialização por tarefa agendada.
  • Temas: YAML com seletores, variáveis e parâmetros de blur.
  • Distribuição: instalador por usuário e ZIP portátil, ambos gerados por um Makefile.

Decisões de engenharia

Três decisões que moldaram o projeto, cada uma com a alternativa considerada e o que ela custa. O repositório mantém dezesseis registros de decisão no total.

1. O Agent compila o tema; o TAP só o aplica

Decisão:
o Agent em Go lê, valida e decompõe o tema e grava um arquivo simples e versionado; o componente dentro do Explorer apenas lê esse arquivo e o aplica, sem interpretar a gramática dos seletores.
Alternativa:
fazer o componente dentro do Explorer interpretar o tema YAML e resolver seletores e variáveis por conta própria.
Motivo:
um erro dentro do Explorer custa reiniciar a barra e depurar é caro. A validação no Agent responde na hora, com todos os erros do tema, antes de tocar no Explorer, e o componente nativo continua pequeno.
Limitação:
os dois programas compartilham um contrato que precisa ser versionado e mantido em sincronia; o Agent e o TAP devem ser atualizados juntos.

2. Depender do auto-ocultar nativo em vez de mudar configurações do sistema

Decisão:
para a dock flutuar sobre as janelas maximizadas, o usuário liga a opção nativa do Windows “Ocultar automaticamente a barra de tarefas”. O menu da bandeja oferece um atalho para ela, mas o aplicativo nunca altera configurações do sistema por conta própria.
Alternativa:
forçar a opção na inicialização para que o layout sempre funcione.
Motivo:
sem o auto-ocultar, o Explorer reserva a faixa da barra e desfaz mudanças na área de trabalho. Deixar a escolha com o usuário evita que a ferramenta altere a máquina em silêncio, e sair do aplicativo nunca muda a opção.
Limitação:
sem o auto-ocultar, a dock continua dividindo a tela com a faixa reservada — algo documentado, mas um compromisso visível.

3. Tarefa agendada de logon em vez da chave Run para iniciar com o Windows

Decisão:
o início com o Windows é uma tarefa agendada de logon do usuário, sem elevação. A chave Run fica como recuo e, no primeiro minuto, o Agent verifica a barra com frequência e trata a sua ausência como “esperar”.
Alternativa:
a chave de registro Run, a forma habitual de iniciar um programa por usuário.
Motivo:
o Windows atrasa as entradas de Run de propósito, então a barra original ficava visível por vários segundos antes do tema aparecer.
Limitação:
é mais um artefato para criar e remover direito; o desinstalador precisa apagá-lo, e uma cópia portátil só deve ativar a inicialização depois de estar na pasta definitiva.

Qualidade, segurança e custo

Tudo o que está abaixo existe no repositório público e pode ser conferido no código. Os valores medidos vêm de uma única máquina de desenvolvimento e não são garantia para outro hardware.

Testes

  • 21 arquivos de teste em Go, cobrindo os casos de uso, o contrato COM e o ciclo da bandeja.
  • Testes de contrato em C++ leem o mesmo arquivo de referência contra o qual o compilador Go é conferido: seletores, atributos, escapes, parâmetros de blur, arquivos inválidos e o cálculo do layout adaptativo.
  • Um teste da bandeja exercita o menu próprio — teclado, clique, itens desabilitados, atualização de estado e recursos GDI após reaberturas — sem executar comandos reais.
  • Tudo roda com make check, que prepara os próprios binários e não instala o aplicativo, não aplica tema nem reinicia o Explorer.

Segurança

  • O tema — seletores, variáveis e valores — é validado antes de reiniciar o Explorer; os erros aparecem no menu com as linhas inválidas.
  • Desativar tema e Sair e restaurar a barra devolvem a barra original; o desinstalador faz o mesmo e preserva os temas e os logs do usuário.
  • O tema padrão é original do projeto, e os avisos de terceiros estão listados no repositório.
  • O README declara com clareza que a técnica usa uma API não documentada e que os binários não têm assinatura.

Consumo

  • Memória do Agent de cerca de 19 MB e CPU em repouso de cerca de 0,2% de um núcleo.
  • O wintaskbar.exe tem cerca de 3,1 MB e o tap.dll cerca de 1,6 MB.
  • O Agent não fica consultando janelas: só verifica o Explorer a cada dois segundos para reanexar o TAP caso ele reinicie, e o blur é desenhado pelo compositor do próprio Windows.
  • Os valores não incluem a memória que o TAP usa dentro do Explorer.

Resultados e limitações

O que existe hoje é um utilitário funcional: uma dock flutuante e uma bandeja separada, com blur, cantos arredondados e borda em gradiente; um tema YAML editável com layout adaptativo da dock, que mantém o botão de overflow acessível em telas estreitas; um menu de bandeja que acompanha o modo claro/escuro do sistema, com suporte completo a teclado; e tanto um instalador de um arquivo quanto uma versão portátil, que não exigem Go, compilador nem privilégios de administrador para usar.

Limitações declaradas

  • Depende de uma API não documentada do Windows. Uma atualização do Windows pode mudar a árvore XAML e fazer o tema deixar de ser aplicado, ou aplicar só em parte.
  • Só uma versão do Windows foi verificada. Foi testado no Windows 11 x64, build 26300; não afirmo que funcione em outras versões.
  • Aplicar, desativar e sair reiniciam o Explorer. A barra e a área de trabalho somem por instantes e janelas do Explorador de Arquivos abertas podem fechar.
  • Os binários não têm assinatura de código. O SmartScreen ou o antivírus podem avisar sobre um programa que carrega uma DLL no Explorer; compilar a partir do código é a alternativa.
  • O TAP ainda não libera todas as referências de elementos mantidas pela API de diagnóstico, o que precisa evoluir para sessões longas, e o blur não implementa saturação, luminosidade, ruído nem reação à economia de energia.
  • Não há dados de uso real. É um projeto pessoal; não afirmo ter usuários, downloads ou adoção.

Explorar

O repositório é público e inclui o README com os avisos, as instruções de instalação e de compilação, a referência de temas, a política de segurança e os registros de decisão de arquitetura em docs/.

Leia os avisos do README antes de executar o programa: ele reinicia o Explorer e usa uma API não documentada, então uma máquina virtual é a forma segura de experimentá-lo primeiro.