[Qt-interest] The State Machine Framework - do's and don'ts

[Mihail Naydenov]

Hello, I have a simple, but important question about The State Machine Framework.
A question about scale.
Its obvious to see the app being in some (macro) state - browsing, crating, editing, saving etc.
But its also easy to spot (micro) states in every possible component - a stupid push button is also in two to three states (hover, press, release ), an input field may has "typing", "selecting", "selected", "empty" etc. some panel holding these itself may have states (open, closed, dragging etc). And these are just the visual components... Its easy to see one can "abuse" the state machine for every thing that "looks different" in time... or does he?

Question is what are the right usages - the do-s?

Studying the examples in Qt source one can note, all of them are more or less macro states examples, except when they showcase a concrete feature.

All except one - the sub-attack.

Compared to all other examples this one (being a demo) looks like an abuse - it has both micro and macro states for all possible actions in the game.
None (IIRC) of the other examples for instance has more then one state machine, but this one creates (and destroys) not only new states, but also a new state machine for every tiny 20px torpedo and depth charge on the screen! At time it can have possibly 10 state machines running and even more states!
Now I am puzzled.
 Is this a case study -  pushing the max of the SM?... 
Or a glimpse in the future - where every button will be state aware, and the UI - state driven?
Or just a toy.

Though Im sure it the last of the three, it will be very helpful to have some general guidelines about using  State Machine Framework.
At the very least some relative performance and scaling metrics.(The cost of multiple states and states machines running.)

Is using micro states an abuse or "a glimpse in the future" after all?

Thank You
MihailNaydenov