Estudo de viabilidade — terminal e file manager próprios em Rust

Estado: somente ideias futuras, explicitamente adiadas pelo usuário em 2026-10-23; não aprovadas para implementação. Priorizar Flowral DE e live preview sem desenvolver terminal/file manager próprios agora. WezTerm e PCManFM continuam como decisões definitivas para MVP. Este documento define critérios para decidir sem reescrever software consolidado por impulso.

Terminal Emulator em Rust

Problema que resolveríamos

O WezTerm já oferece guias/splits, integração de temas e bom terminal moderno. Uma solução própria só compensa se reduzirmos significativamente o consumo de memória, simplificarmos a UI ‘paper’, pudermos controlar features específicas de Flowral e mantermos compatibilidade suficiente com TUI/CLI e agentes.

Implementação não é apenas uma UI

Requer: PTY e job control; parser VT ANSI/DEC; Unicode grapheme/wide chars/ambiguous width; cell grid, scrollback, copy mode, search; hyperlinks OSC 8 e OSC 52 clipboard sob consentimento; mouse reporting; bracketed paste; kitty keyboard protocol ou fallback; IME/composição; 24bit color e imagens (se prometidas); seleção drag, performance, resize (SIGWINCH), symlinks/cwd, segurança de sequências de controle e integração Wayland/Slint.

Candidatos a estudar para reutilização: alacritty_terminal (parser/state, checar licença/API), vte (parser), wezterm_term se reutilizável; render com Slint canvas/software/GPU ou camada específica. Avaliar maturidade/API/licença antes de integrar.

Três rotas

Rota	Escopo	Risco
Customizar WezTerm	tema, shortcuts, launch profile, esconder chrome	baixo; MVP
Criar shell/launcher externo que abra terminal existente	experiência Flowral sem emular VT	baixo/médio
Terminal nativo completo	protocolo, grid, renderer, inputs, PTY, testes	alto

Spike exigido: POC com sh/fish, nvim, OpenCode TUI, clipboard, PTY resize e Unicode em Wayland no E430. Registrar RSS/PSS, latência e bugs frente ao WezTerm; sem resultado convincente, encerrar estudo.

File manager em Rust

Problema

PCManFM é prático e suporta operações fundamentais, mas sua aparência GTK/CSD e extensibilidade podem divergir do design Flowral. Um gerenciador próprio facilitaria componentes Slint, sidebars/contextualização e integração com tema/apps/IA.

Requisitos inevitáveis

Navegação por locais, diretórios e symlinks, breadcrumbs, histórico, busca incremental.
Copiar/mover/renomear/excluir com progresso, cancelar, conflito de nomes e undo/trash.
Drag-and-drop Wayland, clipboard MIME, file chooser e xdg-desktop-portal.
Montar mídia/pendrives/volumes via udisks2 e permissões; SMB/SFTP/GVfs quando necessário.
Associações MIME/.desktop, xdg-open, ícones, thumbnails assíncronas e cache.
ACL/permissões, operações em diretórios enormes, Unicode e tratamento seguro de links.
Observação de FS, symlink cycles, confirmação de operações destrutivas, prevenção de path traversal.
Acessibilidade teclado/pesquisa/navegação e tratamento de arquivos ocultos.

Alternativas

PCManFM temático: customizar ícones, GTK theme, shortcuts, integrar launcher e portal. MVP recomendado.
Frontend Rust+Slint com backend de sistema: protótipo com operações básicas, sem remover PCManFM; GVfs/GIO via bindings quando útil.
File manager nativo completo: versão posterior após cobertura de operações e protocolos remotos.

Critérios para substituir PCManFM

Erros zero em operações de arquivo de teste (inclusive conflito, cancel, rollback quando suportado).
Sem perda de dados em arquivos/diretórios de até dezenas de milhares de entradas.
Fluxo UI superior e mais acessível, mesma associação MIME e montagem de mídia.
Desempenho e consumo ao menos equivalentes; não sacrificar robustez por estética.
Suporte remoto explicitamente compatível ou fallback transparente para PCManFM.

Decisão futura

Realizar duas POCs independentes: (1) terminal PTY + grid com Fish/Neovim; (2) file manager navegação + copy/move/trash + mount. Registrar complexidade, binário, PSS, compatibilidade Wayland e risco. Só então aprovar/recusar reescrita.