Flowral DE — ambiente gráfico próprio sem reescrever o Linux

Status: planejamento e backlog. A tecnologia para aplicações próprias é Rust + Slint, mas integração Slint ↔ Wayland Layer Shell para painéis e toasts exige validação. O Swirl continua compositor; Void continua base. Não implementar todas as substituições no primeiro release.

Visão e fronteiras

Um Flowral DE não precisa incluir um compositor, um gerenciador de rede novo ou um servidor de áudio novo. Ele precisa oferecer uma experiência coesa e acessível em volta dos serviços consolidados.

Flowral DE = Swirl (compositor)
           + Flowral Theme Engine (tokens/adapters, sem daemon residente)
           + Flowral Control Center (aplicação sob demanda)
           + futuro Flowral Shell:
               Panel / Launcher / Notifications / OSD / Power Menu
           + integração com greetd / swayidle / swaylock
           + NetworkManager / BlueZ / PipeWire / UPower / XBPS / portals

O objetivo é substituir interfaces, não protocolos e serviços profundos que já estão maduros.

Distribuição das versões

O roadmap oficial agora organiza as entregas por v1.0, v1.1, v1.2, v2.0+ e pesquisa sem versão. A matriz abaixo continua servindo para avaliar dificuldade e ordem de experimentação, não prazos: Theme Engine, Control Center, Panel, Launcher, OSD, Power Menu, Wallpaper e lock/idle tematizados são objetivos da v1.0, enquanto Notifications/Toasts é meta v1.1 e Tray/Clipboard v1.2. Tudo exige testes reais e pode ser adiado com fallback.

Matriz por dificuldade e prioridade

Estimativas relativas de esforço (baixa / média / alta / crítica), não estimativa de dias nem garantia de consumo menor de RAM.

Nota: as decisões anteriores descrevem swaybar como solução provisória. O usuário mencionou Waybar agora; Flowral Panel deve poder substituir qualquer uma, sem converter isso em decisão de adotar Waybar.

Funções e critérios de cada app

1 — Flowral Power Menu (baixa)

UI com Suspender, Sair, Reiniciar, Desligar, Cancelar. Atalhos teclado e navegação acessível. Nunca executar comandos privilegiados arbitrários. Mostra confirmação quando há risco de perda de trabalho; invocar ações via backend de sessão/energia validado. Falha não deixa sessão bloqueada.

2 — Flowral OSD (baixa–média)

Overlay de brilho, volume, mute, dispositivos e estado de microfone, sem stealing focus. Recebe atualizações dos serviços existentes; oculta-se após intervalo configurável. Pode compartilhar processo com Flowral Panel se o consumo for menor, mas não carregar Control Center inteiro sempre no boot.

3 — Flowral Wallpaper (baixa para UI)

Escolher imagem, crop/fit e tema por monitor, processar versões estáticas desfocadas para lockscreen, salvar config XDG. Na v0.1 deixar swaybg renderizar; processador de wallpaper próprio e animações só após benchmark E430. Não precisa manter indexador permanente.

4 — Flowral Switcher (baixa–média)

Lista compacta de workspaces, estado e janelas obtidos via IPC Swirl, sem polling agressivo. Alternar por teclado/gestos; cartões/miniaturas são opcionais e mais custosos. Fallback aos comandos nativos Swirl.

5 — Flowral Launcher (média)

Busca instantânea e teclado-first; categorias, favoritos e histórico só se opt-in. Ler e interpretar arquivos desktop-entry corretamente, incluindo Exec/field codes/terminal, ícones e diretórios XDG, sem executar linhas arbitrárias de um campo como shell. Layer surface com foco apropriado; fallback Fuzzel durante desenvolvimento.

6 — Flowral Panel (média)

Dois blocos no rodapé, próximos às referências visuais: workspace/data à esquerda, relógio/bateria/rede/áudio à direita. Trabalho com Layer Shell, IPC Swirl, eventos UPower, status e multi-monitor. Não implementar tray no primeiro protótipo. UI Reactiva Rust/Slint somente se prova de integração Layer Shell for aprovada.

7 — Flowral Notifications (média)

Mako é daemon de notificação, não apenas desenho de toasts. Flowral precisa implementar org.freedesktop.Notifications na bus de sessão D-Bus e cumprir versão suportada da Desktop Notifications Specification: Notify, CloseNotification, capabilities, replacement IDs, actions, timeouts, closed reasons, hints e icon support quando aplicável. Registro exclusivo do nome D-Bus por sessão; desativar Mako quando substituto estiver aprovado. Sem logs do corpo das mensagens por padrão.

