Preview and simulation

Driving the design with made-up sensor readings before the hardware exists.

The Play button in the toolbar turns the canvas from a drawing into a working screen. Widgets become operable, events run, bindings run, and a drawer opens with the inputs the firmware would be reading. It is the fastest way to find out whether the logic does what you meant before anything is compiled.

What becomes operable

Sliders and arcs drag to a value - a range slider moves whichever of its two knobs you press nearer to, and a reverse arc counts from its end, as they do on the device. Switches and checkboxes toggle. Dropdowns and rollers cycle through their options. Spinboxes step. Tabviews switch tabs.

Buttons - and anything else you click - are drawn in their Pressed style for as long as the mouse button is down, and fire their events in the device's order: Pressed on the way down; Long pressed after 400 ms, then Long pressed repeat every 100 ms while held; and on release, Released, Short clicked (unless it was a long press) and Clicked. A widget with the Checkable flag toggles its Checked state on release, so it stays in its Checked style and fires Value changed, then Checked or Unchecked - the same fan-out a switch gets.

The data drawer

The right-hand drawer has two halves. Simulated inputs lists every hardware source the project reads - each peripheral channel, analog input and digital input - with a control to set its value, since the browser has no sensors. Variables shows every variable's live value as the formulas compute it, in the variable's unit and decimals. Reset simulated values puts the inputs back to their defaults; the drawer can be hidden and shown again from its header, and sits beside the canvas rather than over it, so zoom-to-fit adapts.

Move the simulated BME280 temperature and a bound label re-formats. Drag a two-way-bound slider on the canvas and its variable changes in the drawer.

Order of operations, and why a slider snaps back

The preview mirrors the firmware exactly: your interaction is applied first, then read bindings on top. A Variable → widget binding therefore overwrites what you just dragged on the next tick - which looks like a bug until you remember that bindings_apply() does the same thing on the device every refresh. A slider that should hold its position wants a Both ways binding, and then the preview shows it holding.

Events run

Click a button and its Clicked actions really happen: the screen changes with no animation but to the right target, a flag toggles and a panel appears, a slider increments, a variable is set. Actions the browser cannot honour - Play Animation, Switch Theme, Write to peripheral, Set digital output - are logged to the Console tab with what they would have done.

Swipes

A mouse cannot swipe. A pad at the bottom of the canvas has the four directions; each arrow sends that gesture to the screen and to every widget listening for it, and each arrow shows a count of the handlers it would reach, so a dead arrow reads as dead rather than looking broken. A fifth control sends Gesture (any).

Nothing sticks

Everything the preview changes is held in a separate overlay - values, checked states, the current screen, hidden flags, colours and opacities set by actions - and the overlay is discarded when you press Play again. Nothing you do in preview dirties the project, lands on the undo stack or changes a widget's stored value. Automations are not run: they are firmware-side and depend on real time and real pins.

What it cannot tell you

Whether the wiring is right, whether the panel is inverted, whether the touch axes are swapped, whether the draw buffer fits, whether the sensor answers on that address. The troubleshooting page is for the first boot; the preview is for the logic.