Interaction between model and self-modifying data in Qt MV

Question

I have a tree structure that represents a system of devices that are connected to the PC via serial port. In a way, this structure was inspired by tree model example in Qt and I think that helps to separate logic part from gui. My model has a root node member, and can access all underlying nodes through the root node. Some nodes should do their work automatically (i.e. send commands to the serial port on timer). Routine tasks for the application are ordinary:

1. Notify model when state of a node had changed.
2. Notify model when the structure of the tree was modified, a node has added a new child node or has removed a node.

Each node has pointer to the root and can emit signals about any changes. So the root node is some kind of the interface for the tree. Now i'm struggled with the crashing when removing a child node and notifying model about that. Actually I solved this problem, however I think it's something wrong in the design. So I want to ask how best to implement interaction between my data structure and the model.

Some questions are: should data structure be able to perform some actions on itself (add or remove nodes) and just notify model about changes, or that should be strictly performed by the model on appropriate request from the tree?

I use Qt, signals and slots, is it bad if my structure would rely on QAbstractItemModel mechanics - use signals like nodeIsAboutToBeRemoved / nodeRemoved to prepare model for corresponding actions?

Update, about the structure I'm using. I don't insist tree is the best or the ideal structure for my purpuses. There were two thoughts about the tree - it's naturally represents the real system and it's easy to use Qt's models and views (both tree and table views). Finally, the tree idea was accepted by chiefs and colleagues. My tree is 5 levels now: root - hub (represents serial port) - coordinator device - terminal device - sensor. Later, new level may be inserted between coordinator device and terminal, and a hub class may be reimplemented for using something else instead of serial port or to use another protocol. There is no multithreading now and it's not planned, but it seems to me, multithreading can be injected relatively simple and natural. Each hub controls serial poort settings. Node at each level knows about all child nodes and so it knows how to form a set of commands to survey physical devices. Each node can hold it's state (is it accessible at the physical level or not) and pass this state to children or just control their behaviour.

Answer 1

What purpose does this tree structure server?

Why not just have linked list of devices?

Then, you have a communication hub class. Each device has a reference to the communication hub, which allows devices to subscribe to events of their choosing, as well as triggering them.

Having everything talking to each in some sort of tree sounds overly complex and unnecessary. Mathematically, it is much less efficient. The only drawback to a central hub model is, if you are using multi threading, a lot of cycles could be wasted on locking code in the hub; however, the tree model has this problem as well, even if it to a slightly lesser extent.

Answer 2

In Qt's MV each view displays a single model.

Typically I implement this by making a model a composition of the data structure items. Then the data structure items inherit QObject and send notifications using the signal/slot mechanism. This has the added benefit that Qt's signals and slots are threadsafe should you need multithreading. You could either propagate the changes upwards and make the root node notify the model or pass the model pointer around to different nodes and notify it directly.

The whole thing slightly changes if you have some sort of a detail view - then you might need a model for each item.

All this sounds like some sort of non-persistent data - I wouldn't bother about separating the data from the model implementation unless it is a huge project.

In your project each level of the tree represents a different type of object so you would represent them with separate classes.

Data changing itself is possible but you need to signal it properly - otherwise you get crashes.