The window

The frame around every page: the title bar with its theme keys and user chip, the navigation rail and what shows each entry, the status bar and its action feed, the stopped-runtime band, notifications, the crash-consent dialog, the screens a lost connection shows, full screen and the system tray.

Every page of Ganter Lab is drawn inside one frame: a title bar, a navigation rail on the left, the page itself, and a status bar along the bottom. The frame is the same on every page and on every screen that looks at the station, the station's own window and a browser on the network alike (see Remote access); the few places where the two differ are called out below. Seeing the frame needs no permission, but several of its entries and marks are drawn only for an identity that holds the matching permission, exactly as the pages behind them are.

The frame at a glance

The window opens no smaller than 880 by 520 pixels and remembers where you left it (position, size, maximized) between launches; see First launch.

Title bar

The Help key

A question mark at the left of the title bar's right-hand group, past a thin divider from the theme keys. It opens the help panel described under Contextual help and marks itself while the panel is open. It is drawn on every route, for every identity, and while the runtime is stopped.

Theme keys

Three keys side by side, in this order, each with a tooltip that names it:

The raised key is the stored preference, never the appearance it resolves to: System stays marked as System while it looks like Light or Dark. Pressing a key applies it live to the screen that pressed it and saves it as the station's preference in the configuration database; Settings, Appearance shows and changes the same three values. The preference belongs to the station, not to the screen: the station's own window follows a change made from a browser at once, and another browser picks it up when its page is loaded again.

The user chip

To the right of the theme keys, past a thin divider, the chip names who is signed in on this screen: Sign in while nobody is, the display name once someone is. The dot on the person glyph is green while signed in and grey otherwise. The chip is always drawn, on every route and every screen, because roles are always in force and not being signed in is an identity of its own (the "Not signed in" role).

Pressing it opens the sign-in dialog:

• The title reads Sign in, or Switch user while someone is already signed in and the roster is showing. In that case a header line "Signed in as name" carries a Sign out button.
• The roster lists every local user with a two-letter token, the name and a mark: a lock for a user with a PIN (tooltip "PIN required"), an arrow for a user without one (tooltip "Signs in on tap"), who is signed in the moment the row is pressed.
• A user with a PIN opens the PIN step: the user's token and name, Back, the eyebrow "Enter PIN" and a keypad taking 4 to 6 digits. The check key or Enter submits.
• A refusal stays on the keypad, in place: "That PIN is not correct.", or "Too many wrong PINs. Try again in n seconds/minutes." Five wrong PINs in a row close the door for a minute; each further run of five doubles the wait, up to fifteen minutes.
• With no local user on the station yet, the dialog says so instead of showing an empty list: "This station has no local users yet. The first one, the primary administrator, is created on the Users page."

On the station's own window the chip changes the station session, the identity every command of that window runs under; in a browser it signs that connection in and nothing else. Either way the outcome also lands in the status bar's action feed ("Signed in as Ana.", "Ana signed out.", "Sign-in refused. Still signed in as Ana."), because who is signed in decides what every other command may do. The whole flow is described under Signing in.

Navigation rail

The rail is 64 pixels wide: a glyph and a label per entry, the active entry highlighted. Each entry is drawn only when the identity on this screen holds at least one of the permissions listed; the pages themselves check again when opened, so the rail only trims what would be refused anyway. The permissions are the switches of the role editor; see Permissions.

With nobody signed in, the "Not signed in" role decides. Its factory permissions hold everything except Manage local users and Remote access (LAN), so a fresh station draws every entry until an administrator narrows that role under Roles. When a role change removes the entry of the page you are on, the shell moves you to the first entry it still draws.

Two entries carry a mark:

• Validation wears a caution pill with the number of items to repair (99+ past ninety-nine), hidden while the configuration is clean. It follows the validator's background rescan, so it changes as you edit; see Validation.
• Account wears an exclamation mark only when the license needs attention: amber when the subscription is past due, ends within 14 days, or has no known end date while set to end; red when the subscription is canceled, or when it could grant a seat but this station holds none. Pressing the marked entry lands on the Subscription section rather than the top of the page; see Subscription. There is no neutral "connected" dot.

