HiNC-Deploy/HiNC-2025-win-desktop-Deploy
Archived
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

deploy.

Browse Source
This commit is contained in:
iamboss
2026-09-12 18:16:27 +08:00
parent b7f55aa631
commit 397a7a8cc4
96 changed files with 1167 additions and 1259 deletions
Download Patch File Download Diff File Expand all files Collapse all files
App/wwwroot/HiAPI-docsite/manual/basics/finding-your-way.html
+25 -26
View File
@@ -88,11 +88,11 @@
<h1 id="finding-your-way">Finding Your Way</h1>
<p>The application is a handful of screens, and most of what a job configures lives inside a tree on
two of them. The <strong>Page</strong> menu reaches six of those screens, and it is not all of them. Every node
two of them. The <strong>Page</strong> menu reaches five of those screens, and it is not all of them. Every node
of a tree has an address of its own, so a place in the application can be linked to rather than
described.</p>
<h2 id="the-screens">The screens</h2>
<p>The <strong>Page</strong> dropdown on the menu bar carries six entries in three groups. The first group is the
<p>The <strong>Page</strong> dropdown on the menu bar carries five entries in two groups. The first group is the
job, in the order a job uses it:</p>
<ul>
<li><strong>Tool House</strong> — the tools, one editor per tool</li>
@@ -106,27 +106,24 @@ run reports</li>
<li><strong>File Explorer</strong> — browsing the files under the roots the service exposes</li>
<li><strong>Mechanism Builder</strong> — authoring a kinematic chain</li>
</ul>
<p>Below a second separator, one more:</p>
<ul>
<li><strong>Legacy-Controller</strong> — the controller settings that the General Setup tree's Controller branch
has no editor for. The page it opens is titled <em>Controller</em>.</li>
</ul>
<p>No entry is ever greyed out. All six are selectable with no project open; what they lead to is what
<p>No entry is ever greyed out. All five are selectable with no project open; what they lead to is what
changes.</p>
<p>Three screens have no entry in this menu:</p>
<ul>
<li><strong>Machine Tool</strong>, at <code>/machine-tool</code>, reached by address only. It shows the machine chain beside a
folder button whose tooltip reads <strong>Browse</strong> and a GUI / XML view switch, so it is more than a
look at the chain — and it needs a project open.</li>
folder button — whose tooltip reads <strong>Browse</strong> once a project is open, and <strong>Load a project first</strong>
before that — and a GUI / XML view switch, so it is more than a look at the chain, and it needs a
project open.</li>
<li><strong>Log Viewer</strong>, reached from the <strong>Show Log</strong> button near the right-hand end of the menu bar. Its
address is <code>/preference/log</code>.</li>
<li>The sign-in page, which the service raises on its own when it wants one.</li>
</ul>
<h2 id="selecting-inside-a-tree">Selecting inside a tree</h2>
<p>General Setup and Execution each carry a Control Tree in their left dock, under a header reading
<strong>Control Tree</strong>, with the selected node's editor in the row beneath it. That editor row is titled
with the path of the selection — <em>General Setup / Workpiece / Anchor / Geom To Fixture</em> — which is
also how these pages name a place in prose.</p>
<strong>Control Tree</strong>, with the selected node's editor in the row beneath it. That editor row names the
path of the selection — <em>General Setup / Workpiece / Anchor / Geom To Fixture</em> — which is also how
these pages name a place in prose; the header shows as much of it as the dock is wide, so a deep
path arrives truncated.</p>
<p>General Setup's tree has one root, <strong>General Setup</strong>, holding <strong>Machine Tool</strong>, <strong>Spindle
Capability</strong>, <strong>Background</strong>, <strong>Coolant</strong>, <strong>Fixture</strong>, <strong>Workpiece</strong> and <strong>Controller</strong>, in that
order. With a project open, a <strong>CSV Controller</strong> and a <strong>CL Controller</strong> node follow, each behind
@@ -148,13 +145,14 @@ copying it copies the node, not just the page.</p>
<li>To take a link from the tree instead, right-click a node's label. Every label is a real link to
that node's address, so the browser's own copy-link and open-in-new-tab entries both apply to
it.</li>
<li>Ctrl-click, Cmd-click or Shift-click a label to open that node in a new tab. The current tab's
selection stays where it is.</li>
<li>Ctrl-click or Cmd-click a label to open that node in a new tab; Shift-click and middle-click open
it wherever the browser opens any other link. The current tab's selection stays where it is.</li>
<li>A plain left click selects the node in place, without navigating.</li>
<li>Paste a <code>?tree=</code> value belonging to the other tree page and it redirects to the page that owns
it, so a link does not have to name the right screen to reach the right node.</li>
<li>Paste a <code>?tree=</code> value belonging to another page's tree and it redirects to the page that owns
it — the other tree page, or Tool House — so a link does not have to name the right screen to
reach the right node.</li>
</ol>
<p>Tool House has no <code>?tree=</code> at all — its address already names the selection, as
<p>Tool House has no <code>?tree=</code> at all — its address names the selection down to the sub-tab, as
<code>/tool-house/&lt;tool&gt;/&lt;tab&gt;/&lt;sub-tab&gt;</code>, so <code>/tool-house/1/cutter/material</code> is a link to one tool's
Material sub-tab.</p>
<p>Arriving at a tree page with no <code>?tree=</code> still lands on a selected node — the last selection this
@@ -164,8 +162,9 @@ as the tree is built, so the address bar is a whole link from then on.</p>
<h5>Important</h5>
<p>An address for a node its Preference checkbox is currently hiding — a <strong>CSV Controller</strong> or <strong>CL
Controller</strong> node — is honoured only when the tree is built while that address is the current
one, and it reveals nothing without a project open. In practice that means a full page load:
pasting the link into a new tab, or reloading on it. Jumping to it from a screen that has already
one, and it reveals nothing without a project open. In practice that means the tree's first build
on that address: pasting the link into a new tab, reloading on it, or opening General Setup for the
first time since the page or the project was loaded. Jumping to it from a screen that has already
shown General Setup for the current project does not rebuild that tree, so the address is dropped
in silence with the selection left where it was.</p>
</div>
@@ -176,7 +175,7 @@ describes the fields as column tags matched against the CSV header line: <strong
prefix</strong> <code>MC.</code>, <strong>Cutter location prefix</strong> <code>CL.</code> and <strong>Tool id column</strong> <code>ToolId</code>.</p>
<p><img src="finding-your-way-img/controller-csv-revealed.en.png" alt="The General Setup Control Tree with a CSV Controller node at the same indent as Controller, a sibling rather than a child of it, and the CSV column-tag editor below the tree"></p>
<h2 id="the-addresses">The addresses</h2>
<p>Nine addresses render a screen of their own. The bracketed segments are optional, so the bare
<p>Eight addresses render a screen of their own. The bracketed segments are optional, so the bare
address resolves too and the screen fills them in from its own state; File Explorer's trailing path
carries as many segments as the browsed folder is deep.</p>
<table>
@@ -204,10 +203,6 @@ carries as many segments as the browsed folder is deep.</p>
<td>Machine Tool</td>
</tr>
<tr>
<td><code>/controller/&lt;tab&gt;</code></td>
<td>Controller</td>
</tr>
<tr>
<td><code>/util/file-explorer/&lt;root&gt;/&lt;path&gt;</code></td>
<td>File Explorer</td>
</tr>
@@ -225,7 +220,7 @@ carries as many segments as the browsed folder is deep.</p>
</tr>
</tbody>
</table>
<p><code>/</code> lands on Execution. Six further addresses render nothing of their own and redirect into a tree
<p><code>/</code> lands on Execution. Seven further addresses render nothing of their own and redirect into a tree
page's node instead:</p>
<table>
<thead>
@@ -236,6 +231,10 @@ page's node instead:</p>
</thead>
<tbody>
<tr>
<td><code>/controller</code>, and anything below it</td>
<td>General Setup, the Controller branch — the trailing path, the retired Legacy-Controller page's tab names included, is discarded</td>
</tr>
<tr>
<td><code>/spindle-capability/&lt;tab&gt;</code></td>
<td>General Setup, the Spindle Capability branch — on that tab's item when the segment names one, on the branch itself otherwise</td>
</tr>
App/wwwroot/HiAPI-docsite/manual/basics/index.html
+4 -3
View File
@@ -89,8 +89,9 @@
<p>This section covers the sign-in gate in front of the application and what is true on every screen
behind it: the frame that stays put while the page area changes, the project the rest of the
application is configured against, the ways one screen leads to another, and the surfaces that
report what the service is doing. The task sections build on it rather than restating it. The pages
application is configured against, the ways one screen leads to another, the settings that follow
the application rather than the project, and the surfaces that report what the service is doing.
The task sections build on it rather than restating it. The pages
below are ordered as the application presents them: the gate, the frame, the project, the screens,
the settings, the messages.</p>
<p>For a first end-to-end run rather than a reference, start with
@@ -102,7 +103,7 @@ the settings, the messages.</p>
<li><a href="projects.html">Projects</a> — Creating, opening, saving and closing a project, and what Save As does and does not copy</li>
<li><a href="finding-your-way.html">Finding Your Way</a> — The screens the Page menu reaches and the ones it does not, selecting inside a tree, and linking to a node</li>
<li><a href="preferences.html">Preferences</a> — The settings the service keeps for everyone on it, and the ones the browser keeps for the device it is sitting at</li>
<li><a href="messages-and-logs.html">Messages and Logs</a> — The footer's three channels, the four session message tabs and the service log, and which answers which question</li>
<li><a href="messages-and-logs.html">Messages and Logs</a> — Where a message lands and how long it lasts: the toasts and the footer, the four session message tabs and the service log, and which answers which question</li>
</ul>
<h2 id="see-also">See Also</h2>
<ul>
App/wwwroot/HiAPI-docsite/manual/basics/messages-and-logs.html
+30 -20
View File
@@ -96,14 +96,16 @@ Picking the right surface is most of the difference between a specific question
<ul>
<li><strong>A toast</strong> — bottom right, for a few seconds, then gone. The only surface that interrupts, and
the only one that keeps nothing itself.</li>
<li><strong>The footer's latest line, and the recent list behind it</strong> — every toast that carried any text is
copied here before it is shown, so this list is the toast's afterlife. Only a toast with neither
message nor caption is skipped, and a small number of status lines are written straight here and
never toast at all.</li>
<li><strong>The footer's latest line, and the recent list behind it</strong> — a toast is copied here before it is
shown, so this list is the toast's afterlife. Two kinds never arrive: a toast carrying neither
message nor caption, and the notices Tool House, the <strong>Spindle Capability</strong> editor and the
Controller panels raise, which are shown once and not kept. A small number of status lines go the
other way — written straight here, and never toasted at all.</li>
<li><strong>The footer's session strip</strong> — the middle of the bar, drawn once a run has produced something
and empty until then.</li>
<li><strong>The footer's background zone</strong> — the right end, drawn only while a project file operation is in
flight, naming the operation and the path it is working on.</li>
<li><strong>The footer's background zone</strong> — the right end, drawn only while one of the <strong>Project</strong> menu's
operations is in flight — <strong>Close Project</strong> included — naming the operation and the path it is
working on.</li>
<li><strong>The Session Messages panel</strong> — on the Execution page, four lists kept by the service.</li>
<li><strong>The Log Viewer</strong> — the file the service itself writes for the current day.</li>
</ul>
@@ -111,12 +113,20 @@ flight, naming the operation and the path it is working on.</li>
four lists, and the panel is where it stays.</p>
<h2 id="messages-a-project-load-raises">Messages a project load raises</h2>
<p>Opening or re-reading a project can report holes in it — a referenced STL missing from disk, or a
mesh-geometry <code>.wct</code> file a raw geometry names but that is not there. <strong>None of these fail the load.</strong>
The project opens, the body that needed the missing file simply comes up without its geometry, and
the action still reports success. The message is the only thing that says otherwise.</p>
<p>These messages then take a path of their own, and it has a consequence worth knowing before you rely
on it. A project file operation runs outside any session, so the panel's four lists — which belong to
the service, and are where everything a <em>run</em> reports stays — never see them. Instead the first five
runner configuration the file names that would not load, leaving the project on a default one.
<strong>None of these fail the load.</strong> The project opens, the body that needed the missing file simply
comes up without its geometry, and the action still reports success. The message is the only thing
that says otherwise.</p>
<p>Two neighbouring cases go elsewhere. A mesh-geometry <code>.wct</code> file a raw geometry names but that is not
there raises nothing here at all, because the load never opens it; the first word about it comes when
the meshed geometry is next needed, and that message belongs to the run, so it lands in the Session
Messages panel like any other. A side file the project names as a reference — the machine chain, the
spindle capability, a material, a cutting parameter set — is the opposite case: a missing one fails
the load outright, and that arrives as an error rather than as one of the messages described here.
See <a href="projects.html">Projects</a>.</p>
<p>These messages then take a path of their own, and it has a consequence worth knowing before that
path is relied on. A project file operation runs outside any session, so the panel's four lists —
which belong to the service, and are where everything a <em>run</em> reports stays — never see them. Instead the first five
errors and warnings are toasted, anything past that goes straight to the footer's recent list, and
one more toast says how many did not get their own. Anything milder than a warning is not surfaced in
the window at all.</p>
@@ -126,15 +136,15 @@ read <a href="#the-service-log">the service log</a>, which has them either way.
not.</p>
<h2 id="the-footer">The footer</h2>
<p>The left region is this browser's own record and nothing else's. The list behind the latest line is
newest first, capped at a hundred entries, emptied by its <strong>Clear</strong> button and by a reload, and
written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it
newest first, capped at a hundred entries, emptied by its <strong>Clear</strong> button — which takes the latest
line back to <em>Ready</em> with it — and by a reload, and written down nowhere — nothing about it survives closing the tab. Each entry keeps the wording it
was raised in, so switching the language leaves the list as a mixture while the panel's lists
re-render at once. The frame page describes the regions themselves: see
<a href="the-app-window.html">The Application Window</a>.</p>
<p><strong>Nothing marks the list as having something new in it.</strong> The button carries no badge and no dot,
deliberately, because a toast has already drawn attention once. The consequence is the failure this
page exists to prevent: a message raised while another screen was open, or while the window was
behind something else, is invisible until that menu is opened by hand. Opening it after an action
page exists to prevent: a message that never toasted at all, or one whose few seconds expired while
the window was behind something else, is invisible until that menu is opened by hand. Opening it after an action
that seemed to do nothing is the cheapest check available.</p>
<p>The middle strip is the other way round — the service pushes it, so every connected browser sees the
same run activity, and each browser keeps its own short ring of the last entries behind it. What it
@@ -149,7 +159,7 @@ appear on it at all. The lists on the service drop nothing.</p>
header row reads <strong>Session Messages</strong> and stays visible when the panel is collapsed, so a grey strip
with that name on it is the panel, shut.</p>
<p><strong>The whole column can be switched off, and nothing on the page says so.</strong> The column quick-toggles
in the middle of the menu bar include one whose tooltip reads <em>Toggle the Execution canvas &amp;
at the right-hand end of the menu bar include one whose tooltip reads <em>Toggle the Execution canvas &amp;
messages column</em>; with it off, neither the panel nor its header row is drawn, and the page simply
looks like it has fewer parts. That choice is the browser's and survives a reload. The expanded or
collapsed state of the panel itself is not: it is kept by the service, and is therefore the same for
@@ -269,14 +279,14 @@ application.</p>
</tr>
<tr>
<td>what was reported while another screen was open</td>
<td>the recent list behind it — nothing else will mention it</td>
<td>the recent list behind it — the only copy the window keeps</td>
</tr>
<tr>
<td>where a run has got to</td>
<td>the footer's session strip</td>
</tr>
<tr>
<td>whether a project file operation is still running</td>
<td>whether one of the Project menu's operations is still running</td>
<td>the footer's background zone</td>
</tr>
<tr>
@@ -297,7 +307,7 @@ application.</p>
</tr>
<tr>
<td>why a project opened with pieces missing</td>
<td>the toasts it raised, or the Log Viewer — <strong>not</strong> the Session Messages panel</td>
<td>the footer's recent list, or the Log Viewer — <strong>not</strong> the Session Messages panel</td>
</tr>
<tr>
<td>what the service recorded, shown or not</td>
App/wwwroot/HiAPI-docsite/manual/basics/preferences.html
+16 -11
View File
@@ -89,8 +89,9 @@
<p>The settings that follow the application rather than the project are kept on two sides: the service,
where one value serves every browser signed in to it, and the browser, for the device it is sitting
at. The <strong>Preference</strong> menu is where most of them are set, and the rest are reached from the panel
each one belongs to. Which side keeps a setting is the thing worth knowing about it, because that is
at. The <strong>Preference</strong> menu carries four of them — the language, the physics switch and the two
controller checkboxes — and the rest are reached from the panel each one belongs to. Which side
keeps a setting is the thing worth knowing about it, because that is
what decides who else sees the change.</p>
<h2 id="where-it-is">Where it is</h2>
<p>The <strong>Preference</strong> dropdown on the menu bar, after <strong>Project</strong> and <strong>Page</strong>. It carries no OK and no
@@ -126,9 +127,11 @@ for a selected step, which of that page's charts, its <strong>Session Messages</
Properties</strong> panel are switched on, the General Setup canvas's display options including the work
coordinate its marker draws, and the graphic cache budget.</p>
<p><strong>The browser keeps the arrangement of the screen in front of it.</strong> That is the two tree pages'
layout — which columns are shown, how wide the docks are, which tree nodes are left unfolded and
which node each tree page reopens on — together with the two controller checkboxes above, and the
File Explorer's editor pane, its split and its sort order. Three of the Execution page's panels sit
layout — which columns are shown, how wide the docks are and how the right-hand dock is divided
between its two columns, how tall the editor row under each tree is, which tree nodes are left
unfolded, which node each tree page reopens on, the heights dragged between stacked panels, the two
shared chart legend widths and the shared strip-chart x-axis mode — together with the two controller
checkboxes above, and the File Explorer's editor pane, its split, its auto-save and its sort order. Three of the Execution page's panels sit
on this side rather than with that page's others: the <strong>3D Rendering Canvas</strong>, <strong>CWE</strong> and
<strong>Sentence Syntax</strong>. The browser also holds a copy of the language, used only to paint the first
frame before the service can be asked; the service's value wins every disagreement, so a language
@@ -139,15 +142,17 @@ reaches the service's preference file only when some later preference save write
service stopped before any such save comes back on the budget it had before.</p>
<h2 id="making-a-physics-change-take">Making a physics change take</h2>
<p><strong>Show Physics Options</strong> is read while a tree or a tab row is being built, not while one is on screen,
so the four routes below are what the tree and the tab row need; the two canvases pick the change up
on their own next draw instead. Ticking it therefore changes nothing already built: the tree does
not grow the nodes it gates, and the Tool House tab row does not grow the tab, until something
builds them again. Folding a branch shut and opening it again is not a rebuild.</p>
so the four routes below are what the tree and the tab row need; the Execution page's <strong>CWE</strong> canvas
re-reads it the next time the selected step changes, while the Tool House canvas fixes the cutter's
shape when its rendering connection is made and holds it until that connection is made again.
Ticking it therefore changes nothing already built: the tree does not grow the nodes it gates, and
the Tool House cutter's section-tab row does not grow the tab, until something builds them again.
Folding a branch shut and opening it again is not a rebuild.</p>
<p>Four things do rebuild one:</p>
<ol>
<li>Reload the browser. That rebuilds the whole application, every tree included.</li>
<li>The project under the session changes — <strong>New</strong>, <strong>Load</strong>, <strong>Close Project</strong>, or a <strong>Save As</strong> to a
location other than the one already open. Every screen the session has built is discarded and
<li>The project under the session changes — <strong>New</strong>, a <strong>Load</strong> that picks a different project,
<strong>Close Project</strong>, or a <strong>Save As</strong> to a location other than the one already open. Every screen the session has built is discarded and
built again, and <strong>ReLoad</strong> does the same on the path already open.</li>
<li>On Tool House, select a different tool in the left column and come back. The tab row is built for
whichever tool is being shown, so moving between two tools rebuilds it twice.</li>
App/wwwroot/HiAPI-docsite/manual/basics/projects.html
+22 -12
View File
@@ -156,12 +156,17 @@ project file's own folder. Opening the project file in a text editor shows those
than what they point at.</p>
<div class="IMPORTANT">
<h5>Important</h5>
<p><strong>A reference that points at nothing does not stop the project opening.</strong> Load and ReLoad read what
they can and report what they could not — a missing STL, or a mesh-geometry <code>.wct</code> file a raw
geometry names — and the project comes up with that body simply having no geometry, the action
still reporting success. The message is the only thing that says otherwise, and it is not kept
where a run's messages are kept: see
<a href="messages-and-logs.html#messages-a-project-load-raises">Messages a project load raises</a>.</p>
<p><strong>A raw geometry that points at nothing does not stop the project opening; a missing side file
does.</strong> Load and ReLoad read what they can and report what they could not — a missing STL, say —
and the project comes up with that body simply having no geometry, the action still reporting
success. A mesh-geometry <code>.wct</code> file a raw geometry names is quieter still: the load neither opens
it nor mentions it, and the first word about it is a warning raised when the meshed geometry is
first needed. A side file named as a reference is the other case altogether: when the machine
chain, the spindle capability, a material or a cutting parameter set is not where the project file
says it is, the load fails outright — no project opens, and the failure is reported as an error
rather than as a diagnostic beside a successful load. Where a load does succeed with a hole, the
message is the only thing that says otherwise, and it is not kept where a run's messages are kept:
see <a href="messages-and-logs.html#messages-a-project-load-raises">Messages a project load raises</a>.</p>
</div>
<p>A project is therefore a folder at least as much as a file. Copying one to another machine, archiving
one, or handing one to somebody else means taking the folder.</p>
@@ -176,10 +181,14 @@ editor, waiting on a file to be given to it.</p>
<div class="WARNING">
<h5>Warning</h5>
<p><strong>A Save As into a new folder can produce a project that finds none of its programs.</strong> Save As
writes out every side file the project file holds as a reference, into the new folder and at the
same relative place, and nothing it does not. What it leaves behind is whatever the project names
as a plain path instead of as a reference — and the NC programs a mission plays are named that
way. Nothing rewrites those paths either, so the saved project still asks for <code>NC/…</code>, now
writes out the side files the project file references — the machine chain, the spindle capability,
the materials, the cutting parameters, and the STL meshes the equipment and the workpiece name —
into the new folder and at the same relative place. Two things travel as a path with nothing
behind them: a mesh-geometry <code>.wct</code>, which is never written out at all, and an STL that was
already missing when the project opened, which is deliberately left missing rather than replaced
by an empty file. Neither are the NC programs a mission plays: the project records
each as a path, and nothing on the save side copies the file. Nothing rewrites those paths either,
so the saved project still asks for <code>NC/…</code>, now
underneath the new folder, where nothing has put it. The programs have to be brought across by
hand, or the Save As aimed at a folder that already holds them.</p>
</div>
@@ -205,8 +214,9 @@ did not change — carries on with what it was showing.</p>
performed the Save As is told, in the reply to its own request. Every other browser goes on
displaying the old path in its <strong>Project</strong> dropdown, although the service is working with the new one
underneath — so a Save from any of them writes to the new path. A stale row corrects itself the next
time the service reports its state to that browser: a reload, another project change, or a run being
started, paused, finished or reset from any browser.</p>
time the service reports its state to that browser: a reload, the browser's status connection
dropping and coming back, another project change, or a run being started, paused, finished or reset
from any browser.</p>
<p>New, Load, ReLoad, Save and Save As take a turn each. A second one asked for while the first is still
running is refused rather than queued, and the refusal arrives as a warning reading <em>Another project
operation is in progress. Please try again.</em> Close Project takes no part in that turn-taking: it
App/wwwroot/HiAPI-docsite/manual/basics/signing-in.html
+3 -2
View File
@@ -105,8 +105,9 @@ change a password or recover one from inside the application. All three are edit
configuration, made by whoever runs the service, and they take effect at its next restart.</p>
<p>What the gate closes is the service's own surface: the requests each screen makes for data, and the
live channels that keep those screens current. It does not close the page. The application shell,
the brand image and the sign-in card itself are served before authorization is consulted, which is
what lets the card be drawn for a browser that holds no session.</p>
the brand image and the sign-in card itself all reach a browser that holds no session: the brand
image and the built bundle the card is drawn from are plain files, served before authorization is
consulted, and the shell page is exempt from the gate outright.</p>
<h2 id="signing-in-1">Signing in</h2>
<p>The card asks for one pair of credentials, under the prompt <em>Please sign in to continue</em>.</p>
<ol>
App/wwwroot/HiAPI-docsite/manual/basics/the-app-window.html
+25 -20
View File
@@ -92,7 +92,7 @@ along the bottom. The frame is built once and stays mounted for the whole sessio
described here is present on every page. A project change is the one event that reaches into it and
rebuilds what the middle holds.</p>
<p>The whole frame at <code>/execution</code>, with the demo project open. Only the column quick-toggles and the
connection badge, in the middle of the bar, are there because of the page underneath them — the logo,
connection badge, in the right-hand group, are there because of the page underneath them — the logo,
the three dropdowns, the page title and <strong>Show Log</strong> sit on the bar whatever page is open, and the
sign-out button turns on whether a sign-in is asked for rather than on the page. The strip along the
very bottom is the footer, reading <strong>Ready</strong> because nothing has been reported yet.</p>
@@ -111,12 +111,12 @@ column), three on General Setup. Each glyph is a small map of the page with its
and each tooltip names the column it toggles. Tool House lays itself out with draggable splitters
and gets no buttons here.</li>
<li><strong>The connection badge</strong> — the Execution page only. See below.</li>
<li><strong>The current page's title</strong> — the destination's own title, which is where two controls read
differently from where they land: the Page menu's <strong>Legacy-Controller</strong> entry opens the page titled
<strong>Controller</strong>, and <strong>Show Log</strong> opens the page titled <strong>Log Viewer</strong>.</li>
<li><strong>The current page's title</strong> — the destination's own title, which is where one control reads
differently from where it lands: <strong>Show Log</strong> opens the page titled <strong>Log Viewer</strong>.</li>
<li><strong>Show Log</strong> — present on every page.</li>
<li><strong>The sign-out button</strong> — labelled with the signed-in user name, or <strong>Logout</strong> when the service has
no name for it. It is there only while the service asks for a sign-in.</li>
no name for it. It is there only while the service asks for a sign-in and this browser has passed
it.</li>
</ul>
<h2 id="the-page-area">The page area</h2>
<p>Everything between the bars is the current page, and every page reached during a session stays built:
@@ -125,16 +125,22 @@ half-finished and an established rendering connection exactly as they were.</p>
<p>Two things it does not carry over. Nothing restores a scroll position inside a panel: coming back to a
page finds its panels scrolled to where a fresh mount would put them. And a browser reload is not a
navigation — it rebuilds the whole application and empties the cache; what survives it is what lives
outside the page area, namely the address (a <code>?tree=</code> selection in it included) and the layout the
browser keeps for itself.</p>
outside the page area: the address (a <code>?tree=</code> selection in it included), the layout the browser
keeps for itself, and the preferences the service holds — the language, <strong>Show Physics Options</strong>, and
which of the Execution page's charts, its <strong>Session Messages</strong> panel and its <strong>Step Properties</strong>
panel are switched on.</p>
<p>The column buttons are remembered per page — the two tree pages each keep their own choices — while
the dock widths and the list of unfolded tree nodes are single settings both of them share, so
widening the dock on Execution widens it on General Setup too.</p>
<p><strong>F5 to F8 belong to the Execution page.</strong> They drive its transport — F5 starts or resumes, F6
pauses, F7 runs one NC line, F8 runs one machining step — and they are bound only while that page is
the one on screen, so on every other screen F5 is the browser's own reload. A key whose button is not
available at that moment, or that is pressed with the focus in a text field, is handed back to the
browser instead. That matters most for F5: while a run is in progress the start button is
unavailable, so the key reloads the page and takes the session with it.</p>
unavailable, so the key reloads the page and the screens the session had built go with it.</p>
<h2 id="what-a-project-change-does">What a project change does</h2>
<p><strong>New</strong>, <strong>Load</strong>, <strong>ReLoad</strong> and <strong>Close Project</strong> discard every page the session has built and
<p><strong>New</strong>, a <strong>Load</strong> that picks a different project, <strong>ReLoad</strong>, a <strong>Save As</strong> to a location other
than the one already open, and <strong>Close Project</strong> discard every page the session has built and
rebuild it against whatever the project is afterwards — nothing at all, after <strong>Close Project</strong>.
That is what stops a screen showing values from a project that is not open any more, and it is also
why in-page state that was never saved does not survive one.</p>
@@ -158,16 +164,18 @@ the full text with whatever caption came with it. The icon in front decodes the
information mark for a plain status line, a green tick for a success, an amber triangle for a warning,
a red mark for a failure. The clock button beside it opens <strong>Recent messages</strong> — newest first, capped
at a hundred, each row repeating its severity as a coloured strip down the left edge and carrying the
time it arrived. That list belongs to this browser and this session: <strong>Clear</strong> empties it, a reload
empties it, and it is written down nowhere.</p>
<p><strong>Middle — the session strip.</strong> It is drawn only while a run has produced something, and the space is
simply empty the rest of the time. A glyph leads each line — a locator mark on a cursor tick, the
time it arrived. That list belongs to this browser and this session: <strong>Clear</strong> empties it and returns
the line in front of it to <strong>Ready</strong>, a reload empties it, and it is written down nowhere.</p>
<p><strong>Middle — the session strip.</strong> It is drawn only while a run has produced something, it is emptied by
a project change, and the space is simply empty the rest of the time. A glyph leads each line — a locator mark on a cursor tick, the
message's own severity mark otherwise — and an anchor follows it in a monospaced prefix wherever the
entry carries one: a cursor line carries <code>Sn</code> and the sentence index it sits on, a message line the
anchor the message itself supplies. Hovering opens the recent activity behind it; clicking pins that
list open.</p>
<p><strong>Right — the background zone.</strong> It appears only while a project file operation is in flight, names
the operation and the path it is working on, and vanishes when the operation ends.</p>
anchor the message itself supplies. Hovering opens the recent activity behind it — newest first,
capped at thirty, with a run of consecutive cursor ticks collapsed into its latest; clicking pins
that list open.</p>
<p><strong>Right — the background zone.</strong> It appears only while one of the <strong>Project</strong> menu's operations is in
flight — <strong>Close Project</strong> included — names the operation and the path it is working on, and vanishes
when the operation ends.</p>
<p>Switching the language re-resolves the interface at once and without navigating: the menus, the page
title in the bar and the browser tab title all change. The two message regions do not follow. Each
line in the recent list and in the session strip keeps the language it was raised in, so a footer read
@@ -188,9 +196,6 @@ healthy rather than every connection that exists.</p>
explain and none appears. The tooltip lists one row per connection, <code>Rendering</code>, <code>Shell</code>, <code>NcDiag</code> and
the rest, and those names are identifiers rather than interface text: in a translated session only the
state beside each name changes language.</p>
<p>The buttons that hide those panels' columns are remembered per page. The two tree pages each keep
their own column choices, while the dock widths and the list of unfolded tree nodes are single
settings both of them share — widening the dock on Execution widens it on General Setup too.</p>
<h2 id="see-also">See Also</h2>
<ul>
<li><a href="index.html">Basics</a> — the rest of what is true on every screen</li>