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 de imagens no shell Android (o Apple já decodifica pelo CoreGraphicsImageLoader em texturas RGBA8).

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 ListDetail é o padrão de duas colunas como componente (o primeiro adaptativo do catálogo).

•

Shells prontos nos templates — entregues: `dotnet new equantic-native --shell blank|tabs|drawer| list-detail (e --shell blank|topnav|dashboard` no template web), parâmetro de ESCOLHA nos dois templates que já existem, em vez de um template por formato; todo formato é adaptativo.

•

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 (nove comandos SDF/textura — o nono, FillAnnularSector, saiu na 0.2.0-preview.45), 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 — e a primeira forma do engine, o setor anular, está FEITA: um SDF exato com paridade Reference↔Metal↔Vulkan, provado por um consumidor real num sunburst de 5,38 milhões de ficheiros.

Sete workstreams — formas no engine (o setor saiu; a decisão polígono-vs-textura espera o benchmark do blob do consumidor), 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; o bundle ad hoc já se reconstrói do payload, allowlista RIDs e falha o build numa assinatura má, veja Photon), o loop do desenvolvedor (correr no simulador/emulador com um comando, perfis de IDE, redeploy ao salvar), 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: o primeiro consumidor constrói contra o SDK a partir de pacotes LOCAIS (veja Fluxo de build) e renderiza byte-idêntico por pacotes e por source. Plano completo: docs/DESKTOP-PLAN.md no repositório principal.

Trilho M: renderização de email

Escreva um e-mail em C# com os mesmos componentes com que uma página é escrita, e receba HTML que um cliente de e-mail realmente renderiza. E-mail é um terceiro realizer ao lado da web e do Photon — um alvo cujo motor é apenas muito restritivo, que é a mesma forma arquitetural de um alvo sem DOM.

Saiu na 0.2.0-preview.45 — eQuantic.UI.Email: tabelas aninhadas com células espaçadoras para os gaps, estilos inline, cores literais, guarda de URL absoluta, shell de 600px, gêmeo em texto puro a partir da mesma árvore, e recusas em tempo de build para tudo que um e-mail não consegue fazer. À frente: a matriz de clientes reais (um sample gerado contra Gmail, Outlook e Apple Mail) e os pins de HTML quando a saída assentar. O design e as cercas estão em Renderização de e-mail.

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).

PREVIOUSPhoton-pt-BR

NEXTRuntime-pt-BR

ON THIS PAGE