Question

Greetings,

We are developing a scientific QT Application which detect the border of a cell.Please refer to following prototype snapshots.

Now ,we are going to develop this as a opensource product with a good design and architecture.We reconed that it has many complex actions and flows.
Eg: move contour node,delete coutour node,add contour node,draw barrier,select multiple nodes…etc

We were hoping to use QT State Machine Framework for UI, and wondering whether to use several state-machine instances for each flow/action or use one “huge” state-machine?
We need unde/redo operations and is it possible to interate QT State-Machine Framework with QT Undo/Redo Framework?

[edit] Is it really possible to use QT SM Framekwork to handle UI interactions?
What kind of design they use in GIMP or CAD applications ?

Thanks in advance,
umanga

Answer 1

I believe the state machine wouldn’t really be the right choice to represent the user interaction. It is suited to easily model changes in the user interface itself.

What you probably need is a combination of the state machine and the Command design pattern, which in Qt is partially implemented by the QUndoStack and QUndoCommand classes. The state machine tracks changes to the user interface itself, and the Command classes track user interaction. I don’t know a lot about detecting cell borders and I don’t know how you are planning the interaction model in your app, but let me try a make-believe example just to clarify.

Example

Suppose your app has two different algorithms to detect a cell border starting from a rough estimate provided by the user. One takes a rough point-by-point path around the cell. The other takes a freehand contour. You also want to allow the user to add callout notes to the cell image. Suppose you also don’t want to clutter the user’s screen with tools she won’t be using right now.

You then have three different interaction modes and each has different actions (or tools) the user can employ:

1. Point by point. The user can add a point, remove a point, move a point around, select points, and refine the border.
2. Freehand. The user can draw with a “pencil” and an “eraser” and refine the border.
3. Callout notes. The user can add a note, remove a note, move the note around, reposition the note’s arrow, and edit the note’s text.

Besides providing tools, the first two modes might also allow the user to tune the algorithm’s parameters.

An approach would be to represent each of 1, 2, and 3 as a state in a state machine. On entering one of the states, it causes the tools to become visible. When a state is exited, it hides its tools. Changing states can be accomplished with toolbar buttons, for example.

Now, when a tool is used and changes the model underneath, it also stores a QUndoCommand in the QUndoStack. Suppose the user is in freehand mode. Now she switches to point-to-point mode, tweaks a parameter, adds two points, moves a point, and then deletes it. The undo stack might look like this, bottom to top:

1. Switch from freehand mode to point-to-point mode
2. Change Parameter ε from 0.00001 to 0.002
3. Add Point #1 at (120, 40)
4. Add Point #2 at (403, 11)
5. Move Point #1 from (120, 40) to (350, 120)
6. Delete Point #1

Notice that the state change was added to the undo stack so that undoing a series of commands leaves the user exactly where she was when she issued it. For example, if she un-did all the way back to 1, she would be back in the freehand mode.

To sum it all

• The state machine in Qt is appropriate to track changes in the user interface.
• The command design pattern is appropriate to track changes made by the user in the underlying model.