feat(vscode): draw the diagram in the pilot's style, filled from a server palette

changes/unreleased/diagram-pilot-style.added.md

@@ -0,0 +1 @@
+- **The VS Code diagram panel draws in the pilot visualizer's style, and in colour, on request.** A **Style** list in the panel's toolbar, backed by the `opensysml.diagram.style` setting, picks the look of every diagram: `theme` (the default) follows the VS Code colour theme as before; `pilot` is the pilot's Standard B&W that the DOT and PlantUML forms already follow — white canvas, black sans-serif text, thin dark borders, square definitions and rounded usages, heavier packages, dashed regions, bold names over an italic keyword, thick arrowless connections, filled pseudo-states; and each of the eight colourblind-safe palettes (`okabe-ito`, `tol-bright`, `tol-muted`, `tol-light`, `brewer-set2`, `brewer-dark2`, `viridis`, `cividis`) is that look filled by keyword family, a usage a lighter tint of its definition's colour, text black. Changing the list keeps the choice in the settings and redraws every open diagram. The colours come from the server: `opensysml/render` with a `palette` now gives each node its `fill` and `border`, the same hex the DOT and PlantUML forms of that view take, advertised as `openSysmlRenderPalette`; against an older `sysml-lsp` a palette draws as `pilot` and the panel says why.

docs/internals/design/vscode-visual-modeling.md

@@ -530,6 +530,24 @@ pipeline's diagram output — and nothing there changed. The panel is a
 is edited as text with the diagram in step, and the editor's dirty state, undo and
 save are the text document's.
 
+The canvas has two looks, chosen by `opensysml.diagram.style` and the panel's
+**Style** list (`src/style.ts`): `theme`, which takes its colours from the VS Code
+theme, and the pilot visualizer's Standard B&W that the DOT and PlantUML forms
+follow (`docs/project/view-rendering-forms.md#style`), as CSS on the `pilot` class
+— white canvas, black text, 0.5 px `#181818` borders, square definitions and
+rounded usages by a class the node's kind gives its box, heavier packages, dashed
+regions, bold names over an italic keyword, 3 px arrowless connections, dashed
+flows, filled pseudo-states. The class changes no geometry the theme look draws (a
+definition alone is square there); the pilot rules square its packages and regions.
+A rendering answered after the setting moved is dropped, since the change queued a
+render in the new style. A palette is that look plus the `fill` and `border`
+the server puts on each node when the render request names one; the canvas sets
+each it is given as a custom property on the node's shape (a sequence participant
+comes with the fill alone) and computes no colour itself, so
+the panel, DOT and PlantUML of one view agree hex for hex and the contrast rule
+lives in one place. The server advertises `openSysmlRenderPalette`; without it the
+panel asks for no palette, draws `pilot`, and says why under the diagram.
+
 ### Test contract
 
 - `edit`: goldens for a new annotation in a view body and inline, an update in

docs/project/view-rendering-forms.md

