window.toolsBesideCanvas reads on with opt_bool, which treats null like an omitted value. docs/mcp.md and the params text now say that an omitted or null on toggles the setting and that any other non-boolean value is an error.
Docked Tools stays at the window's left edge again, outside any panels
docked on the left. Window › Toolbars › Keep Tools Beside the Canvas
(`window.toolsBesideCanvas {on?}`) docks it between those panels and the
canvas instead.
- The setting is its own field in the UI state and in workspaces, and a
missing field reads as off, so saved state and workspaces keep Tools at
the window's edge. Built-in workspaces have it off.
- Off, app.rs draws docked Tools before the docking layout, the canvas
reserves no width for it, and only the full-height window-edge strip
docks a floating Tools panel. On, the canvas panel draws it, the canvas
keeps room for it, and both the window edge and the canvas edge dock it
beside the canvas.
- Turning the setting off forgets the canvas-edge strip, so a strip laid
out while it was on does not dock Tools. A floating Tools panel stays
floating when the setting changes.
- `window.panel.dock {panel: "tools"}` docks Tools where the setting says.
- The menu label has a row in every catalog.
Docs: docs/mcp.md, docs/control-protocol.md, the ROADMAP progress log and
docs/target-app-parity.md. The headline-numbers row and the paragraphs
under the status lines are gone, and scores are unchanged.
On Linux, when the desktop draws the window's frame (KDE, Sway,
Hyprland, COSMIC and X11 sessions), the app bar painted the brand mark
under the desktop's title bar unless System Title Bar was on. The mark
followed the live preference instead of the frame the window has.
The desktop app now records the frame it opened the window with
(VectorcraftApp::desktop_frame), and system_title_bar reads it. A
change to System Title Bar during a session no longer shows or hides
the mark; it changes with the frame at the next start. Embedders
without a window of their own keep the mark.
With Snap to Grid on, a move of objects on one perspective plane at
different depths applied the snap correction only to the objects at the
first object's depth, and every other object moved by the pointer's
offset read at its own depth. Those objects left the grid and lost their
spacing.
Every object on the first object's plane now moves by that object's
plane offset plus the correction, so the edge of the joint bounds nearer
a gridline lands on it and the objects keep their spacing. A selection
at one depth snaps as before, and objects on other planes keep their own
offset.
The command catalog said "* ", "# ", "> " and "+ " all start a list
with the filled dot. It now names the filled dot, hollow circle,
filled square and dash. The text.startList test checks each of the
four triggers and the marker the layout draws.
Typed list detection gave every bulleted trigger the filled dot. Now
`*` and a space start a list with the filled dot (•), `+` with the
hollow circle (◦), `#` with the filled square (▪) and `>` with the dash
(–), each one of the existing Bullets presets. `1.`, `1)`, `A.` and `A)`
start the same numbered lists as before.
Only the list a typed trigger starts changes. Lists already in a
document keep their bullets, pasted triggers start no list, and Undo
and Redo of a typed list work as before.
Docs: docs/mcp.md (typed list paragraph), docs/target-app-parity.md.
- typed_lists_off_leaves_typed_markers_as_text turns the preference back
on for each marker and checks that typing it in a new paragraph starts
a list with a Bullets and Numbering undo step.
- start_lists_from_typed_markers_is_a_saved_type_preference: the Type
page shows the checkbox, checked by default; unchecking it turns the
preference off in the session and in the saved preferences, and every
bundled language translates its label.
Preferences > Type gets Start Lists From Typed Markers (`typedLists`, on
by default). With it off, a list marker and a space typed with the Type
tool at the start of a paragraph (`1. `, `1) `, `A. `, `A) `, `* `,
`# `, `> `, `+ `) stay as text and start no list. `text.startList`,
`text.setFormat {list}` and the Bullets and Numbered List buttons work
as before.
The preference reaches the Type tool through `ToolContext::typed_lists`.
The label has a row in every catalog.
A recorded save in the template format writes a copy and leaves the
document's file as it was, so it no longer clears the warning or the
refusals. A recorded Save or Save As with its own path gives a never-saved,
converted or restored document its file before Save and Close, so the
batch runs and warns that every data set saves over that one file.
With a destination folder and Override Save on, a recorded Save or Save As
step writes each data set to its own file in that folder and makes that
file the document's own, so Save and Close then saves each data set to its
own file. The batch no longer warns that every data set saves over one
file in that case, and no longer refuses a document that was never saved,
converted or restored, since the recorded step gives it a file first.
A recorded PDF, EPS, DXF, Save for Web or Save for Office Documents step
that gives a `path` writes the same file for every data set, because the
batch does not point these steps into the destination folder. The one-file
rule now counts them, so the dialog and `action.batch` warn.
Save and Close over the data sets of a document converted from an older
version or restored by Data Recovery is refused with "save the document
with Save As before Save and Close" before a data set is selected. Saving
such a document does not write its file, so the batch reported success
without saving anything. The message has a row in each of the 26 catalogs.
Batch… with a Data Sets source offers None, Save and Close and Folder again.
Save and Close saves the open document over its own file after each data
set. When every data set saves over the same file, the dialog shows a
warning and `action.batch` returns `warning`: with Save and Close, or with
a recorded step that writes a file and that the batch does not point into
the destination folder. A Save step without a path counts when it writes
the document's own file; Save As, Save a Copy, Save as Template and Export
steps count when they give a path; Export for Screens counts when its
folder, given or from its preset, names a folder. Save and Close over the
data sets of a document that was never saved is refused with "the
document has never been saved" before a data set is selected.
Data sets share one open document, so Save and Close saved every data set
over the same file and only the last one survived. action.batch now
returns an error for source datasets with destination saveAndClose before
it selects a data set or runs a step, and the Batch dialog offers None and
Folder for a Data Sets source, moving a Save and Close choice to Folder.
BFlat