Software & automação · estudo de caso
FlowKey
Atalhos, textos automáticos e macros num painel só, para quem quer ganhar tempo no Windows sem aprender a programar.
Visão geral
O projeto em poucas palavras
O FlowKey é um aplicativo que fica na bandeja do Windows e reúne quatro recursos de produtividade que costumam vir de ferramentas separadas: atalhos de teclado, textos automáticos, um seletor visual de arquivos e pastas e a gravação de macros. A promessa é ganhar tempo sem escrever scripts nem digitar caminhos de arquivo.
O produto está em desenvolvimento. O nome é provisório.
Desafio
O ponto de partida
Ferramentas como AutoHotkey, Espanso e PowerToys cobrem partes do problema, mas costumam exigir que a pessoa digite caminhos, aprenda uma sintaxe ou combine vários programas. O público que eu tinha em mente é quem trabalha em escritório, já usa atalhos do sistema e nunca escreveu um script: quer economizar tempo, não aprender a programar.
Solução
Quatro recursos, um painel
| Recurso | O que faz |
|---|---|
| Atalhos | Uma combinação de teclas abre um aplicativo, arquivo, pasta ou endereço, alterna janelas ou dispara uma macro. A combinação é capturada pressionando as teclas, sem digitar nomes. |
| Textos automáticos | Digitar um gatilho, como uma barra seguida de uma palavra, expande o texto completo em qualquer campo, com variáveis como data, hora e conteúdo da área de transferência. |
| Seletor visual | Um clique direito no Explorer, em “Selecionar para o FlowKey”, escolhe o alvo sem digitar o caminho. |
| Macros | Grava teclas, cliques e tempos e reproduz a sequência, com velocidade e repetição configuráveis. A tecla Esc aborta a qualquer momento. |
Há ainda detecção de conflito com atalhos do Windows, perfis por aplicativo em foco, pausa geral pela bandeja, início junto com o Windows, tema claro e escuro e exportação e importação das configurações.
Processo
Especificação antes do código
Comecei por um documento de especificação com objetivo, personas e o princípio de que, no fluxo básico, ninguém deve precisar digitar um caminho, um código de tecla ou um comando. O documento também compara alternativas de tecnologia — C# com WPF, Rust com Tauri, Electron e C++ nativo — e justifica a escolha por C# e .NET 8: acesso maduro às APIs do Windows, boa produtividade de interface e menor consumo de memória que um app em Electron, importante para algo que fica aberto o dia todo.
A solução separa o Core, sem nenhuma dependência de interface, do aplicativo WPF e de uma ferramenta de linha de comando que registra o item do menu do Explorer. Dentro do Core, cada motor (atalhos, textos, macros, ações, janelas) fica isolado, e a comunicação entre o clique no Explorer e o aplicativo principal acontece por um Named Pipe, com instância única garantida.
Resultados
Estado atual
O código tem cerca de 4,4 mil linhas de C# e 15 testes automatizados sobre repositórios de dados, detecção de conflitos e lógica de textos automáticos. Metas de desempenho estão definidas no projeto — menos de 5 ms por evento de teclado e menos de 80 MB de memória em repouso —, mas ainda não foram medidas em uso real.
As limitações conhecidas estão documentadas: aplicativos executados como administrador podem ignorar a automação, alguns jogos filtram entrada simulada, macros com coordenadas absolutas dependem da resolução, e builds sem assinatura de código podem acionar alertas do antivírus.
Aprendizados
O que guiou as decisões
Programas que observam o teclado inteiro pedem confiança. Por isso, os dados ficam só na máquina, os logs registram eventos técnicos e nunca o conteúdo digitado, e há uma tecla de emergência para interromper qualquer automação. Assinar o código antes de distribuir também faz parte do caminho: sem isso, um app legítimo se parece demais com o que ele quer evitar ser.