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