Roadmap pt BR

Roadmap do projeto

🌐 Esta página em: English · Português

Sincronizado com o ROADMAP.md do repositório principal (a fonte da verdade). Esta página lista o que está pela frente; o que o produto já faz está documentado nas páginas de produto.

Trilho web

• Estado global + orçamentos de performance.
• Push em tempo real do servidor ([ServerEvent] sobre SignalR); hoje os Server Actions são requisição/resposta.
• API Navigator programática e tipada para navegação no cliente (o roteador em si está completo, e guiado por links).
• Densidade de source map por instrução; hoje o mapeamento de pilha C# é por membro.

Trilho nativo (Photon)

• Decodificação/upload de imagem, o consumidor de Texture que falta (hoje o Image renderiza a superfície de placeholder dele).

Trilho de componentes

• Extensões variáveis de item no ListView (medição incremental); a v1 é vertical com extensão fixa.
• Planilha: rolagem 2D (folhas largas), motor de fórmulas, formatação por célula, mesclas, painéis congelados, tudo fora do escopo da v1.
• Renderização de texto marcado inline nas superfícies de código durante a composição por IME.

Trilho F: fatores de forma (tablet, relógio, TV)

Um fator de forma não é um segundo projeto aqui: o mesmo C# já roda em macOS, iOS e Android a partir de um único equantic-native. O que muda é o SHELL em cada largura, e o que um aparelho faz que um telefone não faz.

Tablet já funciona. O WindowSizeClass (Compact <600dp, Medium 600-839, Expanded ≥840) e o AdaptiveNode são realizados nos dois alvos, e o NavigationRail completou o vocabulário: uma lista de NavItem, uma barra embaixo no telefone e uma rail na borda inicial do tablet. O que ainda falta ali é um padrão de lista-detalhe em duas colunas.

• Shells prontos nos templates: dotnet new equantic-native --shell blank|tabs|drawer| list-detail (e --shell blank|topnav|dashboard no template web), como parâmetro de ESCOLHA nos dois templates que já existem, em vez de um template por formato. O shell gerado é adaptativo por padrão.
• Wear OS: safe area redonda, uma classe de tamanho abaixo de Compact (um relógio tem ~200dp), entrada rotativa da coroa ou do bezel, swipe-to-dismiss. Cerca: Tiles e Complications não são Activities, então o write-once cobre o app do relógio e não o tile.
• Android TV: a peça central, navegação por foco com as setas, existe desde o passe de teclado; o que falta é o manifesto leanback, uma safe area de overscan, a escala de tipo de 10 pés e um anel de foco legível a três metros.
• Fora de escopo, com a razão: o Android Auto/AAOS obriga o app a montar os templates aprovados da Google em vez de desenhar o que quer, o oposto deste motor. XR fica na mesma prateleira.

Trilho W: Photon no desktop

As cercas entre o Photon de hoje e uma plataforma de app desktop publicável, cada uma verificada no código: sem paths arbitrários no engine (8 comandos SDF/textura), um IClock deliberadamente periódico cuja própria cerca nomeia o relógio de frames como a coisa por construir, hit-testing só por retângulo, sem superfície de shell desktop (menus, tray, diálogos de ficheiro, notificações, deep links), assinatura ad-hoc que quebra os grants de TCC do macOS a cada build, e uma janela por processo.

O que encolhe o trabalho, achado na mesma varredura: um canal de tempo determinístico já corre pelo layout nativo (TransitionStore), o driver de 120 Hz e os gradientes radiais de 2 stops existem, e a toolchain de shaders resolve-se sozinha — então a primeira forma do engine (um SDF de setor anular) é iniciável imediatamente.

Seis workstreams — formas no engine, relógio de frames + animação + um dispatcher de UI, um nó de desenho custom com eventos de ponteiro em coordenadas locais, a superfície de shell do macOS, empacotamento de verdade (assinatura, notarização, bundle a partir do publish, um updater mínimo — sequenciado primeiro), e os shells Windows/Linux que continuam pós-M5. Nasceu de uma migração real de app (um produto desktop em Electron), e cada peça é genérica. Plano completo: docs/DESKTOP-PLAN.md no repositório principal.