Protocolo: https://specifications.freedesktop.org/notification/latest/

8 — Flowral Clipboard (média)

Usar protocolos de clipboard Wayland e bibliotecas consolidadas; histórico desligado por padrão, limpar sob demanda, ignorar tipos sensíveis e controlar persistência. Nunca salvar senhas/segredos recebidos sem uma política de privacidade; comparar benefício com wl-clipboard + cliphist.

9 — Flowral Idle Settings (baixa para painel)

Expor sliders e regras para swayidle, incluindo lock antes de suspender, DPMS off/on, inibidores e política de tampa. Não criar daemon idle do zero só para trocar tema. Se necessário depois, avaliar ext-idle-notify-v1, inhibit e tratamento de suspend/resume.

Referência: https://wayland.app/protocols/ext-idle-notify-v1

10 — Flowral Greeter (média–alta)

Interface de login própria em Rust+Slint sobre greetd IPC; greetd mantém a autenticação e inicialização de sessão. Evitar implementar um display manager próprio, PAM ou política de usuários. Greeter precisa rodar antes da sessão Flowral, possivelmente em compositor Wayland de login separado e sob usuário greeter; não assumir que Swirl do usuário já está iniciado. TTY fallback tuigreet obrigatório, e selecionar teclado/idioma/sessão corretamente; senha nunca em logs.

Referência: https://github.com/kennylevinsen/greetd

11 — Flowral Lock (tema simples; substituição crítica)

Tema de swaylock é barato. Substituir o mecanismo de bloqueio é outra história: cliente deve usar ext-session-lock-v1 se Swirl suportar, entrar em fail-closed, gerenciar todas as telas, validar autenticação PAM, resistir a falha do processo e ser revisado por segurança. Nunca fazer janela Slint normal que simula lock; isso não é bloqueio confiável.

Referência: https://wayland.app/protocols/ext-session-lock-v1

Tecnologia do shell

• Aplicações normais: Slint + Rust aprovado.
• Superfícies flutuantes ancoradas: Wayland Layer Shell, gestão de foco/teclado, namespace, escalonamento e múltiplas saídas.
• Candidato estável para estudar: Smithay Client Toolkit, com Layer Shell, mas integração direta a renderer Slint não está garantida.
• Candidato experimental: layer-shika, tentativa específica de unir Slint a Layer Shell. O próprio projeto alerta que ainda não é recomendado para produção.
• Alternativa de fallback se não houver integração robusta: manter Rust+Slint nos apps e fazer uma ADR para um frontend mínimo que implemente Layer Shell sem sacrificar segurança/performance. Não substituir stack aprovada sem evidência.

Outras substituições pequenas que fazem sentido (ideias para avaliar)

São candidatos, não funcionalidades aprovadas nem obrigatórias para a ISO. Para evitar proliferação de processos, screenshots, mídia, calendário e atalhos devem ser módulos do panel, launcher ou Control Center, não aplicações residentes independentes. O destino de cada um dependerá de benchmarks e compatibilidade real do Swirl.

Ordem de experimentos

1. Testar um único layer surface no Swirl exibindo relógio, alimentado por timer local; medir FPS, CPU, PSS, foco e qualidade gráfica.
2. Criar OSD de volume e menu de energia com mocks e backend real separáveis.
3. Painel sem tray, launcher simples com desktop-entry, notificações com service DBus e fallback.
4. Trocar programas um a um, removendo autostart do antigo e medindo ganho/perda.
5. Adicionar clipboard, tray e preferências de idle; manter login/lock em upstream até auditoria.
6. Considerar greeter, autenticação e portals em projeto separado de risco.

Gates comuns

Funciona em 1366×768 no Edge E430; keyboard-only; foco visível; seis temas; modo redução de movimento; sem apps órfãos; Swirl IPC compatível; start/stop e fallback no caso de crash; boot e RAM medidos com serviços essenciais. Nenhuma estimativa de RAM é garantia. Se o novo app consumir mais que o atual sem vantagem concreta, mantemos o upstream.

Não fazer: reimplementar Swirl/wlroots, NetworkManager, BlueZ, PipeWire, XBPS, PAM, polkit backend, portais ou o gerenciador de sessão só por consistência visual.