BBUI event state machine

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.

Some more comments…

I created a state diagram that can be edited as part of the bone101 code base at http://beagleboard.github.io/bone101/Support/bone101/UI/fsm/. I’ve saved a copy below for some discussion following it…

pasted1.png

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)

I used different names in the state diagram to save space in the drawing as well as help with some clarity (event type as part of the name).

Per the IRC discussion, the short-hand is as follows:

c - click
h - mousemove (hover)
cd - mousedown (click down)
r - mouseup (release)

For the objects on the screen, I’ve used the following short-hand:

e - exit button
l - leds button
a - analog button
p - power button
g - ground button
d - digital button
dm - one of the digital menu buttons, such as the digital button, input, output or pwm
active - the area where the buttons are dropped to create the probes
pin - one of the pins appropriate for the state
onOff - one of the onOff buttons on the probes
slider - one of the slider bars on the probes (used to set the timer interval for generating outputs)
in - the zoom in button
out - the zoom out button
play - the play button
stop - the stop button

Combined, the state diagram event names correspond to the event handler names in the code as below…

exit - click

c(e)

exitHover - mousemove

h(e)

activateBtn - mousemove

h <— I will add this to the state diagram. This handler is active in the ADD state and never generates a state transition. It is used to draw the button being dragged down into the active probe area.

digitalMenu - mousemove

h(dm)

btnInfo - mousemove

h(l,a,p,g)

selectPin - click

c(pin)

pinHover - mousemove

h(pin)

clicked - click

c(onOff) ← I made a mistake on the drawing and put it as cd(onOff) and will correct it.

clickDown - mousedown

cd(X) ← every mousedown event option except for cd(d)

clickDownDigital - mousedown

cd(d) ← I’ve used the syntax cd(X|d), namely cd(l,a|d) with the vertical bar to show 2 different event handlers causing the same state transition.

slideBar - mousemove

h(slider)

zooming - mouseup

r ← This event handler isn’t unique, but the original author decided to use the event handler state to manage triggering the desired behavior. I think this is ugly coupling as the event state and UI state are better off in isolation to make the code the most readable.

stop - mouseup

r ← Again, nothing interesting about this event except the state that enables it.

record - mouseup

r ← Same as noted above

pinSelected - click

c(pin)

release - mouseup

r ← This one handler seems like the logical place to handle the zooming, stop and record button releases. This is a simple fix.

well, I got some hints in my current version and managed to remove pinHover event and use (selectPin & pinSelected) instead for hovering and selecting specific pin.

Could you explain using ( c(pin & in ) ) in state machine, why did you use ‘zoom in’ button with pin click ?

pasted1.png

If adding an input probe, the current design adds an output pin to the input probe. You should try it.

pasted1.png

Is that OUT state need a new event handler?

No, the cPin (forgot the old name) handler works fine.