The Application Window
One frame surrounds every screen: a menu bar across the top, the current page between, and a footer along the bottom. The frame is built once and stays mounted for the whole session, so everything described here is present on every page. A project change is the one event that reaches into it and rebuilds what the middle holds.
The whole frame at /execution, with the demo project open. Only the column quick-toggles and the
connection badge, in the right-hand group, are there because of the page underneath them — the logo,
the three dropdowns, the page title and Show Log 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 Ready because nothing has been reported yet.
The menu bar
From the left: the brand logo, a version badge, and the Project, Page and Preference dropdowns. The badge is filled from the service's own reply about itself rather than from anything in a project, so it carries a version before a project is open. It is drawn only when that reply carried one, so a service that cannot answer its own status probe leaves the space empty. The bar is not drawn on the sign-in screen at all — the same version appears under the logo on the sign-in card instead.
The rest of the bar is pushed to the right, and renders in this order:
- The column quick-toggles — one button per column the current page actually has: four on Execution (the dock, the canvas-and-messages column, the Strip Charts column, the Step Info column), three on General Setup. Each glyph is a small map of the page with its own column filled, and each tooltip names the column it toggles. Tool House lays itself out with draggable splitters and gets no buttons here.
- The connection badge — the Execution page only. See below.
- The current page's title — the destination's own title, which is where one control reads differently from where it lands: Show Log opens the page titled Log Viewer.
- Show Log — present on every page.
- The sign-out button — labelled with the signed-in user name, or Logout when the service has no name for it. It is there only while the service asks for a sign-in and this browser has passed it.
The page area
Everything between the bars is the current page, and every page reached during a session stays built: there is no cap and nothing is excluded. Coming back to one finds its component state, an edit left half-finished and an established rendering connection exactly as they were.
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: the address (a ?tree= selection in it included), the layout the browser
keeps for itself, and the preferences the service holds — the language, Show Physics Options, and
which of the Execution page's charts, its Session Messages panel and its Step Properties
panel are switched on.
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.
F5 to F8 belong to the Execution page. 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 the screens the session had built go with it.
What a project change does
New, a Load that picks a different project, ReLoad, a Save As to a location other than the one already open, and Close Project discard every page the session has built and rebuild it against whatever the project is afterwards — nothing at all, after Close Project. 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.
What decides a rebuild is the path changing, not the action. A plain Save never rebuilds. Save As back to the path already open behaves exactly like Save and rebuilds nothing, while Save As to a different location moves the window onto that path and everything rebuilds. For the same reason, picking the already-open project out of the Load browser rebuilds nothing either — the file is read again on the service, but the screens keep what they were showing. ReLoad is the entry to use for that, and it is the one that always rebuilds.
The same rebuild runs once at startup, with nobody having done anything: a browser reaching a service that already has a project open receives that path as its first project change and builds on it.
New, Load, ReLoad, Save and Save As run one at a time. A second one started while the first is still running is refused rather than queued, and the refusal arrives as a warning reading Another project operation is in progress. Please try again. Nothing is rebuilt and nothing is lost. Close Project takes no part in that turn-taking and never raises the warning.
The footer
A 29-pixel strip holding three regions, each independent of the other two.
Left — the latest reported line, with the recent ones behind it. The text is the most recent message the application has raised, or Ready before there has been one, and its tooltip carries the full text with whatever caption came with it. The icon in front decodes the severity: a grey 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 Recent messages — 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: Clear empties it and returns the line in front of it to Ready, a reload empties it, and it is written down nowhere.
Middle — the session strip. 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 Sn and the sentence index it sits on, a message line the
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.
Right — the background zone. It appears only while one of the Project menu's operations is in flight — Close Project included — names the operation and the path it is working on, and vanishes when the operation ends.
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 after a language switch is a mixture by design.
The connection badge
The badge on the menu bar belongs to the Execution page alone; the other canvases carry their own badge inside their panel. It aggregates that page's rendering connection with the service connections behind its panels, and reads a green connected only while every connection in the set is up — orange while any of them is (re)connecting, and red only once none is connecting and one is still down.
The set is not fixed. The rendering connection is always folded in on that page, but a service
connection joins only while something is actually using it — an open panel, or the frame itself. One
that nothing is consuming is left out rather than forced to connect. ExecutionStatus has a consumer
for the whole session and is therefore always in the set; the rest come and go, which is why opening
and collapsing panels changes what the badge reports. A green badge means every connection in use is
healthy rather than every connection that exists.
Only the two problem states carry a tooltip — when everything is connected there is nothing to
explain and none appears. The tooltip lists one row per connection, Rendering, Shell, NcDiag and
the rest, and those names are identifiers rather than interface text: in a translated session only the
state beside each name changes language.
See Also
- Basics — the rest of what is true on every screen
- Signing In — what puts the sign-out button on this bar in the first place
- Projects — the Project menu, and what each of its entries does
- Finding Your Way — the Page menu and the screens behind it
- Preferences — the Preference menu, and the settings that are not in it
- Messages and Logs — the surfaces the footer summarises, and the log behind Show Log
- Starting and Stepping — the transport those F5–F8 keys drive, and the connection the bar's badge reports on
- Watching the Run — the two columns the quick-toggles show and hide