Status bar

The bar reads, left to right: the indicator group, the action feed in the elastic middle, then the release mark, the version and the clock. It refreshes every second.

The indicators

The health dot follows the same colours as every state dot in the app: green for healthy, amber for degraded or starting, red for faulted or offline, grey for neutral. The system tray icon reads the same server health (below).

The action feed

The middle of the bar is the one place where the result of what you just did lands: a save, a delete, a rename, an import, a print, a scan, an acknowledgement. Every command that changes state reports both outcomes, when it worked and when it was refused.

• A success fades on its own after six seconds. A failure keeps a red mark and stays until a newer result replaces it or you press its Dismiss (x) button.
• The text ellipsises against the clock; the full text is the tooltip.
• An entry may carry one follow-up button beside it, for example Undo after removing a dashboard component. It lives and dies with the entry: the entry's expiry, the next result, a dismiss and the press itself all take it away, so the bar never offers a verb that no longer answers the text beside it.
• The feed belongs to the connection: this screen shows the results of what this screen did, never what a browser elsewhere did. The station's own window additionally carries the work no screen asked for (an automatic backup, a report generated on its own, a failure of the host).
• The one exception: a command pressed inside a dashboard component (a Button, a Toggle, an Input) answers under that component, the surface that still exists when a full-screen dashboard hides this bar.

Pages never grow a "Saved" flash or a status line of their own; if you are looking for the answer to a press, it is here.

The release mark, the version and the clock

• A new release waiting to be taken is one quiet line beside the clock: "Version 1.5.0 available", or "Version 1.5.0 · important fixes" in the caution tone when the release is flagged as carrying important fixes. The tooltip adds whether it is already downloaded ("It is downloaded and installs the next time Ganter Lab restarts.") and where the press leads: Settings, Updates. The mark is drawn only for an identity holding Change settings or Edit dashboards, so an operator at a remote tablet never sees a decision that is not theirs, and never on a build without an update feed.
• The version running now, in the same quiet tone (tooltip "Settings: About"); About shows the same number.
• The clock: the local date and time in the formats chosen under Settings, Localization (for example dd/MM/yyyy HH:mm:ss), ticking every second. The tooltip reads "Settings: Localization", which is the section those formats are set in.

While the runtime is stopped

Health, alarms and recordings cannot be asserted while nothing is being read, so the indicator group gives way to one message that leads somewhere useful: "Sign in for a longer free window" or "Add a license to remove the limit" (both open the Account page), or, with nothing left to buy, "Restart the runtime to continue" on the station's window and "The restart happens at the station, the computer running Ganter Lab." on a browser. The countdown stays first on the left, reading "Free · runtime stopped".

The stopped-runtime band and the paused page

When the free-mode window runs out the runtime stops (see Free mode and the license), and the shell says so once, in the same way on every route and on every screen:

• A band under the title bar: Runtime stopped, "Acquisition, Logic and recording are paused. Your configuration and recorded runs are intact.", and the one Restart runtime button. The button exists only on the station's own window: a browser reads "The restart happens at the station, the computer running Ganter Lab." in its place, so a free-mode window can never be reset from the network.
• Every page except Account gives way to a paused notice: This screen is paused, "It reads the station live, and nothing is being read while the runtime is stopped. It waits here instead of showing values that are no longer true.", then "Restarting is immediate and unlimited. The runtime is back the moment you ask for it." on the station and "The station operator can restart it at any time, without limit. This screen comes back on its own." elsewhere. Account keeps its page, because signing in or adding a license is what removes the limit.
• A dashboard in full screen leaves it, so the band and the rail are on screen.
• Every command that would change the station is refused with the same two words, "Runtime stopped": on the toolbars, in the menus, on snackbar buttons (greyed with that tooltip) and at the agent endpoint.