@@ -456,7 +456,8 @@ every palette, and text stays black.
 | --- | --- | --- |
 | CLI | `-render <view> -render-form dot\|plantuml`; `-render-all <dir> -render-form dot` writes `.dot` files and `-render-form plantuml` writes `.puml` files; `-render-palette <name>` fills either | [`docs/reference/cli.md`](../reference/cli.md#rendering-a-view) |
 | REPL | `%render <view> dot\|plantuml [palette]`; `%help` names them; the form and, after a form that takes one, the palette complete | [`docs/reference/repl-commands.md`](../reference/repl-commands.md#rendering-a-view) |
-| LSP | `"form": "dot"` or `"plantuml"` and `"palette": "<name>"` on `opensysml/render` | [`docs/reference/lsp.md`](../reference/lsp.md) |
+| LSP | `"form": "dot"` or `"plantuml"` and `"palette": "<name>"` on `opensysml/render`; a palette also gives each node of the result its `fill` and `border`, so a client drawing its own SVG colours a node as these forms do (`Rendering.Fills`) | [`docs/reference/lsp.md`](../reference/lsp.md) |
+| VS Code | The diagram panel's **Style** list and `opensysml.diagram.style`: `pilot` draws the panel's SVG under this section's B&W rules, a palette name fills its nodes from the `fill` and `border` the server returns | [`editors/vscode/README.md`](../../editors/vscode/README.md#the-diagram-panel) |
 | Documents | `-render-document`/`-render-documents … -diagram-form dot\|plantuml`, `%render-document <name> dot\|plantuml`, `"diagramForm"` on `opensysml/renderDocument`: every graph-shaped diagram block as a ` ```dot ` or ` ```plantuml ` fence in Markdown, `<pre class="dot">` or `<pre class="plantuml">` in HTML, the source under a notice in PDF. The form is chosen at render time, not stated in the model: a `Diagram` block says what is drawn, not the notation — though it may state a `palette`, as it states a `direction`, which the DOT or PlantUML figure is filled with and the HTML figure carries as `data-palette` | [`docs/manual/authoring.md`](../manual/authoring.md#diagrams), [`docs/manual/outputs.md`](../manual/outputs.md) |
 
 The gRPC service (`api/proto/sysml.proto`, `internal/frontend/grpc`) has no view-render RPC and no

docs/reference/lsp.md

@@ -9,15 +9,17 @@ result:
 { "capabilities": { "experimental": {
     "openSysmlRender": true, "openSysmlRenderDocument": true, "openSysmlStdlibContent": true,
     "openSysmlApplyModelEdit": true, "openSysmlDebug": true,
-    "openSysmlCrossDocumentLayout": true } } }
+    "openSysmlCrossDocumentLayout": true, "openSysmlRenderPalette": true } } }
 ```
 
 `openSysmlRender` covers the view-rendering methods, `openSysmlRenderDocument`
 the document-rendering ones, `openSysmlStdlibContent` the request that serves
 the bundled standard library's text, `openSysmlApplyModelEdit` the request
-that turns model operations into text edits, and `openSysmlDebug` the
+that turns model operations into text edits, `openSysmlDebug` the
 [`opensysml/debug/*`](#opensysmldebug-requests) requests that run a drawn
-behavior and report where it stands.
+behavior and report where it stands, and `openSysmlRenderPalette` that a
+`palette` named in an `opensysml/render` request colours the result's nodes
+(`fill`, `border`) as well as its DOT or PlantUML artifact.
 
 A client that does not see that capability must not send these methods. That is
 how a new client and an older server stay compatible.
@@ -79,7 +81,7 @@ Renders one view of a document.
 | `textDocument.uri` | The document to render. It must be one the session holds — an open document, or a workspace file the server read. |
 | `view` | The qualified name of a view the document declares, a pseudo-view (below), or omitted. |
 | `form` | `mermaid`, `text`, `markdown`, `dot` or `plantuml`. Omitted writes the machine form of the rendering's kind: `markdown` for a table, `mermaid` for every other kind. `dot` writes Graphviz DOT for a `tree`, `interconnection`, `state` or `action` rendering, without needing Graphviz installed; `plantuml` writes PlantUML in the Pilot visualizer's B&W style for those kinds and a `sequence`, without needing a PlantUML jar. |
-| `palette` | Optional. A palette the `dot` and `plantuml` forms fill nodes with by keyword family: `okabe-ito`, `tol-bright`, `tol-muted`, `tol-light`, `brewer-set2`, `brewer-dark2`, `viridis` or `cividis` ([the palettes](../project/view-rendering-forms.md#palettes)). Omitted or empty draws black and white. A `mermaid` artifact notes the palette as not represented; `text` and `markdown` ignore it. |
+| `palette` | Optional. A palette the `dot` and `plantuml` forms fill nodes with by keyword family: `okabe-ito`, `tol-bright`, `tol-muted`, `tol-light`, `brewer-set2`, `brewer-dark2`, `viridis` or `cividis` ([the palettes](../project/view-rendering-forms.md#palettes)). Omitted or empty draws black and white. A `mermaid` artifact notes the palette as not represented; `text` and `markdown` ignore it. Whatever the form, a server advertising `openSysmlRenderPalette` gives each node the palette colours as `fill` and `border`, so a client drawing the nodes itself draws them the colours the DOT and PlantUML forms take. |
 
 Omitting `view` renders the view the document declares. If the document declares
 several, the request is ambiguous and fails, naming them
@@ -166,6 +168,7 @@ The result, for `{"view": "KitViews::widgetTree"}` over a document declaring
 | `declaration` | On a node or edge a workspace document declares but no qualified name reaches — an unnamed transition, a connection inside an unnamed part — the `range` of that declaration, in place of `fqn`; the range is one of the document `origin.uri` names, this one or, for a client advertising `openSysmlCrossDocumentLayout`, another of the workspace. `opensysml/applyModelEdit`'s `setLayout` and `setRoute` take it, with `declaredIn` when it is another document's, as the target of an inline annotation, since a view body has no name to state one about; no other operation reaches such an element. |
 | `owners` | On a node with an `fqn`: the namespaces declaring it, nearest first, each as its `fqn` and whether it is a `feature`, whether or not the view draws them. A client writes a connection into the nearest owner two nodes share, or into the document when they share none, and spells each end from there — through a feature by `.`, into any other namespace by `::` (`tank.fuelOut`, `Car::tank.fuelOut`). Absent for a top-level declaration. |
 | `palette` | What a diagram of this kind offers to add, in the document's language: `members` are member kinds for `applyModelEdit`'s `addMember`, `connections` are connection kinds for `addConnection`, `typed` are the `members` that may be given a `type`, and `owners` lists, for each member only some bodies declare (`subject`, `actor`, `stakeholder` in a requirement or case, `objective` in a case), the ids of the nodes whose declaration opens such a body — a client offers such a member on those nodes alone, and a member absent from `owners` on every declared node. The same admission decides where a node may be moved: `owners` also lists, under the `notation` of each drawn node that only some bodies declare (`entry action`, `subject`), the nodes that admit it, so a client offers as the new owner of a node the declared nodes, and the document, that its `notation` finds in `owners` — or every one when it is absent. An `interconnection` offers parts, ports, items, attributes and the connection kinds; a `state` diagram states and transitions; an `action` or `sequence` diagram actions, control nodes and successions; a `tree` every kind the language has. Absent for a kind that is not edited from a diagram — a `table`, whose rows name no owner or endpoint to act on, included. |
+| `fill`, `border` | On a node, when the request named a `palette`: the `#RRGGBB` colours the palette gives the node's box and its outline, the same the DOT and PlantUML forms draw it with — a definition its keyword family's colour, a usage a lighter tint of it, both lightened until black text reads on them. A `sequence` participant carries `fill` alone, PlantUML taking no border colour on one. Absent for a node the palette leaves black and white — a control node, a container drawn around its children (a `tree` fills those too, drawing containment as edges) — and for every node when no palette was named. A server that does not advertise `openSysmlRenderPalette` never sends them. |
 | `x`, `y`, `width`, `height`, `collapsed` | On a node: where the model places it, from a `DiagramLayout::Layout` annotation, in pixels from the canvas's top-left corner with y increasing downward. Absent for a node the model does not place; `width` and `height` only when the annotation sizes it; `collapsed` only when it says so. |
 | `route` | On an edge: the waypoints a `DiagramLayout::Route` annotation gives it, as an array of `{"x", "y"}` in the same coordinates. Absent for an edge with none. |
 | `canvas` | The drawing surface the view states with a `DiagramLayout::Canvas` annotation: its `unit` when given, and `width` and `height` together when the annotation sizes it (an explicit `0` is a size). Absent for a view stating none and for every pseudo-view. |

editors/vscode/README.md

@@ -93,6 +93,7 @@ own just waits for the server.
 | **What it draws** | The view the document declares. A document declaring several drawable views opens on the one whose declaration holds the editor's cursor, else the one last chosen for that document in this workspace, else the one picked from a list — the drawable views by name and kind, **All views** to open each in its own panel, and the pseudo-views last; views the server cannot draw are left out of that list (the panel's own picker still shows them, disabled, with the reason), and cancelling opens nothing. A document declaring none is drawn directly, as a model tree, interconnection diagram, state diagram, action flow, sequence diagram or element table — a table is written as Markdown rather than drawn, and is shown as that. A view whose rendering is not supported (`geometry`, `textual`) is listed but not drawable, and the reason is written under the diagram. |
 | **Several panels** | A document may have one panel per view open at once; they are titled `Diagram: <file> — <view>` while there are several, each redraws when the model changes, and each highlights the cursor's node. Open Diagram reveals the panel already showing the chosen view, or opens another beside the source for a different one. Picking a view in a panel's picker retargets that panel — unless another panel already draws it, which is revealed instead. Panels come back with their views when the window reloads. |
 | **Where things go** | A node the model places — a `DiagramLayout::Layout` annotation in the view's body or the element's own — is drawn exactly there, at the size it states; every other node takes a slot in a grid under its owner, in the order rendered, so the same model draws the same way every time. An edge follows the waypoints its `DiagramLayout::Route` gives it, else runs straight. |
+| **Style** | The panel's **Style** list, or the `opensysml.diagram.style` setting, picks the look of every diagram. `theme` (the default) follows the VS Code colour theme. `pilot` is the pilot visualizer's Standard B&W, the look the DOT and PlantUML forms are written in: white canvas, black sans-serif text, thin dark borders, square definitions and rounded usages, a heavier border on a package and a dashed one on a region, bold names over a small italic `«kind»`, thick arrowless connections and dashed flows, filled black pseudo-states. The eight palettes (`okabe-ito`, `tol-bright`, `tol-muted`, `tol-light`, `brewer-set2`, `brewer-dark2`, `viridis`, `cividis`, [described here](../../docs/project/view-rendering-forms.md#palettes)) are that look filled by keyword family — parts one colour, ports another, a usage a lighter tint of its definition's — in the very colours a DOT or PlantUML export of the view takes, since the server names them; text stays black. Changing the list keeps the choice in your settings and redraws every open diagram. A `sysml-lsp` too old to name colours draws a palette as `pilot` and says so under the diagram. |
 | **Navigation** | Click a node to open the declaration it was built from; moving the cursor in the editor highlights the node whose declaration contains it. A node built from a standard library declaration opens the bundled library file, read-only. |
 | **While typing** | A rendering that fails mid-keystroke leaves the last good diagram on screen, dimmed, with the error in the status line: the panel never blanks. What a rendering could not represent is listed under it. |
 | **Cost** | The panel asks for a diagram only while visible, and only once an editing burst settles. The panel draws its own SVG, and its CSP allows the bundled script alone — nothing is fetched from the network. |
@@ -171,6 +172,7 @@ The command exists only when the server advertises
 | `opensysml.server.enabled` | `true` | Set to `false` for highlighting without a server. |
 | `opensysml.trace.server` | `"off"` | Trace LSP traffic in the "SysML v2" output channel. |
 | `opensysml.diagram.autoOpen` | `true` | Open a model file's diagram beside it when the file is shown. Set to `false` to open diagrams only with `SysML: Open Diagram`. |
+| `opensysml.diagram.style` | `"theme"` | The look every diagram is drawn in: `theme` for the VS Code colour theme, `pilot` for the pilot visualizer's black and white, or one of the eight palettes for that look filled by keyword family. The panel's **Style** list sets the same value. |
 
 ## Grammar generation
 

editors/vscode/package.json

@@ -94,6 +94,35 @@
           "type": "boolean",
           "default": true,
           "markdownDescription": "Open the diagram of a SysML or KerML file beside its editor as soon as the file is shown. A diagram you close stays closed for that file until you run **SysML: Open Diagram** on it again."
+        },
+        "opensysml.diagram.style": {
+          "type": "string",
+          "default": "theme",
+          "enum": [
+            "theme",
+            "pilot",
+            "okabe-ito",
+            "tol-bright",
+            "tol-muted",
+            "tol-light",
+            "brewer-set2",
+            "brewer-dark2",
+            "viridis",
+            "cividis"
+          ],
+          "enumDescriptions": [
+            "Follow the VS Code colour theme.",
+            "The pilot visualizer's Standard B&W: white canvas, black text, thin dark borders, square definitions and rounded usages.",
+            "The pilot look, filled by keyword family from the Okabe–Ito palette.",
+            "The pilot look, filled by keyword family from Paul Tol's bright palette.",
+            "The pilot look, filled by keyword family from Paul Tol's muted palette.",
+            "The pilot look, filled by keyword family from Paul Tol's light palette.",
+            "The pilot look, filled by keyword family from ColorBrewer Set2.",
+            "The pilot look, filled by keyword family from ColorBrewer Dark2.",
+            "The pilot look, filled by keyword family from the viridis colour map.",
+            "The pilot look, filled by keyword family from the cividis colour map."
+          ],
+          "markdownDescription": "The look every diagram is drawn in, also chosen from the **Style** list in the diagram panel. A palette colours definitions with their keyword family's colour and usages with a lighter tint of it, the same colours the DOT and PlantUML exports take; text stays black."
         }
       }
     },