implements PLN-0064
This commit is contained in:
parent
1f85be3721
commit
6b60fa9d33
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
11
README.md
11
README.md
@ -2,7 +2,7 @@
|
||||
|
||||
Prometeu Studio is the desktop development environment for the Prometeu toolchain.
|
||||
|
||||
This repository packages the Studio shell together with the embedded services it depends on: project VFS, language tooling, compiler pipeline integration, and asset packing. The current implementation is a Java/JavaFX multi-module Gradle build.
|
||||
This repository packages the Studio shell together with the embedded services it depends on: compiler pipeline integration, asset packing, runtime/debug orchestration, and project-local Studio state. The current implementation is a Java/JavaFX multi-module Gradle build.
|
||||
|
||||
## What Lives Here
|
||||
|
||||
@ -10,8 +10,6 @@ The root project is a monorepo with these main areas:
|
||||
|
||||
- `prometeu-app`: JavaFX application entry point (`p.studio.App`).
|
||||
- `prometeu-studio`: Studio UI, workspaces, project session lifecycle, play/stop flow, and debugger-facing surfaces.
|
||||
- `prometeu-vfs`: project document access and save/open contracts.
|
||||
- `prometeu-lsp`: language-service integration used by the editor workflow.
|
||||
- `prometeu-packer`: embedded packer APIs and implementation used by Studio.
|
||||
- `prometeu-compiler`: compiler core, build pipeline, frontend APIs, and the PBS frontend.
|
||||
- `prometeu-infra`: shared infrastructure used across modules.
|
||||
@ -21,14 +19,13 @@ The root project is a monorepo with these main areas:
|
||||
|
||||
## Current Product Shape
|
||||
|
||||
The Studio shell currently organizes the product around four workspaces:
|
||||
The Studio shell currently organizes the product around three workspaces:
|
||||
|
||||
- Assets
|
||||
- Code editor
|
||||
- Debug
|
||||
- Shipper
|
||||
|
||||
At runtime, the app boots an embedded packer, creates a project document VFS, wires LSP services, and opens the Studio launcher window. Project creation currently scaffolds a Prometeu workspace with `prometeu.json`, `src/`, `assets/`, `build/`, `cartridge/`, `.workspace/`, and local Studio metadata.
|
||||
At runtime, the app boots an embedded packer, restores project-local Studio state, and opens the Studio launcher window. Project creation currently scaffolds a Prometeu workspace with `prometeu.json`, `src/`, `assets/`, `build/`, `cartridge/`, `.workspace/`, and local Studio metadata.
|
||||
|
||||
## Requirements
|
||||
|
||||
@ -68,7 +65,7 @@ If you are new to the codebase, this order is usually the fastest path:
|
||||
|
||||
1. Start at `prometeu-app` to see application bootstrap.
|
||||
2. Read `prometeu-studio` for the shell, workspaces, and user-facing flows.
|
||||
3. Read `prometeu-vfs`, `prometeu-lsp`, and `prometeu-packer` for service boundaries.
|
||||
3. Read `prometeu-packer` for asset and packaging boundaries.
|
||||
4. Read `prometeu-compiler` when you need compiler or PBS language behavior.
|
||||
|
||||
## Specs And Architecture
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
{"type":"meta","next_id":{"DSC":32,"AGD":35,"DEC":32,"PLN":65,"LSN":47,"CLSN":1}}
|
||||
{"type":"discussion","id":"DSC-0031","status":"in_progress","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-05","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[{"id":"AGD-0034","file":"AGD-0034-vscode-editor-migration-feasibility.md","status":"accepted","created_at":"2026-05-05","updated_at":"2026-05-05"}],"decisions":[{"id":"DEC-0031","file":"DEC-0031-studio-editor-workspace-cleanup.md","status":"in_progress","created_at":"2026-05-05","updated_at":"2026-05-05","ref_agenda":"AGD-0034"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0063","file":"PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0064","file":"PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md","status":"open","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]}],"lessons":[]}
|
||||
{"type":"discussion","id":"DSC-0031","status":"in_progress","ticket":"studio-editor-workspace-cleanup","title":"Limpeza completa do Workspace Editor do Studio e remoção dos acoplamentos legados","created_at":"2026-05-05","updated_at":"2026-05-05","tags":["studio","editor","cleanup","vfs","lsp","migration"],"agendas":[{"id":"AGD-0034","file":"AGD-0034-vscode-editor-migration-feasibility.md","status":"accepted","created_at":"2026-05-05","updated_at":"2026-05-05"}],"decisions":[{"id":"DEC-0031","file":"DEC-0031-studio-editor-workspace-cleanup.md","status":"in_progress","created_at":"2026-05-05","updated_at":"2026-05-05","ref_agenda":"AGD-0034"}],"plans":[{"id":"PLN-0062","file":"PLN-0062-shell-session-and-state-cleanup-after-editor-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0063","file":"PLN-0063-legacy-lsp-and-vfs-module-removal-with-runtime-preservation.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]},{"id":"PLN-0064","file":"PLN-0064-normative-test-and-lesson-cleanup-for-editor-stack-removal.md","status":"done","created_at":"2026-05-05","updated_at":"2026-05-05","ref_decisions":["DEC-0031"]}],"lessons":[]}
|
||||
{"type":"discussion","id":"DSC-0030","status":"done","ticket":"studio-scene-pack-runtime-binary-contract","title":"Studio scene pack contract for runtime SCENE binary payload","created_at":"2026-04-24","updated_at":"2026-05-01","tags":["studio","packer","runtime","scene","asset-pack","binary-format","tiled"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0046","file":"discussion/lessons/DSC-0030-studio-scene-pack-runtime-binary-contract/LSN-0046-canonical-scene-owns-editorial-truth-while-pack-stays-request-driven.md","status":"done","created_at":"2026-05-01","updated_at":"2026-05-01"}]}
|
||||
{"type":"discussion","id":"DSC-0029","status":"done","ticket":"studio-frame-composer-syscall-and-sprite-alignment","title":"Studio Alignment with Runtime FrameComposer Syscalls and Sprite Composition","created_at":"2026-04-18","updated_at":"2026-04-18","tags":["studio","compiler","pbs","stdlib","runtime-alignment","abi","syscall","frame-composer","sprites"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0041","file":"discussion/lessons/DSC-0029-studio-frame-composer-syscall-and-sprite-alignment/LSN-0041-composer-must-own-public-sprite-composition.md","status":"done","created_at":"2026-04-18","updated_at":"2026-04-18"}]}
|
||||
{"type":"discussion","id":"DSC-0028","status":"done","ticket":"studio-tiled-parser-assets-scene-asset-type","title":"Tiled Parser and Scene Asset-Type Ownership in Assets Workspace","created_at":"2026-04-15","updated_at":"2026-04-23","tags":["studio","assets","scene","tiled","parser","asset-type"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0045","file":"discussion/lessons/DSC-0028-studio-tiled-parser-assets-scene-asset-type/LSN-0045-asset-owned-scene-bank-and-tiled-xml-workflow.md","status":"done","created_at":"2026-04-23","updated_at":"2026-04-23"}]}
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-03-31
|
||||
tags: [studio, editor, workspace, read-only, navigator, tabs, lsp-deferred, ui-foundations]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio code editor. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
Studio needed a real `Code Editor` workspace, but the team explicitly did not want the first wave to collapse UI structure, file management, write behavior, and language semantics into one premature implementation.
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-03-31
|
||||
tags: [studio, editor, vfs, project-session, filesystem, boundary, architecture]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio editor/VFS split. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The first Studio `Code Editor` wave had already established a read-only editorial shell, but the concrete implementation still let the editor package own direct filesystem concerns for:
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-04-02
|
||||
tags: [studio, editor, vfs, lsp, access-policy, save, read-only, frontend-boundary]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio editor, VFS, and legacy LSP flow. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The first Studio `Code Editor` implementation had already established a session-owned document boundary through `prometeu-vfs`, but it was still missing the next operational split:
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-04-02
|
||||
tags: [studio, editor, frontend, semantic-highlighting, lsp, compiler, pbs, presentation]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio semantic editor presentation path. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The first semantic highlight wave for frontend documents had already proved that Studio could consume semantic spans through the integrated LSP path.
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-04-06
|
||||
tags: [studio, editor, scope-guides, structural-anchors, semantic-read, frontend-contract]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio editor gutter and structural-anchor flow. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The Studio editor already exposed structural guides in the gutter, but the old behavior mixed two different concerns:
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-04-06
|
||||
tags: [studio, editor, inline-hints, lsp, compiler, pbs, type-inference, rendering]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio inline-hint path. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The repository needed inline type hints for inferred PBS `let` bindings, but the real architectural issue was broader than one PBS feature.
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-04-04
|
||||
tags: [studio, editor, indentation, tabs, setup, dot-studio, project-creation, gitignore]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents indentation policy choices made for the removed embedded Studio editor. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The Studio editor exposed an indentation chip in the status bar, but that chip was driven by file-content heuristics rather than by a stable editor policy.
|
||||
|
||||
@ -6,6 +6,10 @@ created: 2026-04-06
|
||||
tags: [studio, editor, frontend, write, save, vfs, lsp, access-policy, persistence]
|
||||
---
|
||||
|
||||
## Historical Status
|
||||
|
||||
This lesson documents the removed embedded Studio frontend edit/save wave. Keep it as historical context only; do not treat it as current product guidance after `DEC-0031`.
|
||||
|
||||
## Context
|
||||
|
||||
The first editor write wave had deliberately kept frontend files hard `read-only` while semantic-read support shipped through `prometeu-lsp`.
|
||||
|
||||
@ -2,9 +2,9 @@
|
||||
id: PLN-0064
|
||||
ticket: studio-editor-workspace-cleanup
|
||||
title: Normative Test and Lesson Cleanup for Editor Stack Removal
|
||||
status: open
|
||||
status: done
|
||||
created: 2026-05-05
|
||||
completed:
|
||||
completed: 2026-05-05
|
||||
tags: [studio, editor, cleanup, docs, tests, lessons]
|
||||
---
|
||||
|
||||
@ -72,11 +72,11 @@ Remove or revise the normative documentation, tests, lessons, and user-facing re
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Studio specs no longer define the embedded editor stack as an active surface.
|
||||
- [ ] Studio README/index material no longer points to removed editor/VFS/LSP architecture as current.
|
||||
- [ ] Editor-specific i18n keys are removed or no longer consumed.
|
||||
- [ ] Obsolete tests are removed or rewritten.
|
||||
- [ ] Historical lessons are clearly demoted from active operational guidance.
|
||||
- [x] Studio specs no longer define the embedded editor stack as an active surface.
|
||||
- [x] Studio README/index material no longer points to removed editor/VFS/LSP architecture as current.
|
||||
- [x] Editor-specific i18n keys are removed or no longer consumed.
|
||||
- [x] Obsolete tests are removed or rewritten.
|
||||
- [x] Historical lessons are clearly demoted from active operational guidance.
|
||||
|
||||
## Dependencies
|
||||
|
||||
@ -88,4 +88,3 @@ Remove or revise the normative documentation, tests, lessons, and user-facing re
|
||||
- Removing normative docs too early may temporarily leave the repo without clear current guidance.
|
||||
- Historical lessons may still be valuable; deleting them outright could lose context that should instead be reclassified.
|
||||
- Partial cleanup can leave broken links or missing i18n keys that only appear at runtime.
|
||||
|
||||
|
||||
@ -44,15 +44,10 @@ The left workspace selector remains fixed in the baseline Studio shell.
|
||||
|
||||
The baseline workspace set includes:
|
||||
|
||||
- Code Editor;
|
||||
- Asset Management;
|
||||
- Debugger/Profiler;
|
||||
- Shipper, temporarily represented by the current `BuilderWorkspace`.
|
||||
|
||||
Workspace-local behavior for the first `Code Editor` wave is defined in:
|
||||
|
||||
- `5. Code Editor Workspace Specification.md`
|
||||
|
||||
`BuilderWorkspace` is transitional and must not be treated as a long-term architectural reference for the final shipping surface.
|
||||
|
||||
## Workspace Architecture Model
|
||||
@ -71,7 +66,7 @@ Baseline workspace architecture rules are:
|
||||
The shell must not encourage a workspace model where every interaction falls back to whole-workspace refresh.
|
||||
|
||||
Detailed local workspace composition remains workspace-owned.
|
||||
For example, `Code Editor`-local layout, navigator behavior, tab rules, passive placeholder surfaces, document access-mode behavior, and editor-local save surfaces are not shell-global rules and must be defined by the workspace-local editor specification.
|
||||
For example, `Assets`-local navigator behavior, detail-pane composition, and mutation flows are not shell-global rules and must be defined by the workspace-local specifications that still exist.
|
||||
|
||||
Project-session boundaries may still exist above a workspace when the state must remain alive while the project window stays open.
|
||||
|
||||
|
||||
@ -1,377 +0,0 @@
|
||||
# Code Editor Workspace Specification
|
||||
|
||||
## Status
|
||||
|
||||
Active
|
||||
|
||||
## Applies To
|
||||
|
||||
- `prometeu-studio`
|
||||
- the Studio `Code Editor` workspace
|
||||
- the first controlled editor write wave for supported documents including frontend sources
|
||||
|
||||
## Purpose
|
||||
|
||||
Define the normative Studio contract for the first `Code Editor` workspace wave.
|
||||
|
||||
This specification stabilizes:
|
||||
|
||||
- the baseline visual composition of the workspace,
|
||||
- the `Project Navigator` role and scope,
|
||||
- the controlled editable file-opening model,
|
||||
- the responsive tab baseline,
|
||||
- the editor-owned composition surfaces that host save and semantic-read UX,
|
||||
- the gutter-based active-structure indicator model for semantic editor scopes,
|
||||
- the editor-local save surfaces,
|
||||
- and the workspace boundary with the integrated frontend semantic-read phase.
|
||||
|
||||
## Authority and Precedence
|
||||
|
||||
This specification extends:
|
||||
|
||||
- [`1. Studio Shell and Workspace Layout Specification.md`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md)
|
||||
- [`2. Studio UI Foundations Specification.md`](2.%20Studio%20UI%20Foundations%20Specification.md)
|
||||
- [`3. Studio Components Module Specification.md`](3.%20Studio%20Components%20Module%20Specification.md)
|
||||
- [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md)
|
||||
- [`7. Integrated LSP Semantic Read Phase Specification.md`](7.%20Integrated%20LSP%20Semantic%20Read%20Phase%20Specification.md)
|
||||
|
||||
If this document conflicts with the global Studio shell specifications, the shell specifications control shell-wide behavior and this document controls workspace-local editor behavior.
|
||||
|
||||
## Normative Inputs
|
||||
|
||||
The `Code Editor` workspace must assume:
|
||||
|
||||
- the Studio shell already mounts `Code Editor` as a baseline workspace,
|
||||
- the current wave allows editing for the supported document classes classified by `prometeu-vfs` as editable, including frontend-scoped supported documents,
|
||||
- all project files remain visible in the editor workspace even when only some are frontend-relevant,
|
||||
- `prometeu.json` plus the selected frontend may identify source roots worth tagging,
|
||||
- the integrated frontend semantic-read phase may add diagnostics, symbols, outline-facing structure, definition, and highlight for frontend documents,
|
||||
- the integrated frontend semantic-read phase may later add dedicated structural-anchor metadata for exact scope-indicator anchoring,
|
||||
- frontend semantic presentation contract data comes from frontend-owned metadata published through `FrontendSpec`,
|
||||
- and the current wave must not depend on semantic behavior to remain coherent.
|
||||
|
||||
This workspace may consume Studio project metadata and Studio-owned workspace framework primitives, but it must not infer a semantic-provider contract beyond the explicit frontend-owned descriptor surfaced by the integrated semantic-read phase.
|
||||
This workspace must consume project tree and document data through `prometeu-vfs` rather than through editor-owned direct filesystem readers.
|
||||
This workspace must consume document access policy and save capability from `prometeu-vfs` rather than rederiving editability locally.
|
||||
|
||||
## Workspace Model
|
||||
|
||||
The `Code Editor` workspace is:
|
||||
|
||||
- project-aware,
|
||||
- file-oriented,
|
||||
- controlled-editable in this wave, with supported documents following the canonical access mode provided by `prometeu-vfs`,
|
||||
- and not a full semantic IDE surface yet.
|
||||
|
||||
The workspace must help the user:
|
||||
|
||||
- see the full project tree,
|
||||
- identify frontend-relevant source roots visually,
|
||||
- open supported files into editor tabs,
|
||||
- save editable supported documents through editor-local commands,
|
||||
- consume frontend semantic-read UX provided through the integrated LSP phase when that phase is active,
|
||||
- understand the active file context,
|
||||
- and understand that broader IDE automation remains outside this wave.
|
||||
|
||||
The workspace must not pretend to offer:
|
||||
|
||||
- merge behavior,
|
||||
- completion,
|
||||
- rename, code actions, or formatting,
|
||||
- or editor-owned semantic inference that bypasses the integrated LSP phase.
|
||||
|
||||
## Baseline Layout
|
||||
|
||||
The baseline workspace layout is:
|
||||
|
||||
- a left editor column,
|
||||
- a central editor work area,
|
||||
- a lower helper region,
|
||||
- and a bottom status bar.
|
||||
|
||||
The left editor column must be a vertical stack containing:
|
||||
|
||||
- a functional `Project Navigator` at the top,
|
||||
- and a reserved `Outline` region below it.
|
||||
|
||||
The central editor work area must contain:
|
||||
|
||||
- a top command bar containing at least `Save` and `Save All`,
|
||||
- a tab strip at the top,
|
||||
- and the editor body below it.
|
||||
|
||||
The lower helper region is present in this wave only as a passive placeholder.
|
||||
|
||||
## Component Ownership Rules
|
||||
|
||||
The `Code Editor` workspace must be implemented as a composition root plus child controls/panels rather than one monolithic render surface.
|
||||
|
||||
Rules:
|
||||
|
||||
- the workspace root should coordinate layout, workspace-level session state, and structural synchronization;
|
||||
- the workspace root should consume project-session-owned document services such as `prometeu-vfs` rather than owning their lifecycle locally;
|
||||
- the `Project Navigator`, tab strip, editor body, reserved `Outline`, helper region, and status bar should exist as explicit local surfaces;
|
||||
- passive placeholder surfaces must remain visually real without implying unsupported functionality;
|
||||
- and the first wave should preserve a clean path for later extraction of reusable Studio controls when the surfaces become stable enough to justify that move.
|
||||
|
||||
## Project Navigator Rules
|
||||
|
||||
### Primary Navigation Unit
|
||||
|
||||
- The primary navigation unit is the project file or directory.
|
||||
- The navigator must cover the whole project rather than only frontend-tagged roots.
|
||||
- Frontend tagging is supplementary context, not an inclusion filter.
|
||||
|
||||
### Structural Snapshot
|
||||
|
||||
- The navigator must consume a structural project-tree entity provided by `prometeu-vfs`.
|
||||
- That structural tree must not replace the filesystem as the source of truth.
|
||||
- Content snapshots are separate and are only required for files that are actually opened in the editor through `prometeu-vfs`.
|
||||
- The navigator may request more targeted tree refresh operations than a full-tree reload when the `prometeu-vfs` contract provides them.
|
||||
|
||||
### Visibility and Ordering
|
||||
|
||||
- All project files and directories must be visible in the navigator.
|
||||
- Hidden files must be included by default.
|
||||
- Folders must sort before files.
|
||||
- Items within those groups must sort alphabetically.
|
||||
|
||||
### Frontend-Aware Tagging
|
||||
|
||||
- `prometeu.json` plus the selected frontend may be used to tag relevant source roots or source directories.
|
||||
- That tagging must not hide non-source project files.
|
||||
- That tagging must not imply semantic/editor-language ownership by the navigator itself.
|
||||
- Rendering those tags remains a Studio UI concern even when the source data comes from `prometeu-vfs`.
|
||||
|
||||
### Refresh Model
|
||||
|
||||
- The navigator must perform one initial refresh when the project opens.
|
||||
- The navigator must expose a manual refresh action directly on the navigator surface and route that request through `prometeu-vfs`.
|
||||
- Watcher-driven automatic refresh is explicitly deferred from this wave.
|
||||
|
||||
### Unsupported Files
|
||||
|
||||
- Unsupported or non-text files may still appear in the navigator.
|
||||
- File support and unsupported-file classification belong to `prometeu-vfs`.
|
||||
- Attempting to open such a file must show a simple modal stating that the file is not supported in this wave.
|
||||
- The workspace must not fake a partial preview to imply unsupported file-format coverage.
|
||||
|
||||
## Tabs and File Opening Rules
|
||||
|
||||
- Selecting a supported file that is not already open must open it in a new tab.
|
||||
- File opening must resolve document content through `prometeu-vfs`.
|
||||
- The editor must maintain opened-file content in memory for the active Studio session only.
|
||||
- Frontend-scoped supported documents may coexist in tabs with other editable supported documents.
|
||||
- The tab strip must be responsive rather than fixed to one hardcoded tab count.
|
||||
- Overflow tabs must remain accessible through an IntelliJ-style overflow control.
|
||||
- The active tab must remain visible.
|
||||
- The tab label must use only the file name with extension.
|
||||
|
||||
The first wave must not define:
|
||||
|
||||
- tab pinning,
|
||||
- drag-and-drop tab reordering,
|
||||
- grouped tabs,
|
||||
- split editors.
|
||||
|
||||
Project-session-owned cross-session tab restoration is accepted for the project-local Studio state wave.
|
||||
|
||||
Rules:
|
||||
|
||||
- persisted editor restoration state must come from the project-session-owned `.studio/` state store rather than from an editor-owned ad hoc file;
|
||||
- accepted restoration scope in this wave is limited to open tabs and active tab;
|
||||
- editor layout restoration accepted in this wave may include divider-driven editor sizing, `Project Navigator` expansion state, and dock-panel configuration such as `Outline` and `Helper` open/closed state plus their restored size;
|
||||
- restoration must degrade safely when a previously open file is missing or unsupported.
|
||||
|
||||
## Access-Mode and Save Model
|
||||
|
||||
The first `Code Editor` write wave is controlled rather than universally editable.
|
||||
|
||||
Rules:
|
||||
|
||||
- the workspace must treat `prometeu-vfs` as the canonical source of document access mode for supported files;
|
||||
- the workspace must not infer frontend scope from path heuristics, local UI state, or ad hoc extension checks;
|
||||
- supported frontend-scoped documents may be editable when `prometeu-vfs` classifies them as editable;
|
||||
- editable scope is limited to the supported textual classes exposed by `prometeu-vfs` for this wave, including supported frontend sources;
|
||||
- the workspace must expose save behavior only through an editor-local command bar containing at least `Save` and `Save All`;
|
||||
- the global shell `Save` menu item must not be the save surface for this wave;
|
||||
- save intent must route through `prometeu-vfs`, which remains the owner of persistence policy;
|
||||
- the active indentation policy for editable documents MUST come from project-local setup rather than from file-content heuristics;
|
||||
- the status-bar indentation chip MUST display the active configured policy, not inferred file contents;
|
||||
- pressing `Tab` in an editable document MUST insert spaces according to the active configured indentation width;
|
||||
- the active indentation policy MUST remain stable while the user edits document contents;
|
||||
- opening a file whose existing indentation diverges from the configured policy MUST NOT trigger automatic reformatting;
|
||||
- and the workspace must not define local merge/conflict behavior against disk changes.
|
||||
|
||||
## Outline Rules
|
||||
|
||||
- The `Outline` region must exist structurally in this wave.
|
||||
- Before the integrated LSP semantic-read phase is implemented, it may show a discreet placeholder state.
|
||||
- When the integrated LSP semantic-read phase is active, the `Outline` region may render frontend document-symbol structure and workspace-symbol-backed navigation owned by that phase.
|
||||
- The workspace must not fake semantic outline structure before real semantic ownership exists.
|
||||
|
||||
## Helper Region Rules
|
||||
|
||||
- The helper region must exist structurally in this wave.
|
||||
- Before the integrated LSP semantic-read phase is implemented, it may remain passive.
|
||||
- It exists only to stabilize workspace composition and reserve future space.
|
||||
- It may later host diagnostics or related semantic-read detail for frontend documents without changing workspace ownership.
|
||||
- It must not become a substitute for the shell-level `Activity` surface.
|
||||
|
||||
## Integrated Semantic-Read Boundary
|
||||
|
||||
- Frontend documents may be editable when `prometeu-vfs` grants editable access mode.
|
||||
- Diagnostics, document symbols, workspace symbols, outline-facing structure, definition, and frontend highlight must come through the integrated LSP semantic-read phase rather than from editor-local inference.
|
||||
- Exact anchor positions for semantic scope indicators must come from frontend-owned structural metadata rather than Studio-local text scanning when that metadata is available.
|
||||
- Opened frontend documents must be analyzed from the VFS-owned in-memory snapshot exposed through `prometeu-vfs`.
|
||||
- Unopened frontend documents may be analyzed from filesystem-backed state exposed through the same `prometeu-vfs` boundary.
|
||||
- Non-frontend highlight may remain Studio-local in this phase.
|
||||
- Frontend highlight must come from the integrated LSP semantic-read phase and use frontend-owned semantic presentation contract data derived from `FrontendSpec`.
|
||||
- Frontend semantic presentation resources must remain frontend-owned and must not be replaced by a Studio-owned generic fallback theme.
|
||||
- When semantic presentation descriptor data or usable frontend resources are absent, the workspace must continue without semantic highlight for that frontend document.
|
||||
- The workspace must not surface this condition as a product-facing editor error.
|
||||
- The workspace must not treat semantic-read over editorial snapshots as authorization for build participation or for bypassing `prometeu-vfs` access policy.
|
||||
|
||||
## Inline Hint Rules
|
||||
|
||||
Inline hints must be treated as a host-generic editor capability rather than as a PBS-only feature.
|
||||
|
||||
The Studio `Code Editor` must render inline hints only from frontend-owned semantic payloads transported through the integrated semantic-read phase.
|
||||
|
||||
The editor must not invent:
|
||||
|
||||
- hint existence policy,
|
||||
- hint text,
|
||||
- hint categories,
|
||||
- or host-owned semantic fallback hints.
|
||||
|
||||
If a frontend publishes valid inline hints through the accepted semantic-read contract, the editor must render them.
|
||||
|
||||
If a frontend does not publish inline hints for a construct, the editor must not synthesize one.
|
||||
|
||||
Inline hints are decorative only.
|
||||
|
||||
Therefore the editor must ensure that inline hints:
|
||||
|
||||
- do not modify document text;
|
||||
- do not become part of persisted file content;
|
||||
- do not participate as copied document text;
|
||||
- do not redefine selection ranges;
|
||||
- and do not redefine caret movement over the text model.
|
||||
|
||||
The completed capability must render inline hints as real inline editor decorations attached to document positions inside the editor flow.
|
||||
|
||||
An approximate visual implementation may exist only as an explicit transitional wave.
|
||||
|
||||
Any transitional approximation:
|
||||
|
||||
- must be documented as transitional;
|
||||
- must not redefine the final editor contract;
|
||||
- and must converge to real inline rendering in a later execution step.
|
||||
|
||||
When only some inline hint spans remain valid under degraded semantic analysis, the editor must continue rendering those valid spans rather than disabling all inline hints for the document.
|
||||
|
||||
## Scope Indicator Rules
|
||||
|
||||
The default semantic scope-indicator surface in the Code Editor must remain the gutter.
|
||||
|
||||
The first active-state wave must render at most two simultaneous semantic indicators:
|
||||
|
||||
- `activeContainer`
|
||||
- `activeScope`
|
||||
|
||||
The editor must not restore the previous full ancestry stack as the default active-state presentation.
|
||||
|
||||
`activeScope` must be selected as the smallest structural range that contains the caret.
|
||||
|
||||
`activeContainer` must be selected as the immediate structural ancestor of `activeScope`.
|
||||
|
||||
If no valid structural ancestor exists, the editor may omit `activeContainer`.
|
||||
|
||||
The editor must not promote a higher semantic owner such as function, type, or module when a nearer structural ancestor exists.
|
||||
|
||||
The concrete visual presentation of `activeContainer` and `activeScope` remains frontend-owned. This specification intentionally does not fix:
|
||||
|
||||
- colors,
|
||||
- stroke style,
|
||||
- dashed versus solid treatment,
|
||||
- opacity,
|
||||
- thickness,
|
||||
- or equivalent visual-emphasis details.
|
||||
|
||||
The Studio editor must only preserve the semantic distinction between the two indicator roles.
|
||||
|
||||
Exact guide start and end anchoring must consume the dedicated structural-anchor semantic surface defined by the integrated semantic-read specification.
|
||||
|
||||
The editor must not treat local brace scanning heuristics as the final production contract for exact anchor placement.
|
||||
|
||||
## Status Bar Rules
|
||||
|
||||
The status bar must remain mostly passive in this wave.
|
||||
|
||||
Its left side must show the breadcrumb path of the active file, such as `proj > src > file.pbs`.
|
||||
|
||||
Its right side must show:
|
||||
|
||||
- `L:C`,
|
||||
- line separator,
|
||||
- tabs/spaces mode,
|
||||
- file extension or language,
|
||||
- and access-mode state.
|
||||
|
||||
For this wave:
|
||||
|
||||
- `L:C` may remain a visual placeholder,
|
||||
- editable non-frontend documents may show their current file-type state without implying build participation,
|
||||
- hard `read-only` frontend documents must show an explicit `read-only` state,
|
||||
- and the status-bar `read-only` surface should be shaped so it can evolve into a per-file toggle later without requiring a model rewrite.
|
||||
|
||||
## Session State Rules
|
||||
|
||||
Visual/editorial state in this wave is session-local only.
|
||||
|
||||
That includes at minimum:
|
||||
|
||||
- open tabs,
|
||||
- active tab selection,
|
||||
- tree expansion state,
|
||||
- and similar visual editor state.
|
||||
|
||||
The following remain outside editor-owned session state:
|
||||
|
||||
- project-session ownership of `prometeu-vfs`,
|
||||
- structural project-tree data returned by `prometeu-vfs`,
|
||||
- support classification rules,
|
||||
- document loading responsibilities,
|
||||
- save persistence policy,
|
||||
- and build-facing document ownership.
|
||||
|
||||
Editable documents may have session-local editorial snapshots while the project session remains open.
|
||||
Those snapshots are editorial only and must not be treated as canonical build input by implication.
|
||||
|
||||
Persisting that state across Studio executions is deferred.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- merge/conflict resolution
|
||||
- watcher-driven automatic refresh
|
||||
- public `prometeu-vfs` event APIs
|
||||
- helper panel functionality
|
||||
- editor-owned semantic analysis that bypasses the integrated LSP phase
|
||||
- frontend editing
|
||||
- completion, rename, code actions, or formatting
|
||||
- a normative editor event contract in this wave
|
||||
- any implication that editor-owned in-memory snapshots participate in the build
|
||||
- host-owned semantic inline hint policy
|
||||
|
||||
## Exit Criteria
|
||||
|
||||
This specification is complete enough when:
|
||||
|
||||
- the controlled write-wave scope is unambiguous,
|
||||
- the `Project Navigator` and tab responsibilities are explicit,
|
||||
- editor-local `Save` and `Save All` are part of the normative workspace contract,
|
||||
- hard frontend `read-only` behavior is explicit in both warning and status-bar surfaces,
|
||||
- the workspace boundary with the integrated frontend semantic-read phase is explicit,
|
||||
- placeholder versus functional regions are clearly separated,
|
||||
- and excluded frontend editing and completion behavior are clearly outside the current contract.
|
||||
@ -1,235 +0,0 @@
|
||||
# Project Document VFS Specification
|
||||
|
||||
## Status
|
||||
|
||||
Active
|
||||
|
||||
## Applies To
|
||||
|
||||
- `prometeu-vfs`
|
||||
- `prometeu-studio`
|
||||
- the Studio project-document boundary for the first controlled Code Editor write wave
|
||||
|
||||
## Purpose
|
||||
|
||||
Define the normative Studio contract for `prometeu-vfs` as the project-document boundary consumed by Studio workspaces.
|
||||
|
||||
This specification stabilizes:
|
||||
|
||||
- `prometeu-vfs` module role,
|
||||
- project-session ownership,
|
||||
- the filesystem-backed first-wave contract,
|
||||
- structural tree and document access responsibilities,
|
||||
- canonical frontend scope and access policy ownership,
|
||||
- editorial snapshot and save ownership for editable supported documents including frontend sources,
|
||||
- the semantic-read consumer boundary used by the integrated LSP phase,
|
||||
- the RPC-first public API baseline,
|
||||
- and explicit first-wave exclusions such as public event publication and watchers.
|
||||
|
||||
## Authority and Precedence
|
||||
|
||||
This specification extends:
|
||||
|
||||
- [`1. Studio Shell and Workspace Layout Specification.md`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md)
|
||||
- [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md)
|
||||
|
||||
If this document conflicts with shell-wide Studio rules, the shell specification controls shell-wide behavior and this document controls the project-document boundary contract.
|
||||
|
||||
## Normative Inputs
|
||||
|
||||
`prometeu-vfs` must assume:
|
||||
|
||||
- the current migration wave carries only the Code Editor capabilities that already exist today,
|
||||
- the initial backend is filesystem-backed,
|
||||
- the boundary is project-scoped rather than product-global,
|
||||
- the boundary must outlive workspace focus changes for an opened project,
|
||||
- Studio UI remains the owner of visual tree state and error presentation,
|
||||
- and the integrated `prometeu-lsp` phase consumes this boundary as a semantic-read client rather than as a persistence owner.
|
||||
|
||||
`prometeu-vfs` must not infer:
|
||||
|
||||
- watcher-driven refresh in this wave,
|
||||
- public event API exposure in this wave,
|
||||
- build participation for editorial snapshots by implication,
|
||||
- or ownership over non-Studio domains such as packer assets.
|
||||
|
||||
## Module Role
|
||||
|
||||
`prometeu-vfs` is:
|
||||
|
||||
- the Studio project-document boundary,
|
||||
- the owner of project structural tree data for the covered scope,
|
||||
- the owner of project document resolution for the covered scope,
|
||||
- the owner of file support and unsupported-file classification for the covered scope,
|
||||
- the owner of document access policy for the covered scope,
|
||||
- the owner of save persistence for editable documents in this wave,
|
||||
- and the required path through which Studio accesses project-document filesystem state in this wave.
|
||||
|
||||
`prometeu-vfs` is not:
|
||||
|
||||
- a visual tree control,
|
||||
- a Studio shell replacement,
|
||||
- a product-wide universal filesystem layer,
|
||||
- or a public event transport in this wave.
|
||||
|
||||
## Project Session Ownership
|
||||
|
||||
The primary `prometeu-vfs` instance must belong to the Studio project session.
|
||||
|
||||
Rules:
|
||||
|
||||
- a project-scoped `prometeu-vfs` instance must be created when a Studio project session is opened;
|
||||
- that instance must remain alive while the project session remains open;
|
||||
- switching workspace focus must not destroy or recreate the project-document state by default;
|
||||
- the `Code Editor` workspace must consume the session-owned `prometeu-vfs` instance rather than owning the boundary lifecycle itself;
|
||||
- the project-session scope must cover only the opened project.
|
||||
|
||||
## Filesystem Access Rules
|
||||
|
||||
For the scope covered by this specification, Studio must access the project filesystem through `prometeu-vfs`.
|
||||
|
||||
Rules:
|
||||
|
||||
- the first implementation must be filesystem-backed;
|
||||
- direct filesystem reads for project tree and document loading must not remain a workspace-owned responsibility in the Code Editor;
|
||||
- this rule does not grant `prometeu-vfs` ownership over unrelated domains or unrelated filesystem responsibilities elsewhere in the product.
|
||||
|
||||
## Structural Tree Contract
|
||||
|
||||
`prometeu-vfs` must expose a structural representation of the project tree.
|
||||
|
||||
Rules:
|
||||
|
||||
- the structural tree must cover project content only;
|
||||
- the structural tree must contain structural and documentary data only;
|
||||
- the structural tree must not contain visual presentation state;
|
||||
- the structural tree must not contain navigator chrome decisions;
|
||||
- the structural tree may include structural metadata useful to Studio consumers;
|
||||
- consumers may request narrower refreshes than a full-tree reload when the request remains within the project boundary.
|
||||
|
||||
The following concerns remain outside `prometeu-vfs`:
|
||||
|
||||
- visual expansion state,
|
||||
- selection state,
|
||||
- focus state,
|
||||
- reveal or scroll behavior,
|
||||
- icon choice,
|
||||
- and other view-model concerns of the navigator UI.
|
||||
|
||||
## Document Access Contract
|
||||
|
||||
`prometeu-vfs` must own document resolution for the covered Studio scope.
|
||||
|
||||
Rules:
|
||||
|
||||
- opening a supported file in the Code Editor must go through `prometeu-vfs`;
|
||||
- the returned document content must describe only project-session document state for the opened project;
|
||||
- `prometeu-vfs` must classify each supported document as at least editable or hard `read-only`;
|
||||
- unsupported documents must remain distinguishable from supported `read-only` and supported editable documents;
|
||||
- `prometeu-vfs` must own editable in-memory editorial snapshots for the current Studio session;
|
||||
- save operations for editable documents in this wave must persist those editorial snapshots to disk through `prometeu-vfs`;
|
||||
- Studio consumers must treat `prometeu-vfs` access policy as canonical rather than rederiving editability locally;
|
||||
- and editorial snapshots must remain outside build-facing document state.
|
||||
|
||||
## Frontend Scope Contract
|
||||
|
||||
Frontend scope must be decided canonically inside `prometeu-vfs`.
|
||||
|
||||
Rules:
|
||||
|
||||
- `FrontendSpec.allowedExtensions` is the source of truth for frontend scope in this wave;
|
||||
- the VFS document contract must expose a canonical frontend-compatible `typeId` or equivalent scope marker derived from that source of truth;
|
||||
- consumers must not infer frontend scope from raw dynamic language identifiers, path heuristics, or local UI extension checks;
|
||||
- frontend-scoped supported documents must be editable in this wave when they are supported by the current frontend;
|
||||
- the initial editable set is limited to the currently supported textual classes represented as `text`, `json`, `ndjson`, `bash`, and supported frontend source documents resolved from `FrontendSpec.allowedExtensions`;
|
||||
- and no additional editable class may be inferred by implementation convenience during this wave.
|
||||
|
||||
## Document Access Context
|
||||
|
||||
`prometeu-vfs` must reserve a single access-context entity for document-access-related values.
|
||||
|
||||
Rules:
|
||||
|
||||
- the access-context entity may remain session-local in this wave;
|
||||
- it must already support lookup and mutation under current demand;
|
||||
- future persistence may be added later without redesigning the access model;
|
||||
- and the current reservation must not be treated as authorization for build participation or broader product-wide state ownership.
|
||||
|
||||
## Semantic-Read Consumer Boundary
|
||||
|
||||
`prometeu-vfs` must remain the source-of-truth document substrate consumed by the integrated LSP semantic-read phase.
|
||||
|
||||
Rules:
|
||||
|
||||
- opened frontend documents must be exposed to `prometeu-lsp` from the in-memory editorial snapshot held by `prometeu-vfs`, including dirty snapshots not yet saved to disk;
|
||||
- unopened frontend documents may be exposed to `prometeu-lsp` from filesystem-backed state through the same boundary;
|
||||
- `prometeu-lsp` must not bypass `prometeu-vfs` with ad hoc filesystem reads inside Studio UI code;
|
||||
- `prometeu-lsp` must not become the owner of save, persistence, or access policy;
|
||||
- semantic analysis over editorial snapshots must remain separate from build-facing document ownership;
|
||||
- and this boundary must remain suitable for frontend diagnostics, symbols, definition, and highlight without implying frontend edit rights.
|
||||
|
||||
## Support and Plugin Rules
|
||||
|
||||
Support and unsupported-file decisions belong to `prometeu-vfs`.
|
||||
|
||||
Rules:
|
||||
|
||||
- file support classification must be decided inside `prometeu-vfs`;
|
||||
- plugin or handler resolution for supported file access must be decided inside `prometeu-vfs`;
|
||||
- Studio UI may render the resulting success or failure state, but it must not own the classification rule itself.
|
||||
|
||||
## Communication Model
|
||||
|
||||
The official first-wave `prometeu-vfs` API is RPC-oriented.
|
||||
|
||||
Rules:
|
||||
|
||||
- commands and queries are the public API baseline for this wave;
|
||||
- internal runtime events may exist inside `prometeu-vfs`;
|
||||
- those events must remain internal in this wave;
|
||||
- internal events must not be promoted to public API by inference during planning or implementation.
|
||||
|
||||
## Refresh and Watchers
|
||||
|
||||
Refresh remains manual in this wave.
|
||||
|
||||
Rules:
|
||||
|
||||
- Studio consumers may request manual refresh through `prometeu-vfs`;
|
||||
- watcher-driven automatic refresh is deferred;
|
||||
- file watching must not be introduced implicitly while implementing this specification.
|
||||
|
||||
## Cross-Domain Boundary
|
||||
|
||||
`prometeu-vfs` belongs to the Studio domain.
|
||||
|
||||
Rules:
|
||||
|
||||
- `prometeu-vfs` serves `prometeu-lsp` as a consumer-facing substrate for the semantic-read phase;
|
||||
- `prometeu-lsp` remains a separate layer and must not be renamed into `prometeu-vfs`;
|
||||
- `prometeu-vfs` must not absorb packer responsibilities;
|
||||
- `prometeu-vfs` must not redefine asset ownership;
|
||||
- extending this boundary outside project-document concerns requires a new decision.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- public event publication
|
||||
- watcher-driven refresh
|
||||
- dirty tracking
|
||||
- merge or conflict handling
|
||||
- non-project content snapshots
|
||||
- a generic product-wide filesystem abstraction
|
||||
- treating editorial snapshots as canonical build input
|
||||
|
||||
## Exit Criteria
|
||||
|
||||
This specification is complete enough when:
|
||||
|
||||
- `prometeu-vfs` ownership is clearly separated from shell and workspace UI ownership,
|
||||
- the project-session lifecycle rule is unambiguous,
|
||||
- the structural tree contract is explicitly non-visual,
|
||||
- frontend scope and access policy ownership are explicit,
|
||||
- editable supported-document snapshot and save ownership are explicit,
|
||||
- the semantic-read consumer boundary with `prometeu-lsp` is explicit,
|
||||
- the RPC-first public API rule is explicit,
|
||||
- and deferred public events and watchers are clearly out of scope.
|
||||
@ -1,183 +0,0 @@
|
||||
# Integrated LSP Semantic Read Phase Specification
|
||||
|
||||
## Status
|
||||
|
||||
Active
|
||||
|
||||
## Applies To
|
||||
|
||||
- `prometeu-studio`
|
||||
- `prometeu-vfs`
|
||||
- `prometeu-lsp`
|
||||
- the integrated frontend semantic phase in the Studio `Code Editor` workspace
|
||||
|
||||
## Purpose
|
||||
|
||||
Define the normative Studio contract for the integrated frontend semantic-read phase that arrives before any frontend editing release.
|
||||
|
||||
This specification stabilizes:
|
||||
|
||||
- the phase boundary between semantic ownership and frontend editing ownership,
|
||||
- the ownership relationship between `prometeu-vfs`, `prometeu-lsp`, and the Studio editor,
|
||||
- the minimum semantic capability set for frontend documents,
|
||||
- the dedicated semantic surface used for structural anchors and guide-aware editor structure,
|
||||
- the packaging expectations for the public `prometeu-lsp` API surface,
|
||||
- and the explicit exclusions that remain outside this phase.
|
||||
|
||||
## Authority and Precedence
|
||||
|
||||
This specification extends:
|
||||
|
||||
- [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md)
|
||||
- [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md)
|
||||
|
||||
If this document conflicts with shell-wide Studio rules, shell rules control shell behavior, the Code Editor specification controls workspace-local editor UX, the VFS specification controls document-boundary ownership, and this document controls the integrated semantic-read phase itself.
|
||||
|
||||
## Normative Inputs
|
||||
|
||||
The integrated semantic-read phase must assume:
|
||||
|
||||
- frontend-scoped documents may be editable under the controlled write wave exposed by `prometeu-vfs`,
|
||||
- editable supported documents remain governed by the controlled write wave,
|
||||
- `FrontendSpec.allowedExtensions` remains the source of truth for frontend scope,
|
||||
- `FrontendSpec` is the canonical source of frontend semantic presentation contract data,
|
||||
- `prometeu-vfs` owns document state, snapshots, persistence, and access policy,
|
||||
- and semantic-read over editorial snapshots must remain separate from build-facing ownership.
|
||||
|
||||
## Phase Boundary
|
||||
|
||||
This phase is a semantic phase for frontend documents, not an ownership phase for frontend editing.
|
||||
|
||||
Rules:
|
||||
|
||||
- no capability in this phase may override `prometeu-vfs` access policy, save policy, or snapshot ownership;
|
||||
- completion, rename, code actions, and formatting remain outside this phase.
|
||||
|
||||
## Ownership Rules
|
||||
|
||||
- `prometeu-vfs` owns document state, access policy, editorial snapshots, and persistence.
|
||||
- `prometeu-lsp` is a semantic consumer above `prometeu-vfs`.
|
||||
- the Studio `Code Editor` owns UX surfaces that render semantic-read output.
|
||||
- each frontend owns its semantic vocabulary and semantic presentation resources.
|
||||
- build-facing document ownership remains outside this phase.
|
||||
|
||||
`prometeu-lsp` must not become the owner of:
|
||||
|
||||
- save,
|
||||
- persistence,
|
||||
- document access policy,
|
||||
- frontend semantic presentation assets,
|
||||
- or frontend edit-right release.
|
||||
|
||||
## Document Source-of-Truth Rules
|
||||
|
||||
- opened frontend documents must be analyzed from the in-memory snapshot exposed by `prometeu-vfs`;
|
||||
- unopened frontend documents may be analyzed from filesystem-backed state exposed through the same `prometeu-vfs` boundary;
|
||||
- Studio UI code must not bypass `prometeu-vfs` with ad hoc file loading for semantic-read behavior;
|
||||
- semantic-read over editorial snapshots must not be treated as canonical build input by implication.
|
||||
|
||||
## Minimum Capability Set
|
||||
|
||||
The minimum semantic capability set of this phase must include:
|
||||
|
||||
- diagnostics for frontend documents;
|
||||
- document symbols for frontend documents;
|
||||
- workspace symbols for frontend documents;
|
||||
- outline-facing structural symbol data;
|
||||
- go-to-definition for frontend documents;
|
||||
- frontend semantic highlight.
|
||||
|
||||
The phase may ship the dedicated structural-anchor surface after the baseline capability set is stable, but Studio and frontend implementations must treat that surface as the canonical source of exact scope-indicator anchoring once it exists.
|
||||
|
||||
The phase may also ship a dedicated inline-hint semantic surface.
|
||||
|
||||
Once shipped, frontend and Studio implementations must treat that surface as the canonical source of decorative inline hint payloads.
|
||||
|
||||
## Highlight Ownership Rules
|
||||
|
||||
- frontend highlight must come from semantic information provided through `prometeu-lsp`;
|
||||
- frontend highlight must use frontend-owned semantic presentation contract data derived from `FrontendSpec`;
|
||||
- `prometeu-lsp` must expose a dedicated semantic presentation descriptor derived from the resolved `FrontendSpec`;
|
||||
- that descriptor must remain simple and include frontend-owned `semanticKeys` plus frontend-owned `resources` in the same message surface;
|
||||
- `prometeu-lsp` must not collapse frontend semantic keys into host-owned generic categories;
|
||||
- Studio must project semantic keys mechanically to CSS classes without semantic translation;
|
||||
- frontend semantic presentation resources must remain under frontend `resources/` and be resolved like ordinary Java resources;
|
||||
- when semantic presentation descriptor data or usable resources are absent, Studio must continue without semantic highlight;
|
||||
- this condition must not become a product-facing Studio error and may at most produce normal development logs;
|
||||
- non-frontend highlight may remain on the existing Studio-local highlighting path in this phase.
|
||||
|
||||
## Inline Hint Ownership Rules
|
||||
|
||||
- frontend inline hints must come from semantic information provided through `prometeu-lsp`;
|
||||
- frontend hint existence and hint payload semantics remain frontend-owned;
|
||||
- `prometeu-lsp` must expose a dedicated transport contract for inline hints rather than relying on Studio-local inference;
|
||||
- `prometeu-lsp` must preserve deterministic anchor information required for host rendering;
|
||||
- `prometeu-lsp` must not invent host-owned hint policy when a frontend does not publish hints;
|
||||
- Studio must render transported hints mechanically as host decorations rather than as document text;
|
||||
- valid inline hint spans must survive partial degradation when the frontend can still produce them;
|
||||
- invalid or missing hint spans may be omitted locally;
|
||||
- Studio must not disable all inline hints for a document solely because some hint spans are unavailable.
|
||||
|
||||
## Structural Anchor Semantic Surface
|
||||
|
||||
Exact structural anchoring for editor scope indicators must not be overloaded into `documentSymbols`.
|
||||
|
||||
`documentSymbols` remains the outline and navigation surface.
|
||||
|
||||
Guide-oriented structure must be exposed through a dedicated semantic surface for structural anchors and related guide metadata.
|
||||
|
||||
That dedicated surface must be frontend-owned and language-agnostic.
|
||||
|
||||
The contract must describe generic structural positions rather than PBS-specific brace semantics.
|
||||
|
||||
The surface must be able to represent structures whose boundaries are expressed by:
|
||||
|
||||
- braces;
|
||||
- keywords;
|
||||
- indentation-derived blocks;
|
||||
- or mixed delimiter schemes.
|
||||
|
||||
At minimum, the dedicated structural-anchor surface must be able to communicate:
|
||||
|
||||
- structural ranges that can participate in active-scope selection;
|
||||
- immediate parentage or equivalent information needed to recover the nearest ancestor relationship;
|
||||
- exact structural anchor positions used for guide start and end placement;
|
||||
- enough structural identity to distinguish the active structural range from its immediate container.
|
||||
|
||||
The semantic-read contract must not require Studio to scan source text in order to discover the final structural anchor positions.
|
||||
|
||||
Temporary local heuristics may exist only as development aids. They must not become the canonical production contract.
|
||||
|
||||
The exact serialized schema of this dedicated surface may evolve in implementation plans, but any accepted schema must preserve the invariants above.
|
||||
|
||||
## Packaging Rules
|
||||
|
||||
The public `prometeu-lsp` API should follow flat packaging similar to `prometeu-packer-api`.
|
||||
|
||||
Rules:
|
||||
|
||||
- public contract surfaces should remain shallow and explicit;
|
||||
- packages such as `dtos`, `messages`, and `events` are the preferred shape for public API grouping where those surfaces exist;
|
||||
- deep public packaging by internal implementation concern should be avoided;
|
||||
- runtime or implementation layering may exist internally, but it must not leak into the public contract surface by default.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- frontend save policy
|
||||
- completion
|
||||
- rename
|
||||
- code actions
|
||||
- formatting
|
||||
- build participation inferred from editorial snapshots
|
||||
- external-editor compatibility requirements
|
||||
- Studio-owned semantic hint generation
|
||||
|
||||
## Exit Criteria
|
||||
|
||||
This specification is complete enough when:
|
||||
|
||||
- the semantic-read versus frontend-editing phase boundary is explicit,
|
||||
- `prometeu-vfs` and `prometeu-lsp` ownership remains unambiguous,
|
||||
- the minimum semantic capability set is explicit,
|
||||
- frontend and non-frontend highlight ownership is clearly separated,
|
||||
- and the excluded editing and completion capabilities remain unambiguous.
|
||||
@ -22,7 +22,6 @@ This specification implements the accepted decision for project-local Studio sta
|
||||
It extends:
|
||||
|
||||
- [`1. Studio Shell and Workspace Layout Specification.md`](1.%20Studio%20Shell%20and%20Workspace%20Layout%20Specification.md)
|
||||
- [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md)
|
||||
|
||||
## Core Rules
|
||||
|
||||
@ -31,7 +30,7 @@ It extends:
|
||||
3. The main session-restoration store MUST remain a single file at `.studio/state.json`.
|
||||
4. The main session-restoration store MUST be versioned.
|
||||
5. The main session-restoration store MUST load when the project session opens.
|
||||
6. Restorable shell and editor state accepted by this wave MUST restore when the project shell mounts.
|
||||
6. Restorable shell state accepted by this wave MUST restore when the project shell mounts.
|
||||
7. The main session-restoration store MUST save when the project shell or project session closes.
|
||||
8. Missing, invalid, or schema-incompatible session-restoration state MUST fall back to safe default values and MUST NOT block project open.
|
||||
9. Project-local setup configuration MUST live in a separate file at `.studio/setup.json`.
|
||||
@ -44,13 +43,11 @@ The main session-restoration store MUST include:
|
||||
|
||||
- `shellLayout`
|
||||
- `openShellState`
|
||||
- `editorRestoration`
|
||||
|
||||
Wave-1 accepted meaning is:
|
||||
|
||||
- `shellLayout`: restorable layout state already accepted by implementation, including divider positions and equivalent layout proportions for accepted workspaces such as `Assets` and `Code Editor`, `Project Navigator` expansion state, and editor dock-panel open/closed plus restored-size configuration;
|
||||
- `shellLayout`: restorable layout state already accepted by implementation, including divider positions and equivalent layout proportions for accepted workspaces such as `Assets`;
|
||||
- `openShellState`: which workspace or equivalent shell-owned project view was open;
|
||||
- `editorRestoration`: open editor tabs and active tab.
|
||||
|
||||
## Project-Local Setup Configuration
|
||||
|
||||
@ -61,8 +58,8 @@ Rules:
|
||||
- project-local setup MUST live in `.studio/setup.json`;
|
||||
- project-local setup MUST be treated as project configuration rather than session state;
|
||||
- project-local setup MAY contain runtime-oriented values such as the Prometeu runtime path;
|
||||
- project-local setup MUST own the project-wide editor indentation policy;
|
||||
- the editor indentation policy MUST define at least indentation mode and indentation width;
|
||||
- project-local setup MAY continue carrying project-wide indentation policy defaults for future code-tooling integrations;
|
||||
- the indentation policy MUST define at least indentation mode and indentation width;
|
||||
- when setup does not provide an explicit indentation policy, consumers MUST resolve it to `spaces` with width `4`;
|
||||
- project-local setup MAY grow with additional manual or automatic configuration keys over time;
|
||||
- consumers such as `Play` MUST read project-local setup from the dedicated setup file rather than from `.studio/state.json`;
|
||||
|
||||
@ -54,10 +54,7 @@ The current Studio core corpus is:
|
||||
2. [`2. Studio UI Foundations Specification.md`](2.%20Studio%20UI%20Foundations%20Specification.md)
|
||||
3. [`3. Studio Components Module Specification.md`](3.%20Studio%20Components%20Module%20Specification.md)
|
||||
4. [`4. Assets Workspace Specification.md`](4.%20Assets%20Workspace%20Specification.md)
|
||||
5. [`5. Code Editor Workspace Specification.md`](5.%20Code%20Editor%20Workspace%20Specification.md)
|
||||
6. [`6. Project Document VFS Specification.md`](6.%20Project%20Document%20VFS%20Specification.md)
|
||||
7. [`7. Integrated LSP Semantic Read Phase Specification.md`](7.%20Integrated%20LSP%20Semantic%20Read%20Phase%20Specification.md)
|
||||
8. [`8. Project-Local Studio State Specification.md`](8.%20Project-Local%20Studio%20State%20Specification.md)
|
||||
5. [`8. Project-Local Studio State Specification.md`](8.%20Project-Local%20Studio%20State%20Specification.md)
|
||||
|
||||
## Reading Order
|
||||
|
||||
@ -67,19 +64,14 @@ Recommended order:
|
||||
2. shared UI foundations;
|
||||
3. components module policy;
|
||||
4. assets workspace behavior;
|
||||
5. project document VFS boundary;
|
||||
6. code editor workspace behavior;
|
||||
7. integrated LSP semantic-read behavior;
|
||||
8. project-local Studio state behavior.
|
||||
5. project-local Studio state behavior.
|
||||
|
||||
## Current Wave Notes
|
||||
|
||||
The current `Code Editor` wave is not globally read-only anymore.
|
||||
The embedded Studio code-editor stack was removed by `DEC-0031`.
|
||||
|
||||
Normative reminders:
|
||||
|
||||
- editable scope is limited to supported non-frontend textual documents classified by `prometeu-vfs`;
|
||||
- frontend-scoped supported documents remain hard `read-only`;
|
||||
- the editor-local `Save` and `Save All` surfaces belong to the `Code Editor` workspace rather than the shell;
|
||||
- editorial in-memory snapshots remain outside build-facing state;
|
||||
- frontend semantic-read capability lands before any frontend editing release and is documented by the integrated LSP phase specification.
|
||||
- the active Studio workspace corpus is `Assets`, `Debug`, and `Shipper`;
|
||||
- project-local Studio session state remains normative and is owned by `StudioProjectSession`;
|
||||
- any future external-editor backend or replacement language-service architecture requires a new accepted decision before new Studio specs are introduced.
|
||||
|
||||
@ -78,38 +78,6 @@ public enum I18n {
|
||||
TOOLBAR_STOP("toolbar.stop"),
|
||||
TOOLBAR_EXPORT("toolbar.export"),
|
||||
|
||||
WORKSPACE_CODE("workspace.code"),
|
||||
CODE_EDITOR_NAVIGATOR_TITLE("codeEditor.navigator.title"),
|
||||
CODE_EDITOR_NAVIGATOR_REFRESH("codeEditor.navigator.refresh"),
|
||||
CODE_EDITOR_NAVIGATOR_REVEAL_ACTIVE("codeEditor.navigator.revealActive"),
|
||||
CODE_EDITOR_NAVIGATOR_PLACEHOLDER("codeEditor.navigator.placeholder"),
|
||||
CODE_EDITOR_NAVIGATOR_DETAIL("codeEditor.navigator.detail"),
|
||||
CODE_EDITOR_OUTLINE_TITLE("codeEditor.outline.title"),
|
||||
CODE_EDITOR_OUTLINE_PLACEHOLDER("codeEditor.outline.placeholder"),
|
||||
CODE_EDITOR_OUTLINE_SYMBOLS("codeEditor.outline.symbols"),
|
||||
CODE_EDITOR_OUTLINE_EMPTY_SYMBOLS("codeEditor.outline.emptySymbols"),
|
||||
CODE_EDITOR_HELPER_TITLE("codeEditor.helper.title"),
|
||||
CODE_EDITOR_HELPER_PLACEHOLDER("codeEditor.helper.placeholder"),
|
||||
CODE_EDITOR_HELPER_DIAGNOSTICS("codeEditor.helper.diagnostics"),
|
||||
CODE_EDITOR_HELPER_EMPTY_DIAGNOSTICS("codeEditor.helper.emptyDiagnostics"),
|
||||
CODE_EDITOR_TABS_PLACEHOLDER("codeEditor.tabs.placeholder"),
|
||||
CODE_EDITOR_TABS_OVERFLOW("codeEditor.tabs.overflow"),
|
||||
CODE_EDITOR_STATUS_BREADCRUMB("codeEditor.status.breadcrumb"),
|
||||
CODE_EDITOR_STATUS_POSITION("codeEditor.status.position"),
|
||||
CODE_EDITOR_STATUS_LINE_SEPARATOR("codeEditor.status.lineSeparator"),
|
||||
CODE_EDITOR_STATUS_INDENTATION("codeEditor.status.indentation"),
|
||||
CODE_EDITOR_STATUS_LANGUAGE("codeEditor.status.language"),
|
||||
CODE_EDITOR_COMMAND_SAVE("codeEditor.command.save"),
|
||||
CODE_EDITOR_COMMAND_SAVE_ALL("codeEditor.command.saveAll"),
|
||||
CODE_EDITOR_CLOSE_DIRTY_TITLE("codeEditor.closeDirty.title"),
|
||||
CODE_EDITOR_CLOSE_DIRTY_MESSAGE("codeEditor.closeDirty.message"),
|
||||
CODE_EDITOR_CLOSE_DIRTY_SAVE("codeEditor.closeDirty.save"),
|
||||
CODE_EDITOR_CLOSE_DIRTY_DISCARD("codeEditor.closeDirty.discard"),
|
||||
CODE_EDITOR_CLOSE_DIRTY_CANCEL("codeEditor.closeDirty.cancel"),
|
||||
CODE_EDITOR_WARNING_FRONTEND_READ_ONLY("codeEditor.warning.frontendReadOnly"),
|
||||
CODE_EDITOR_UNSUPPORTED_FILE_TITLE("codeEditor.unsupportedFile.title"),
|
||||
CODE_EDITOR_UNSUPPORTED_FILE_MESSAGE("codeEditor.unsupportedFile.message"),
|
||||
|
||||
WORKSPACE_SHIPPER("workspace.shipper"),
|
||||
WORKSPACE_SHIPPER_LOGS("workspace.shipper.logs"),
|
||||
WORKSPACE_SHIPPER_BUTTON_RUN("workspace.shipper.button.run"),
|
||||
|
||||
@ -3,7 +3,7 @@ app.projectTitle=Prometeu Studio - {0}
|
||||
shield.loadingProject=Loading project {0}...
|
||||
shield.version=Version {0}
|
||||
shield.status.indexing=Indexing sources and restoring services...
|
||||
shield.status.restoring=Restoring workspace surfaces and editor state...
|
||||
shield.status.restoring=Restoring workspace surfaces and project state...
|
||||
shield.phase.indexing=Indexing
|
||||
shield.phase.preparing=Preparing UI
|
||||
shield.phase.restoring=Restoring State
|
||||
@ -69,37 +69,6 @@ wizard.error.indentationRequired=Indentation width must be selected.
|
||||
toolbar.play=Play
|
||||
toolbar.stop=Stop
|
||||
toolbar.export=Export
|
||||
workspace.code=Code
|
||||
codeEditor.navigator.title=Project Navigator
|
||||
codeEditor.navigator.refresh=Refresh
|
||||
codeEditor.navigator.revealActive=Reveal active file
|
||||
codeEditor.navigator.placeholder=Project navigation lands in the next implementation slice.
|
||||
codeEditor.navigator.detail=This first shell reserves the full navigator surface, its refresh action, and the left-column composition without wiring project-tree data yet.
|
||||
codeEditor.outline.title=Outline
|
||||
codeEditor.outline.placeholder=Open a frontend document to inspect semantic symbols.
|
||||
codeEditor.outline.symbols=Symbols
|
||||
codeEditor.outline.emptySymbols=No semantic symbols are currently available for the active frontend document.
|
||||
codeEditor.helper.title=Editor Helper
|
||||
codeEditor.helper.placeholder=Open a frontend document to inspect semantic diagnostics.
|
||||
codeEditor.helper.diagnostics=Diagnostics
|
||||
codeEditor.helper.emptyDiagnostics=No diagnostics for the active frontend document.
|
||||
codeEditor.tabs.placeholder=no-file-open.txt
|
||||
codeEditor.tabs.overflow=More
|
||||
codeEditor.status.breadcrumb=proj > src > file.pbs
|
||||
codeEditor.status.position=L:C
|
||||
codeEditor.status.lineSeparator=LF
|
||||
codeEditor.status.indentation=Spaces: 4
|
||||
codeEditor.status.language=Text
|
||||
codeEditor.command.save=Save
|
||||
codeEditor.command.saveAll=Save All
|
||||
codeEditor.closeDirty.title=Unsaved changes
|
||||
codeEditor.closeDirty.message=Save changes to {0} before closing?
|
||||
codeEditor.closeDirty.save=Save
|
||||
codeEditor.closeDirty.discard=Discard
|
||||
codeEditor.closeDirty.cancel=Cancel
|
||||
codeEditor.warning.frontendReadOnly=This frontend file is read-only in this wave. It cannot be edited or saved yet.
|
||||
codeEditor.unsupportedFile.title=Unsupported file
|
||||
codeEditor.unsupportedFile.message=This file is not supported in this wave: {0}
|
||||
workspace.shipper=Shipper
|
||||
workspace.shipper.logs=Logs
|
||||
workspace.shipper.button.run=Build
|
||||
|
||||
@ -12,7 +12,6 @@ toolbar.play=Executar
|
||||
toolbar.stop=Parar
|
||||
toolbar.export=Exportar
|
||||
|
||||
workspace.code=Código
|
||||
workspace.shipper=Empacotador
|
||||
workspace.shipper.logs=Logs
|
||||
workspace.shipper.button.run=Construir
|
||||
|
||||
@ -352,24 +352,6 @@
|
||||
-fx-background-color: #17191d;
|
||||
}
|
||||
|
||||
.editor-workspace {
|
||||
-fx-background-color: #15181d;
|
||||
}
|
||||
|
||||
.editor-workspace-layout {
|
||||
-fx-padding: 16;
|
||||
-fx-background-color: #15181d;
|
||||
}
|
||||
|
||||
.editor-workspace-split {
|
||||
-fx-background-color: transparent;
|
||||
}
|
||||
|
||||
.editor-workspace-split > .split-pane-divider {
|
||||
-fx-background-color: transparent;
|
||||
-fx-padding: 0 8 0 8;
|
||||
}
|
||||
|
||||
.workspace-dock-split {
|
||||
-fx-background-color: transparent;
|
||||
}
|
||||
@ -386,544 +368,6 @@
|
||||
-fx-padding: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-left-column,
|
||||
.editor-workspace-center-column {
|
||||
-fx-spacing: 12;
|
||||
}
|
||||
|
||||
.editor-workspace-panel {
|
||||
-fx-background-color: #1b1f25;
|
||||
-fx-background-radius: 12;
|
||||
-fx-border-radius: 12;
|
||||
-fx-border-color: #2a313c;
|
||||
}
|
||||
|
||||
.editor-workspace-panel-header {
|
||||
-fx-alignment: center-left;
|
||||
}
|
||||
|
||||
.editor-workspace-header-icon-button {
|
||||
-fx-background-color: transparent;
|
||||
-fx-border-color: transparent;
|
||||
-fx-background-radius: 4;
|
||||
-fx-border-radius: 4;
|
||||
-fx-padding: 6;
|
||||
}
|
||||
|
||||
.editor-workspace-header-icon-button:hover {
|
||||
-fx-background-color: #243243;
|
||||
-fx-border-color: #556f8b;
|
||||
}
|
||||
|
||||
.editor-workspace-panel-content {
|
||||
-fx-padding: 6 0 0 0;
|
||||
}
|
||||
|
||||
.editor-workspace-panel-title {
|
||||
-fx-text-fill: #eff5fb;
|
||||
-fx-font-size: 14px;
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-placeholder {
|
||||
-fx-text-fill: #c3cfdb;
|
||||
-fx-font-size: 12px;
|
||||
}
|
||||
|
||||
.editor-workspace-placeholder-detail {
|
||||
-fx-text-fill: #8896a7;
|
||||
-fx-font-size: 11px;
|
||||
}
|
||||
|
||||
.editor-workspace-navigator-panel {
|
||||
-fx-min-height: 320px;
|
||||
}
|
||||
|
||||
.editor-workspace-tree {
|
||||
-fx-background-color: transparent;
|
||||
-fx-border-color: transparent;
|
||||
}
|
||||
|
||||
.editor-workspace-tree .tree-cell {
|
||||
-fx-background-color: transparent;
|
||||
-fx-text-fill: #d6e0ea;
|
||||
-fx-font-size: 14px;
|
||||
-fx-padding: 4 6 4 4;
|
||||
}
|
||||
|
||||
.editor-workspace-tree .tree-cell:selected {
|
||||
-fx-background-color: #24415e;
|
||||
-fx-text-fill: #ffffff;
|
||||
}
|
||||
|
||||
.editor-workspace-tree .tree-disclosure-node {
|
||||
-fx-padding: 0 4 0 0;
|
||||
}
|
||||
|
||||
.editor-workspace-tree .tree-disclosure-node .arrow {
|
||||
-fx-background-color: #8ea4ba;
|
||||
}
|
||||
|
||||
.editor-workspace-tree .tree-cell:selected .tree-disclosure-node .arrow {
|
||||
-fx-background-color: #e8f3ff;
|
||||
}
|
||||
|
||||
.editor-workspace-tree-cell-tagged {
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-tree-cell-root {
|
||||
-fx-font-weight: bold;
|
||||
-fx-text-fill: #f4f8fc;
|
||||
}
|
||||
|
||||
.editor-workspace-icon {
|
||||
-fx-min-width: 14;
|
||||
-fx-min-height: 14;
|
||||
-fx-pref-width: 14;
|
||||
-fx-pref-height: 14;
|
||||
-fx-max-width: 14;
|
||||
-fx-max-height: 14;
|
||||
-fx-alignment: center;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-shape {
|
||||
-fx-scale-x: 0.88;
|
||||
-fx-scale-y: 0.88;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-folder-default {
|
||||
-fx-fill: #8792a1;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-folder-source {
|
||||
-fx-fill: #4ea0ef;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-folder-build {
|
||||
-fx-fill: #d88a3d;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-file {
|
||||
-fx-fill: #b0bac6;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-cog {
|
||||
-fx-fill: #c6d0da;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-refresh {
|
||||
-fx-fill: #eff5fb;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-target {
|
||||
-fx-fill: #eff5fb;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-lock-closed {
|
||||
-fx-fill: #f6d78f;
|
||||
}
|
||||
|
||||
.editor-workspace-icon-lock-open {
|
||||
-fx-fill: #bde7c7;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-panel {
|
||||
-fx-min-height: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-scroll {
|
||||
-fx-background-color: transparent;
|
||||
-fx-background-insets: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-scroll > .viewport {
|
||||
-fx-background-color: transparent;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-summary {
|
||||
-fx-text-fill: #dce6f0;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-section-title {
|
||||
-fx-font-size: 11px;
|
||||
-fx-font-weight: 700;
|
||||
-fx-text-fill: #8fb1d2;
|
||||
-fx-padding: 4 0 0 0;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-list {
|
||||
-fx-spacing: 6;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-item {
|
||||
-fx-text-fill: #d7e2ec;
|
||||
-fx-font-size: 12px;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-diagnostic-error {
|
||||
-fx-text-fill: #ff9a9a;
|
||||
}
|
||||
|
||||
.editor-workspace-outline-diagnostic-warning {
|
||||
-fx-text-fill: #f6d78f;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-strip {
|
||||
-fx-padding: 8 12 8 12;
|
||||
-fx-background-color: #1b1f25;
|
||||
-fx-background-radius: 0;
|
||||
-fx-border-radius: 0;
|
||||
-fx-border-color: #2a313c;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area {
|
||||
-fx-background-color: #171c22;
|
||||
-fx-font-size: 15px;
|
||||
-fx-highlight-fill: #26405c;
|
||||
-fx-highlight-text-fill: #eef4fb;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button {
|
||||
-fx-background-radius: 0;
|
||||
-fx-border-radius: 0;
|
||||
-fx-padding: 0 8 0 12;
|
||||
-fx-alignment: center-left;
|
||||
-fx-font-size: 12px;
|
||||
-fx-background-color: #20262f;
|
||||
-fx-border-color: #343f4d;
|
||||
-fx-border-width: 1;
|
||||
-fx-text-fill: #d6dde6;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-content {
|
||||
-fx-spacing: 8;
|
||||
-fx-alignment: center-left;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-label {
|
||||
-fx-alignment: center-left;
|
||||
-fx-font-size: 12px;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-dirty-indicator {
|
||||
-fx-background-color: #d9e3ef;
|
||||
-fx-background-radius: 999;
|
||||
-fx-border-radius: 999;
|
||||
-fx-opacity: 0.9;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-close-chip {
|
||||
-fx-alignment: center;
|
||||
-fx-background-color: #131820;
|
||||
-fx-background-radius: 999;
|
||||
-fx-border-color: #485667;
|
||||
-fx-border-radius: 999;
|
||||
-fx-border-width: 1;
|
||||
-fx-padding: 0;
|
||||
-fx-cursor: hand;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-close-icon {
|
||||
-fx-fill: transparent;
|
||||
-fx-stroke: #cfd8e2;
|
||||
-fx-stroke-width: 1.1;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active {
|
||||
-fx-background-color: #16283d;
|
||||
-fx-border-color: #8fc4f2 #516579 #516579 #516579;
|
||||
-fx-border-width: 3 1 1 1;
|
||||
-fx-text-fill: #ffffff;
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only {
|
||||
-fx-background-color: #252b34;
|
||||
-fx-border-color: #47515d;
|
||||
-fx-text-fill: #d9dee5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only .editor-workspace-tab-label {
|
||||
-fx-text-fill: #d9dee5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only .editor-workspace-tab-dirty-indicator {
|
||||
-fx-background-color: #d9dee5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only .editor-workspace-tab-close-icon {
|
||||
-fx-stroke: #d9dee5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only .editor-workspace-tab-close-chip {
|
||||
-fx-background-color: #171c23;
|
||||
-fx-border-color: #4f5b68;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover {
|
||||
-fx-background-color: #2b323d;
|
||||
-fx-border-color: #5b6878;
|
||||
-fx-text-fill: #eff4fa;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-label {
|
||||
-fx-text-fill: #eff4fa;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-dirty-indicator {
|
||||
-fx-background-color: #eff4fa;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip {
|
||||
-fx-background-color: #1c232c;
|
||||
-fx-border-color: #6b7989;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip:hover {
|
||||
-fx-background-color: #2a3440;
|
||||
-fx-border-color: #90a2b5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip:hover .editor-workspace-tab-close-icon {
|
||||
-fx-stroke: #f7fbff;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only:hover .editor-workspace-tab-close-chip:pressed {
|
||||
-fx-background-color: #364351;
|
||||
-fx-border-color: #a8bbce;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only.editor-workspace-tab-button-active {
|
||||
-fx-background-color: #16283d;
|
||||
-fx-border-color: #8fc4f2 #516579 #516579 #516579;
|
||||
-fx-border-width: 3 1 1 1;
|
||||
-fx-text-fill: #ffffff;
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-read-only.editor-workspace-tab-button-active:hover {
|
||||
-fx-background-color: #1c3148;
|
||||
-fx-border-color: #a7d7ff #5c738b #5c738b #5c738b;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable {
|
||||
-fx-background-color: #203226;
|
||||
-fx-border-color: #4d6f58;
|
||||
-fx-text-fill: #e8f6eb;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable .editor-workspace-tab-label {
|
||||
-fx-text-fill: #e8f6eb;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable .editor-workspace-tab-dirty-indicator {
|
||||
-fx-background-color: #b9f0c7;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable .editor-workspace-tab-close-icon {
|
||||
-fx-stroke: #e8f6eb;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable .editor-workspace-tab-close-chip {
|
||||
-fx-background-color: #15211a;
|
||||
-fx-border-color: #557363;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover {
|
||||
-fx-background-color: #29412f;
|
||||
-fx-border-color: #6f957a;
|
||||
-fx-text-fill: #f4fff5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover .editor-workspace-tab-label {
|
||||
-fx-text-fill: #f4fff5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover .editor-workspace-tab-dirty-indicator {
|
||||
-fx-background-color: #f4fff5;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip {
|
||||
-fx-background-color: #192720;
|
||||
-fx-border-color: #789886;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip:hover {
|
||||
-fx-background-color: #27382d;
|
||||
-fx-border-color: #9fc0ac;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip:hover .editor-workspace-tab-close-icon {
|
||||
-fx-stroke: #ffffff;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable:hover .editor-workspace-tab-close-chip:pressed {
|
||||
-fx-background-color: #314739;
|
||||
-fx-border-color: #b2d2bf;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable.editor-workspace-tab-button-active {
|
||||
-fx-background-color: #1d3a2a;
|
||||
-fx-border-color: #8ad3a2 #587464 #587464 #587464;
|
||||
-fx-border-width: 3 1 1 1;
|
||||
-fx-text-fill: #ffffff;
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active .editor-workspace-tab-label {
|
||||
-fx-text-fill: #ffffff;
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active .editor-workspace-tab-dirty-indicator {
|
||||
-fx-background-color: #ffffff;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active .editor-workspace-tab-close-icon {
|
||||
-fx-stroke: #ffffff;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active .editor-workspace-tab-close-chip {
|
||||
-fx-background-color: rgba(255, 255, 255, 0.08);
|
||||
-fx-border-color: rgba(255, 255, 255, 0.22);
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active:hover .editor-workspace-tab-close-chip:hover {
|
||||
-fx-background-color: rgba(255, 255, 255, 0.18);
|
||||
-fx-border-color: rgba(255, 255, 255, 0.42);
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-active:hover .editor-workspace-tab-close-chip:pressed {
|
||||
-fx-background-color: rgba(255, 255, 255, 0.28);
|
||||
-fx-border-color: rgba(255, 255, 255, 0.56);
|
||||
}
|
||||
|
||||
.editor-workspace-tab-button-editable.editor-workspace-tab-button-active:hover {
|
||||
-fx-background-color: #234532;
|
||||
-fx-border-color: #a5efbd #688676 #688676 #688676;
|
||||
}
|
||||
|
||||
|
||||
.editor-workspace-tab-overflow {
|
||||
-fx-background-radius: 0;
|
||||
-fx-border-radius: 0;
|
||||
-fx-padding: 0 12 0 12;
|
||||
-fx-min-width: 128;
|
||||
-fx-pref-width: 128;
|
||||
-fx-max-width: 128;
|
||||
-fx-min-height: 34;
|
||||
-fx-pref-height: 34;
|
||||
-fx-max-height: 34;
|
||||
}
|
||||
|
||||
.editor-workspace-tab-overflow-item {
|
||||
-fx-text-fill: #d9e2eb;
|
||||
-fx-font-size: 12px;
|
||||
-fx-padding: 0 10 0 10;
|
||||
-fx-background-color: transparent;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .content {
|
||||
-fx-background-color: #171c22;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .paragraph-box {
|
||||
-fx-background-color: #171c22;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .lineno {
|
||||
-fx-background-color: #12161c;
|
||||
-fx-text-fill: #6f7a86;
|
||||
-fx-padding: 0 12 0 12;
|
||||
-fx-font-family: "JetBrains Mono Medium", "JetBrains Mono", "Iosevka", "Cascadia Mono", "IBM Plex Mono", monospace;
|
||||
-fx-font-size: 14px;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .text {
|
||||
-fx-fill: #f2f6fb;
|
||||
-fx-font-family: "JetBrains Mono Medium", "JetBrains Mono", "Iosevka", "Cascadia Mono", "IBM Plex Mono", monospace;
|
||||
-fx-font-size: 14px;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .caret {
|
||||
-fx-stroke: #ffd27a;
|
||||
}
|
||||
|
||||
.editor-workspace-editor-surface {
|
||||
-fx-background-color: #171c22;
|
||||
-fx-border-color: #2a313c;
|
||||
-fx-border-width: 1;
|
||||
}
|
||||
|
||||
.editor-workspace-editor-viewport {
|
||||
-fx-background-color: transparent;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .text.editor-inline-hint {
|
||||
-fx-fill: #707070;
|
||||
-rtfx-background-color: #1f242f;
|
||||
-fx-font-family: "JetBrains Mono Medium", "JetBrains Mono", "Iosevka", "Cascadia Mono", "IBM Plex Mono", monospace;
|
||||
-fx-font-size: 13px;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area .text.editor-inline-hint-type {
|
||||
-fx-fill: #707070;
|
||||
-rtfx-background-color: #1f242f;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-text .text {
|
||||
-fx-fill: #eef3f8;
|
||||
}
|
||||
|
||||
.editor-workspace-command-bar {
|
||||
-fx-padding: 10 12 0 12;
|
||||
-fx-alignment: center-left;
|
||||
}
|
||||
|
||||
.editor-workspace-command-button {
|
||||
-fx-alignment: center;
|
||||
-fx-pref-width: 118px;
|
||||
-fx-min-width: 118px;
|
||||
}
|
||||
|
||||
.editor-workspace-warning {
|
||||
-fx-alignment: center-left;
|
||||
-fx-spacing: 8;
|
||||
-fx-padding: 8 12 8 12;
|
||||
-fx-background-color: #3b2a10;
|
||||
-fx-border-color: #8f6730;
|
||||
-fx-border-width: 0 0 1 0;
|
||||
-fx-text-fill: #f7ddb0;
|
||||
-fx-font-size: 12px;
|
||||
}
|
||||
|
||||
.editor-workspace-warning-counter {
|
||||
-fx-text-fill: #f3d8a7;
|
||||
-fx-font-size: 11px;
|
||||
-fx-font-weight: 700;
|
||||
}
|
||||
|
||||
.editor-workspace-warning-button {
|
||||
-fx-min-width: 24;
|
||||
-fx-pref-width: 24;
|
||||
-fx-max-width: 24;
|
||||
-fx-min-height: 24;
|
||||
-fx-pref-height: 24;
|
||||
-fx-max-height: 24;
|
||||
-fx-padding: 0;
|
||||
-fx-background-color: #4b3413;
|
||||
-fx-border-color: #9a7440;
|
||||
-fx-text-fill: #f7ddb0;
|
||||
-fx-font-size: 11px;
|
||||
-fx-background-radius: 4;
|
||||
-fx-border-radius: 4;
|
||||
}
|
||||
|
||||
.editor-workspace-warning-button:hover {
|
||||
-fx-background-color: #5a4018;
|
||||
-fx-border-color: #b38749;
|
||||
}
|
||||
|
||||
.workspace-dock-pane {
|
||||
-fx-collapsible: true;
|
||||
@ -960,13 +404,6 @@
|
||||
-fx-border-insets: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-helper-panel {
|
||||
-fx-min-height: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-helper-summary {
|
||||
-fx-text-fill: #dce6f0;
|
||||
}
|
||||
|
||||
.workspace-dock-pane-collapsed {
|
||||
-fx-background-insets: 0;
|
||||
@ -984,107 +421,6 @@
|
||||
-fx-border-insets: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-status-bar {
|
||||
-fx-padding: 6 12 6 12;
|
||||
-fx-background-color: #1b1f25;
|
||||
-fx-background-radius: 12;
|
||||
-fx-border-radius: 12;
|
||||
-fx-border-color: #2a313c;
|
||||
-fx-min-height: 40;
|
||||
-fx-pref-height: 40;
|
||||
-fx-max-height: 40;
|
||||
}
|
||||
|
||||
.editor-workspace-status-breadcrumb {
|
||||
-fx-alignment: center-left;
|
||||
}
|
||||
|
||||
.editor-workspace-status-breadcrumb-segment {
|
||||
-fx-alignment: center-left;
|
||||
-fx-padding: 0 2 0 0;
|
||||
}
|
||||
|
||||
.editor-workspace-status-breadcrumb-segment-root {
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-status-breadcrumb-text {
|
||||
-fx-text-fill: #d4dde7;
|
||||
-fx-font-size: 12px;
|
||||
}
|
||||
|
||||
.editor-workspace-status-breadcrumb-segment-root .editor-workspace-status-breadcrumb-text {
|
||||
-fx-text-fill: #f1f7fd;
|
||||
-fx-font-weight: bold;
|
||||
}
|
||||
|
||||
.editor-workspace-status-breadcrumb-separator {
|
||||
-fx-text-fill: #6f7e8e;
|
||||
-fx-font-size: 12px;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip {
|
||||
-fx-background-color: #11151b;
|
||||
-fx-background-radius: 4;
|
||||
-fx-border-radius: 4;
|
||||
-fx-border-color: #2a313c;
|
||||
-fx-padding: 0 8 0 8;
|
||||
-fx-text-fill: #c5d2de;
|
||||
-fx-font-size: 11px;
|
||||
-fx-alignment: center;
|
||||
-fx-min-height: 28;
|
||||
-fx-pref-height: 28;
|
||||
-fx-max-height: 28;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-type-text {
|
||||
-fx-background-color: #11151b;
|
||||
-fx-border-color: #2a313c;
|
||||
-fx-text-fill: #c5d2de;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-position {
|
||||
-fx-min-width: 44;
|
||||
-fx-pref-width: 44;
|
||||
-fx-max-width: 44;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-line-separator {
|
||||
-fx-min-width: 44;
|
||||
-fx-pref-width: 44;
|
||||
-fx-max-width: 44;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-indentation {
|
||||
-fx-min-width: 84;
|
||||
-fx-pref-width: 84;
|
||||
-fx-max-width: 84;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-language {
|
||||
-fx-min-width: 72;
|
||||
-fx-pref-width: 72;
|
||||
-fx-max-width: 72;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-access-mode {
|
||||
-fx-min-width: 36;
|
||||
-fx-pref-width: 36;
|
||||
-fx-max-width: 36;
|
||||
-fx-padding: 0;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-read-only {
|
||||
-fx-background-color: #3b2a10;
|
||||
-fx-border-color: #8f6730;
|
||||
-fx-text-fill: #f7ddb0;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-editable {
|
||||
-fx-background-color: #203226;
|
||||
-fx-border-color: #5a8567;
|
||||
-fx-text-fill: #ebfff0;
|
||||
}
|
||||
|
||||
.assets-workspace-split {
|
||||
-fx-background-color: transparent;
|
||||
|
||||
@ -1,39 +0,0 @@
|
||||
.editor-workspace-code-area-type-bash .text {
|
||||
-fx-fill: #edf2f7;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .lineno {
|
||||
-fx-text-fill: #788595;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-shebang {
|
||||
-fx-fill: #f0ae63;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-comment {
|
||||
-fx-fill: #7d8a98;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-string {
|
||||
-fx-fill: #dcbf88;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-variable {
|
||||
-fx-fill: #8fd4ff;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-keyword {
|
||||
-fx-fill: #d7a6ff;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-builtin {
|
||||
-fx-fill: #9fe2a0;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-command {
|
||||
-fx-fill: #7fc1ff;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-bash .text.editor-syntax-bash-operator {
|
||||
-fx-fill: #c7d3de;
|
||||
}
|
||||
@ -1,41 +0,0 @@
|
||||
.editor-workspace-code-area-type-json {
|
||||
-fx-highlight-fill: #204766;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text {
|
||||
-fx-fill: #dff3ff;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .lineno {
|
||||
-fx-text-fill: #7e92a6;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text.editor-syntax-json-key {
|
||||
-fx-fill: #8fd4ff;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text.editor-syntax-json-string {
|
||||
-fx-fill: #d9c48f;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text.editor-syntax-json-number {
|
||||
-fx-fill: #9ee39f;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text.editor-syntax-json-boolean {
|
||||
-fx-fill: #f3a6d6;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text.editor-syntax-json-null {
|
||||
-fx-fill: #c89cff;
|
||||
}
|
||||
|
||||
.editor-workspace-code-area-type-json .text.editor-syntax-json-punctuation {
|
||||
-fx-fill: #c8d5e2;
|
||||
}
|
||||
|
||||
.editor-workspace-status-chip-type-json {
|
||||
-fx-background-color: #132433;
|
||||
-fx-border-color: #4e88b8;
|
||||
-fx-text-fill: #e2f4ff;
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user