Investigar egui para tools internas e prototipacao rapida

[solrachix]

Contexto

Estamos avaliando se vale implementar ou adotar egui no OrbitShell, principalmente para casos bem praticos: tools, apps internas, utilitarios e prototipacao rapida.

Referencia: https://github.com/emilk/egui

O ponto a favor do egui e que ele se propõe a ser facil de usar e multiplataforma. Ele tambem abstrai o conceito de tecla Command, fazendo Cmd no macOS e Ctrl no Windows/Linux funcionarem de forma uniforme para atalhos como select all. Isso pode reduzir friccao em input de texto, atalhos, clipboard e ferramentas auxiliares.

Ao mesmo tempo, o projeto hoje usa GPUI, que combina melhor com uma experiencia desktop custom inspirada no Zed. A decisao nao deveria ser puramente estetica: precisamos validar produtividade, qualidade dos inputs e custo de manutencao.

Proposta

Investigar egui como alternativa ou complemento ao GPUI para partes do OrbitShell, especialmente telas de utilitarios, paineis internos e prototipos rapidos.

A investigacao deve responder:

• egui melhora a velocidade de desenvolvimento para tools internas?
• O input de texto, selecao, clipboard e atalhos funcionam melhor ou com menos codigo proprio?
• Conseguimos chegar em um visual aceitavel para um app desktop inspirado no Zed?
• Ele se integra bem com o fluxo atual do OrbitShell, incluindo terminal, agent, async/background tasks e estado de UI?
• Vale usar egui no geral, ou manter GPUI como stack principal e talvez usar egui apenas para prototipos/tools separadas?

Spike sugerido

Criar uma PoC pequena em egui com a mesma tela/fluxo minimo que mais nos incomoda hoje:

• input estilo terminal/agent
• atalhos basicos (Cmd/Ctrl+A, copiar, colar, enviar)
• clipboard
• sidebar/lista simples
• modal ou popup
• tema escuro inspirado no Zed
• comportamento em Linux e Windows, quando possivel

Comparar a PoC com a implementacao atual em GPUI nos seguintes criterios:

• quantidade de codigo
• complexidade para input/selection/clipboard
• suporte a atalhos cross-platform
• capacidade de customizacao visual
• facilidade para componentes internos e ferramentas rapidas
• risco de manutencao
• impacto se a gente migrar algo existente

Resultado esperado

Ao final da investigacao, registrar uma recomendacao objetiva:

• manter GPUI como stack principal
• adotar egui para partes especificas
• criar tools/prototipos em egui separadamente
• ou considerar migracao parcial/total, se o ganho for claro

Links

• egui: https://github.com/emilk/egui
• GPUI/Zed: https://github.com/zed-industries/zed/tree/main/crates/gpui

[solrachix]

Fiz uma primeira passada de investigação.

Recomendação objetiva por enquanto: manter GPUI como stack principal do OrbitShell e testar egui apenas como PoC/tool separada, não como integração dentro da UI principal agora.

Evidências locais:

• O shell principal está bem acoplado ao GPUI em src/ui/views/tab_view.rs: terminal, Agent mode, preview focus, overlays, clipboard, PTY, async/background updates e estado de UI.
• O ponto onde egui pode reduzir fricção é input simples: hoje temos src/ui/text_edit.rs e bastante KeyDownEvent manual em sidebar_view.rs, settings_view.rs, tab_view.rs e agent_view.rs.
• O input principal do terminal não é só um TextEdit: tem completion, histórico, controle de PTY, Agent mode, pickers e seleção de preview. Migrar isso sem PoC seria arriscado.
• File preview já está alinhado com a estratégia de renderização lazy: o conteúdo textual é dividido uma vez em Arc<Vec<String>> e renderizado via uniform_list. A performance das listas principais continua sendo uma pauta GPUI separada, não um argumento direto para egui.

Evidências externas:

• egui é a lib de UI immediate-mode; eframe é o framework que fornece backend nativo/web, input e rendering.
• egui::TextEdit cobre workflows de input simples, seleção, single-line/multiline/code editor, return key, layouter e estilo.
• egui::Context::copy_text cobre escrita no clipboard.
• O modelo de background work recomendado por egui via channel/promise/shared state combina com tools pequenas e separadas, mas não resolve sozinho a integração com o event loop/rendering do GPUI.

Próximo passo recomendado:

• Criar uma PoC standalone, por exemplo tools/egui_spike/, com eframe/egui como dependência apenas desse tool.
• Não adicionar egui ao binário principal ainda.
• Validar: input terminal/agent-style, Cmd/Ctrl+A, copiar, colar, enviar, clipboard, sidebar/lista simples, modal/popup, dark theme inspirado no Zed e updates de background via channel/shared state.
• Testar Linux primeiro e Windows quando possível.

Critério de decisão depois da PoC:

• manter egui só para prototipação,
• manter como workspace de tools internas separadas,
• usar em utilitários standalone específicos,
• ou rejeitar se visual/input/manutenção não compensarem.

Também deixei uma nota local de spike em docs/superpowers/specs/2026-04-14-egui-spike-investigation.md para entrar no repo junto com o próximo commit/PR.

[solrachix]

