What one openable row of the wave selector stands for, which is both how it is styled and the key under which the model remembers whether it is open. A row is a group of components within one sheet instance, or the sheet instance itself. There were also cases for a single component and a single port, from when the list was nested a level deeper than it is; nothing has built one since, so the rows that would have used them are gone and only their styling and their summary text remained.

Whether the open design currently builds into a simulation, which is all the Simulation tab needs in order to decide whether its button reads "Start Simulation" or "See Problems", and whether to offer the waveform simulator. It is here, in the model, because answering it means flattening the whole hierarchy: the tab used to ask on every render, so a large design was flattened again for every frame it was visible. Now it is answered once per edit, on a delay, and the last answer stands while a new one is worked out - a button that is briefly a moment out of date, in exchange for an editor that does not stop. The verdict is reached by validateCircuitSimulation, which builds the graph and no FastSimulation, so answering it allocates no step arrays.

Elmish Model type for a rich text code editor

Groups components together in the wave selection table. NB: There are fields which are commented out: these can be added back in later on if we want to group those components together by type rather than separately by name.

Everything that could change what DATA the view needs from the .NET simulation, as ONE value derived by one pure function of the model (WaveSimTop.dataViewportOf). This record's field list IS the enumeration that has to be kept right, in one reviewable place: the fetch decision is an equality - current viewport <> the viewport the last COMPLETED fetch was for => fetch the whole current one - and no cache is ever consulted to decide. See docs/dev/sidecarInvariants.md.

How the components of an in-progress drag came to exist, if they were added at all. DragAndDrop is also entered when moving EXISTING components that end up overlapping, and by undo snapshots, so the drag settling back to idle does not by itself mean "components added". A paste is distinguished from a catalogue placement because its components must inherit the parameter slots of the ones they were copied from.

What a catalogue drag draws following the cursor.

A catalogue component being dragged onto the canvas, before it exists. Nothing is created until the drop, and where the catalogue item asks for parameters, not until that popup is accepted: what follows the cursor is drawn from a symbol that is never added to any model. That is what makes the gesture free to abandon - a drag ending anywhere but the canvas leaves nothing behind - and it keeps the popup in front of the component exactly as it is for a click.

Identifies which Component and Port drives a waveform. Must be an Output port (Input ports cannot drive waveforms).

Possible messages used by editor

What one fetch was for - recorded on its completion as what WAS fetched, never what is current by then. Each part is Some only when that viewport differed when the fetch was issued.

A gap in a waveform. Stores information about gaps between NonBinaryTransitions. Used in displayValuesOnWave, and also to store hatched information.

A text position interval in the code editor. This is used to represent the start and end of a selection or an error. All characters in raster scan order are considered part of the interval.

Which half of the window the keyboard is pointing at.

The draw block state a read-only sheet is held at, captured once the sheet has finished loading and written back over the live model after every message - see ModelHelpers.pinDrawBlock. Exactly the state a sheet is SAVED from, and nothing else. SymbolUpdate.extractComponent is the sole path from symbols to saved state, and it ignores Symbol.Appearance, so colour, opacity, port visibility and corner handles are all absent here and stay free to change: selection and hover go on working on a read-only sheet at no cost. The bounding boxes are here only because they are derived from the symbols, and would otherwise follow symbols that did not move. The two clipboards are here for a different reason: pinning them is what stops anything being copied OUT of a library sheet, since a copy writes the clipboard and nothing else. Whatever the user had copied before they looked inside survives, which is what they would expect.

Possible fields that may (or may not) be used in a dialog popup.

The project browser's state while it is open. Its own field rather than borrowed dialog text: the refresh timer has to be able to ask whether the browser is still open, and a timer that answered from shared popup state would go on writing into whatever dialog opened next.

Describe WaveSim's scrollbar's mouse actions' type of operation.

Information required to display a waveform. One waveform the viewer knows about: which signal it is, what it is called and where its data lies. What it LOOKS like is not here - see WaveDrawn, which memoises that as a function of this and the view. It used to be: every Wave carried its SVG and the five view settings that SVG had been made under, so the model held a picture of the screen that had to be kept in step with the screen, and "is this waveform up to date" was a question about the model rather than about what is drawn. What the .NET simulator is doing, as far as the renderer knows - and therefore what a synchronous question about it can be answered with. **This is the "is building" state that keeps everything else synchronous.** Building a design and running it are the only things a simulator does that take long enough not to be answerable while a frame is drawn, and both are commands the renderer issues. So they are modelled the Elmish way - a message that starts one, a message that says it finished, and this in the model in between - and every other question about the simulator is answered at once, with "nothing yet" exactly while this says a build is in flight. See the module note on SimInterface. It was module-level state in SidecarSession, on the argument that what another process holds is not model state. It is: what the renderer BELIEVES about that process is a fact about the renderer, the UI has to draw it, and a belief the view can only reach through a side channel is one the view cannot draw from. Identifies one asynchronous operation asked of the .NET simulator: sent with the request, returned with the answer, and the key under which the model remembers what the operation was. **Its own numbering, not the wire's correlation id.** `SidecarClient` gives every REQUEST a correlation id and the sidecar echoes it, which is how a promise finds its reply. An operation is not a request: a build is `sendDesign` - itself one frame per sheet - followed by `SimBuild`, and a fetch is a run followed by a read. One id per request cannot name a thing made of several, so this numbers the operations and `SidecarClient` goes on numbering the frames. Unique among the operations OUTSTANDING, not for all time. An entry leaves the table when its answer arrives and there are never many, so a uint32 wrapping cannot collide with anything still in it.

What an operation answered. One case per operation, so that an answer cannot be handled as though it were the answer to something else.

One asynchronous operation asked of the .NET simulator and not yet answered. It carries its own parameters, which is what lets one reply message serve every operation: the answer names the operation, the table says what that operation was, and the update function works out what to do from the two together. Without them there would be a message type per feature, each carrying the context its own handler happened to need.

The session the sidecar holds, which is what an operation commands. Not an operation in flight and so not in the table above: a build that has finished leaves a session behind, and it is the session that the next run or read names. Whether a build is RUNNING is read off the table (`ModelHelpers.sidecarIsBuilding`), so there is one place that says so rather than a state here that could disagree with it.

Which instances' port SLICES the selector and wave reconciliation need - the structure viewport beside the data one, separate because its lifetime is the build's: it only ever grows under one epoch, where the data viewport moves with every scroll.

Which dropdown on the renderer's own menu bar is open. Edit and View hold what used to be on the Electron menus of the same names.

Contains all information required by waveform simulator. One WaveSimModel per sheet.

Determines whether the user is able to see the wave viewer pane. Changes value depending on the state of the circuit and whether the wave simulator has been run.