Trilho M: renderização de email

Escrever um email em C# com os mesmos componentes com que se escreve uma página, e receber HTML que um cliente de email realmente renderiza. Email é um terceiro realizador ao lado do web e do Photon — um alvo cujo motor é apenas muito restritivo, que é a mesma forma arquitetural de um alvo sem DOM.

Duas peças já existem: WebRealizer.Lower(..., styles: null) mantém os estilos inline em vez de atomizá-los em classes, e HtmlRenderer.RenderNode transforma a árvore rebaixada numa string. O que falta é o meio — layout em tabelas aninhadas para o motor do Word no Outlook, cores literais em vez de custom properties, URLs absolutas de imagem, e uma cerca sobre tudo o que um email não faz.

O desenho completo, as fatias (a M0 mede antes de a M1 construir) e as cercas estão em Renderização de Email.

Trilho I: inteligência de editor (CodeEditor)

O framework publica um editor de código de verdade (modelo de documento, seleção, histórico, realce, casamento de parênteses, busca, rabiscos) e ele hoje não consegue ajudar você a escrever. A metade que falta é a inteligência, e a peça que a torna possível está provada: o Roslyn responde completações semânticas sobre a mesma compilação que a página constrói (provado no playground, que compila o C# dos visitantes com o eqc de verdade) (context. oferece Theme; Col oferece Column, porque a superfície using static faz parte daquela compilação).

• I1, o modelo de completação em Primitives, ao lado do CodeEditorController: itens, seleção, o span que um commit substitui, abrir/filtrar/mover/aceitar/dispensar. Write-once, testável sem tela.
• I2, as teclas e a lista em Components: a lista é posicionada no cursor a partir das métricas que o editor já calcula (ContentTop, LineHeight, ContentLeft, ColumnWidth), do jeito que a barra de busca já flutua sobre o código.
• I3, ajuda de assinatura: o painel de parâmetros no (, sobre o encanamento do I1 e o posicionamento do I2.

O problema real é latência, não completações: buscar num gatilho (. ou Ctrl+Space), filtrar localmente enquanto a digitação continua, cancelar requisições velhas. Diagnósticos ao vivo, rabiscos enquanto se digita, são a mesma forma.

Trilho E: a extensão "eQuantic UI" para VS Code

Um editor visual de primeira parte sobre o próprio SDK: preview de tela ao vivo (o realizador web DE VERDADE numa webview), clique para selecionar no visualizador, um painel de propriedades que edita o código C# por rewrites do Roslyn, até a edição visual completa. Marcos E1 (preview ao vivo) → E4 (edição completa).

Correção (2026-08-14): os source maps V3 não conseguem carregar a seleção. O corpo inteiro do Build é emitido por uma única chamada, então a posição mais fina que um mapa consegue nomear é o início do método — um módulo publicado tem uma linha de 942 caracteres. A identidade vem, em vez disso, de um VisualNode.Origin neutro de alvo carimbado por uma emissão em modo de design, que é exato em vez de correlacionado, e que o track nativo herda de graça.

O E1 (preview ao vivo do buffer não salvo), o E2 (clique para selecionar e pular para o código), o E3 (o painel de propriedades) e a metade estrutural do E4 (inserir, mover, remover) já saíram. Veja Editor visual.

Diretrizes permanentes

• Zero dependências de terceiros onde a plataforma fornece a capacidade (frameworks do sistema, toolchains embarcadas, o modelo Bun/slangc).
• Falhar alto: qualquer coisa que o SDK não consiga realizar fielmente é erro de build, nunca divergência silenciosa.
• Tudo pinado: conformidade diferencialmente, estilos por cross-pins idênticos byte a byte, pixels por goldens, hidratação por identidade de classe (e2e).