A restart that fails raises a warning notification, "Runtime restart failed: The runtime could not be fully restarted. Review Events and try again.", and the button stays for another attempt.

Contextual help

The Help key opens a panel on the right, next to the page rather than over it: the page keeps working, so the instruction can be carried out on the screen it is about. On a narrow screen (a phone, or a tablet held upright) the panel takes the window instead. Escape closes it, as does its own close key, and the focus goes back to the Help key.

What it shows is the documentation page for what is in front of you. The route decides it, so opening the panel on Logic opens the Logic page of this documentation; on a page read as one long column (Settings, Agent, Account) the section you have scrolled to decides instead, so Settings at Backups opens Backups. Moving to another page, or to another section of the same one, brings the page that belongs to what is now on screen rather than leaving the previous article standing over it.

The panel carries the page's title, its summary, the list of its sections and its whole text. Links to other pages of the documentation and to sections open inside the panel; a link that leaves the documentation opens in your browser. The panel's own Open the full documentation key opens the same page on the website, in the same language and for the version this station runs; it is the one thing here that needs a network.

The documentation is installed with the application, not fetched: it is the documentation of the version you are running, in the language of the station, and it opens with no internet connection at all. A browser on the network reads the same pages from the station, so a screen on the shop floor is never left without them. When a package carries no help for the running version or the station's language, the panel says which version and which language it looked for instead of opening something else, and the same line is written to Events, Console.

Notifications

Snackbars

Interrupting notices stack bottom right over the page, newest on top. Each card carries a coloured accent for its severity (Info, Warning, Error), an optional title, the message, any action buttons and a Dismiss (x). A card is sticky unless whatever raised it gave it a timeout. While the runtime is stopped, a card's button that would change the station is greyed with the tooltip "Runtime stopped".

What raises them, among others:

Snackbars are for what interrupts; the result of your own action is never a card (see the action feed above).

Windows notifications

The cards live inside the window, so while the window is hidden to the tray or minimized the same moments also raise a Windows notification: an alarm activation ("Priority alarm: name"), an interlock trip, the free-mode warning and the stop, a server or restore failure on a hidden boot, and the one-time hint on the first hide. Clicking the notification opens the window, where the card is waiting. These notifications exist only on an installed build; a portable or development copy keeps the in-window cards alone.

The crash-consent dialog

If Ganter Lab closed unexpectedly, the next start that shows the window opens Send crash report? over the page (a start hidden to the tray waits for the next visible one):

• "Ganter Lab closed unexpectedly last time. Sending this report helps us fix it. It contains the error and a short slice of the recent log. Review it below before sending."
• Crash detail: the whole payload that would be sent, with a Copy button ("Copied" for a moment). The payload is the capture time, the context, the app version, the operating system, the exception with its stack, and the last 60 lines of the log, scrubbed of the Windows user name and profile path. Nothing else leaves the station.
• Always send crash reports automatically: opts into sending future crashes without asking (the same switch as Settings, Crash reports). It is greyed with "Runtime stopped" while the runtime is stopped, because the opt-in could not be saved.
• Don't send clears the captured crash so it is not offered again. Send report sends it; a send that fails keeps the crash and asks again on the next start. The report is attributed to your Ganter account when the station is signed in, and accepted anonymously otherwise.

The crash is kept as crash\pending-crash.json under the data folder until it is sent or declined.

When the screen loses the station

The page is served by the station live, so a screen can lose it: the connection drops, the station restarts, the page hits a fault. A browser on the network meets these screens most; the station's own window is served the same way and can show them too.

• The circuit banner. A page that fails inside a running screen shows a quiet band at the bottom: "This page hit a problem, but the app keeps running. Details are on the Events page.", with Reload and a dismiss mark. Nothing is lost; reloading reattaches.
• The reconnect card takes the whole screen while the connection is gone:

