The event state machine is a bit harder to document than I expected. Below is my attempt. Each event has a handler. There are several identifiable states where a specific set of event handlers are enabled.
I believe the original code had a unnecessary states where it enabled hovering to highlight pins (selectPin), but didn’t enable the click event (pinSelected) until there was hovering over a pin. I documented this below as a single state, since I think that would be a better approach.
BBUI events: (name - EventListener type)exit - click
exitHover - mousemove
activateBtn - mousemove
digitalMenu - mousemove
btnInfo - mousemove
selectPin - click
pinHover - mousemove
clicked - click
clickDown - mousedown
clickDownDigital - mousedown
slideBar - mousemove
zooming - mouseup
stop - mouseup
record - mouseup
pinSelected - click
release - mouseup
The event names above are from the original code. I already renamed activateBtn to activateProbe. I did this to distinguish “buttons” which are in the menu at the top that you can select and drag into the active area and “probes” which have already been dropped in the active area and represent an array of assigned data collection and/or generation.
There are other cases where event handlers themselves adjust the event listeners unconditionally and I believe it would make more sense to adjust the event listeners at a single state transition point.
I think it is easiest to define the overall state machine by breaking it into a top-level state machine and a number of smaller state machines. The smaller sub-state machines are able to be activated once the clickDown event handler is enabled. I believe they are otherwise independent.
Top-level BBUI event states:
INIT - exit, exitHover
IDLE - clickDown, release, clicked, btnInfo
DM - clickDown, release, clicked, btnInfo, digitalMenuDMH - clickDown, release, clicked, btnInfo, digitalMenu, clickDownDigital
ADD - activateBtn, release, clicked
SEL - selectPin, pinSelected, release, clicked
OUT - selectPin, pinSelected, release, clicked
I believe the OUT state, where you select an output to go with an input, is unnecessary. I believe simply monitoring the input via the graph is sufficient and tying it to an output isn’t necessary. If you were going to tie it to an output, I’d think the LEDs would be most useful, but it should be fully optional. This is to be resolved at a later point.
When the clickDown event is active, the following sub-states can be enabled/disabled without affecting the top-level BBUI event state:
SLID - sliderBar
ZOOM(in/out) - zooming
STOP - stop
PLAY - record
There is some additional global state, such as if a probe is on or off. I haven’t documented that here because it doesn’t adjust the state of the event listeners.
I believe the next step in the state machine documentation is to define the conditions upon which the state transitions occur. It should be clear it only happens within an event handler/listener, but the conditions for a state transition should be defined.
One of the main reasons for this re-write is to isolate the state machines from the conditional code such that the state machine can be readable in a terse manner. I’m hopeful understanding this state machine will result in accelerated development of the BBUI code.