Implementei a PoC standalone proposta para o spike.

Arquivos adicionados localmente:

• tools/egui_spike/Cargo.toml
• tools/egui_spike/Cargo.lock
• tools/egui_spike/src/app.rs
• tools/egui_spike/src/main.rs
• tools/egui_spike/README.md
• tools/egui_spike/.gitignore
• docs/superpowers/plans/2026-04-14-egui-spike-poc.md
• docs/superpowers/specs/2026-04-14-egui-spike-investigation.md

O tool fica isolado do binário principal GPUI: não alterei Cargo.toml da raiz nem arquivos em src/.

O que a PoC valida:

• UI nativa em eframe = 0.34.1.
• input terminal/agent-style com egui::TextEdit.
• submit por Enter/botão Send.
• clipboard via egui::Context::copy_text no botão Copy transcript.
• sidebar/lista simples.
• modal/popup.
• dark theme inspirado no Zed.
• updates de background via std::sync::mpsc sem bloquear a UI.
• testes unitários para estado de prompt e drenagem de mensagens de background.

Validação local executada:

• cargo test --manifest-path tools/egui_spike/Cargo.toml -> 2 passed, 0 failed.
• cargo check --manifest-path tools/egui_spike/Cargo.toml -> exit 0.
• cargo fmt --manifest-path tools/egui_spike/Cargo.toml --check -> exit 0.

Como rodar manualmente:

• cargo run --manifest-path tools/egui_spike/Cargo.toml

Não fechei a issue ainda porque o próximo gate ainda é validação manual/visual em Linux e, quando possível, Windows.

[solrachix]

Após validação visual da PoC, vou seguir a recomendação conservadora:

• Manter GPUI como stack principal do OrbitShell.
• Não perseguir paridade visual de 100% em egui.
• Não migrar terminal, sidebar, settings ou shell principal para egui.
• Manter egui apenas como caminho opcional para tools internas/protótipos standalone, onde o visual não precisa ser idêntico ao OrbitShell.

Motivo: a PoC confirmou que egui ajuda em ergonomia de input/widgets básicos, mas visualmente não encaixa naturalmente no shell GPUI/Zed-like. Para chegar perto de 100% parecido, provavelmente precisaríamos de custom painting/widgets suficientes para perder a vantagem de produtividade que motivou o spike.

Também atualizei localmente:

• docs/superpowers/specs/2026-04-14-egui-spike-investigation.md com a decisão final da PoC.
• tools/egui_spike/README.md deixando explícito que isso não é caminho de migração.

Verificação reexecutada depois da atualização documental:

• cargo test --manifest-path tools/egui_spike/Cargo.toml -> 2 passed, 0 failed.
• cargo check --manifest-path tools/egui_spike/Cargo.toml -> exit 0.
• cargo fmt --manifest-path tools/egui_spike/Cargo.toml --check -> exit 0.

[solrachix]

Segui com a recomendação para o input: em vez de copiar terminal/input do Zed, extraí uma fundação própria em GPUI.

O que foi implementado localmente:

• Novo módulo src/ui/input/ com:
  • keymap.rs: usa gpui::Modifiers::secondary() como modificador primário (Cmd no macOS, Ctrl no Linux/Windows).
  • state.rs: estado puro de prompt (PromptInputState) com texto, cursor, seleção, insert/delete, backspace e word movement.
  • testes em mod.rs cobrindo primary modifier, bloqueio de input com modificadores, substituição de seleção, backspace e word movement de caminho.
• TabView passou a usar InputKeymap e PromptInputState no prompt principal.
• Cmd+A/Cmd+V no macOS e Ctrl+A/Ctrl+V no Linux/Windows agora usam a mesma semântica primária.
• Preview e overlays do TabView também usam primary modifier para copiar/selecionar/paste onde aplicável.
• Mantive Ctrl+C de Agent cancel e Ctrl+<letter> de terminal PTY preservados.

Consultei o exemplo oficial no repo do Zed/GPUI (crates/gpui/examples/input.rs) como referência de arquitetura, mas não copiei o componente: o exemplo usa EntityInputHandler e um elemento custom completo, que é maior do que precisamos nesta etapa.

Verificação local:

• cargo test ui::input --lib -> 5 passed, 0 failed.
• cargo test tab_view --lib -> 50 passed, 0 failed.
• cargo check -> exit 0.
• cargo fmt --check -> exit 0.

[solrachix]

Implemented the next terminal-input follow-up in the local workspace:

• Added a separate terminal interactive prompt path for mid-command PTY prompts.
• Secret prompts such as [sudo] password ...: and SSH passphrase prompts are detected and shown with masked input.
• Plain confirmations such as [y/N] / (y/n) are detected and use the same raw PTY input path.
• Enter sends the typed value directly to the PTY with CRLF; it does not go through normal command submission or command history.
• Ctrl+C / Escape cancels by sending ETX to the PTY.
• Agent approval remains on the existing structured ACP permission-card path in TabView.

Verification run locally:

cargo test ui::input --lib
cargo test tab_view --lib
cargo check
cargo fmt --check

Results: ui::input 9/9 passed, tab_view 52/52 passed, cargo check exit 0, cargo fmt --check exit 0.