• The window could not be served. The station's own window is served from a port inside the machine. When that port cannot be opened (almost always a second copy of Ganter Lab already running), the window paints its own notice instead of a blank page: Ganter Lab could not open its screen, "The app is running and your devices are still being read. What is missing is the screen…", the port, what the system reported and the log folder. It retries every five seconds and opens on its own once the port is free.
• Not found. An address that matches no page lands inside the frame: This screen isn't part of this station, "That address doesn't match any screen here. It may have been renamed or removed.", with Go to Home, which opens View.
• Sign in to view. A browser on the network whose identity lacks Remote access (LAN), or any screen whose role does not open the page it asked for, gets the sign-in card in place of the page ("Sign in to view this station from the network." or "Sign in to open this page."), naming the identity that was refused. Signing in renders the page that was asked for. The station's own window and a browser on the station's machine are never gated by remote access.

Full screen and Expand

A dashboard on View, and a unit's panel or screen under Process, can hide the frame in two ways, both on the trailing cluster of the dashboard's bar:

Both verbs are greyed while no dashboard is open and are not drawn while a dashboard is being edited: entering one would end the edit without saying so. Whether the status bar stays at the bottom in either mode is the dashboard's own setting (see Dashboard settings). The modes are exclusive: pressing Full screen while expanded upgrades rather than toggles.

Keys: F11 toggles Full screen (and does nothing while editing or while a folder is open); Esc leaves, innermost first: a folder being renamed, then the navigation overlay, then Full screen, then Expand. A browser leaving full screen by its own gesture takes the mode with it. Leaving the dashboard route restores the frame, and a stopped runtime leaves full screen so the band and the rail are back. A chart's own Full screen tool fills the monitor the same way (see Charts); Esc closes the chart first. More under Full screen.

Desktop zoom

In the station's own window, Ctrl + mouse wheel zooms the whole surface in the browser engine's native steps (each step multiplies by 1.2, between 25 % and 500 %) and Ctrl + 0 returns to 100 %. Every change is announced in the action feed ("Zoom: 120%") and saved at once, per installation, in window-placement.json under the data folder (never in the configuration database, never in a backup). Settings, Appearance shows the current level and resets it. A browser keeps its own zoom.

The system tray

Ganter Lab is always on: closing the window hides it while the embedded server, acquisition and recordings keep working (unless "Keep running in the background when closed" is off under Settings, Startup, in which case the X exits). The notification-area icon is the brand tile with a health dot mirroring the embedded server, the same reading as the status bar's health: green online, amber starting or partial, red offline, grey otherwise. Its tooltip reads "Ganter Lab: state", with "(recording)" added while any run records (checked every 15 seconds).

• A left click opens the window; a right click opens the menu: Open Ganter Lab, a read-only line "Server: state (recording)", and Exit. There are no start or stop controls in the menu: a stray click must not take down the clients reading the server.
• The first time the window hides, a Windows notification says "Ganter Lab is still running: The server and recordings keep working from here. Click the tray icon to open; right-click to exit." It is shown once, and only counted as shown once it was delivered.
• Exit stops everything through one teardown: agent access, the web host, the monitors, the process runtime (runs stay resumable), the embedded server, the logic runtime (retained values are flushed), the event journal and the host. While a recording runs the window comes back first with a calm confirmation, A recording is running: "Exiting stops data acquisition. Everything recorded so far is saved and reopens the next time you start Ganter Lab, but nothing new is recorded while the app is closed." Keep running is the default; Exit anyway proceeds. A downloaded update installs on the way out.

What the frame does not do

• It never hides Users from a non-administrator; the page carries its own notice instead.
• It never offers the runtime restart anywhere but the band, and never on a browser.
• It never shows another screen's action results, and never turns an action result into a card.
• It never changes a remote browser's theme until that browser loads its page again.
• The help panel never reaches the website to show an article, never opens a page written for another version, and never falls back to English for a language the installed help does not carry.
• The Help key, the theme keys, the chip, the rail and the status bar are the frame's only controls; every verb over a thing you are configuring belongs to that thing's page (see How the pages work).