I'm building a desktop app in QT (although that may be irrelevant) and I'm having a hard time working through the class structure and layout. The data model is fairly simple with a root container with a number of containers of items. Consider the following representation:
Root
+ Parent
+ Child
The UI is fairly simple and follows that data model with a main window with a scrollable area (root), widgets that contain layouts (parents) of custom widgets (children) with some labels and buttons.
My trouble is with handling events that need to go up the chain and then back down like moving a child from one parent to another, moving elements, or updating child meta-data that impacts several to many other widgets.
I'm currently splitting UI widgets and model objects but having each widget and corresponding model object pointing to and from each other feels cumbersome and I think it is leading to too much maintenance.
I'd suggest following a standard MVC pattern and ensure there are no dependencies from the model to the view; in your case this would mean that while there is a widget for every model item, the model items do not reference their corresponding widgets.
While the MVC pattern has many flavours, one way to accomplish this would be to have a view class that monitors the model for any changes and updates the view accordingly (this can be accomplished by connecting a slot in the view class to a signal emitted from the model class). Any changes the user initiates through the view can then be:
1) handled directly by the model
through a simple signal/slot
connection
2) handled
by a controller class which can
direct the model to update accordingly
Either of these would then cause the model to emit an update signal which would cause your view to update. The benefit of this is the ability to change your view (or add additional views) without having to update your model.
I'd recommend reading Qt's Model/View Programming Guide to better understand how MVC works in Qt and to see if there's an existing class or interface (e.g. QAbstractItemModel) that you could use instead of baking your own.
Consider using factory pattern and command pattern. There are plenty of samples. I am just giving a hint here.
http://en.wikipedia.org/wiki/Factory_method_pattern
http://en.wikipedia.org/wiki/Command_pattern
Forgot mention about qt book: cartan-cas-dot-suffolk-dot-edu/oopdocbook/html/
Related
I may be bordering on a discussion type question here so I apologise if the question is not specific enough.
I would like to know if I my current application design is inherently weak/flawed. My background is C so I am not using clever c++ patterns to their fullest extent, of this I am sure.
My application is similar to a 3D modelling package, without geometry creation (e.g setting up animations using existing models). The user imports a geometry and can set various parameters on pre existing geometry, and there are time dependent values that relate to the whole system. The output is a text file to be processed by another application.
I am using a QTreeview to render a QStandardItemModel. I simply store pointers to my core classes in the model's items. These have specific UI for each class type, and are all descended from a common base class. They all have a QWidget which is their "mainwidget"
When the user clicks on part of the treeview, the stored class is retrieved and its mainwidget is displayed on a pane on the UI. So - treeview on the left, pane to the right with the current item's contents, and a 3D view showing the geometry.
Most of my data is stored in the classes UI elements themselves; I don't have a central database which stores anything, and when it's time to save the project, I traverse the tree and let every item write itself to a QSettings file. This feels quite naive but it does work, and the reverse happens on project load. The project class generates new classes based on the type information in the settings file and they then read the contents out of the file themselves.
Similarly when writing the output file, each item knows how to write itself and does so. Where other classes can influence the output of others (for example, start and end times), higher level classes process the children and will set start and end times based on the order and duration of each child.
Should I be storing more data in the QStandardItemModel itself, or defining my own model perhaps? Does it sound like I have set myself up for future problems?
At the moment I have modified this system a couple of times to provide customised applications, but I am about to try and make it more generic. I welcome suggestions for improving my design. Go easy, please!
You should try to avoid creating god objects. Split your tasks and duties into smaller chunks. It makes it much easier to maintain and also much easier to extend if you need to.
Your specific use-case would benefit a lot from a more complete use of the Model-View-Controller pattern.
What doesn't make sense in your design is that your data objects hold a UI element. Since only one item can be shown in the right pane, this seems like a waste of resources. It makes more sense to have a single object that then gets passed a data object to display.
What I suggest for your program is the following:
Splitting your data into classes that only have functions for reporting and modifying values. There should be no knowledge of how to display data or store to a file.
Create separate class that handles the reading and writing from a file. If your model is very simple, you could just use single functions to do this using the method shown in the documentation for QDataStream or QTextStream.
Use your QTreeView and QStandardItemModel as Adaptor class between your data objects and the left pannel.
Create a controller class that gets informed by the QTreeView if data needs to be displayed in the right panel. The controller will then retrieve the data item and pass it to the right panel in order to be displayed.
The right panel should act like another View class with the sole responsibility of graphically displaying the data passed in from the controller class.
One advantage of doing it this way is that, if there are different categories of data that get displayed differently in the right panel, the controller could examine the selected data item, determine what the category is, create a view widget to put in the right panel, and then pass it the data to display.
This pattern is open-ended as far as extendability is concerned because you do not need to change your data classes if you need a new display, you merely need to create a new right-panel widget, and then teach your controller class how to determine when the new view should be used.
Another advantage of this pattern is that you only ever need to have a single widget created to display data in your right panel. If you change your selected item, you can just pass it to the view class that already exists and get it to refresh its display with the newly selected data. You only need to distroy the right-panel view widget if a different category of data object is selected and its data needs to be drawn in a different way. The controller class can determine whether a right-panel view widget can be re-used or whether it needs to be swapped out for a different widget.
If I understood the concept of the Qt models correct, then I can have multiple views, sharing the same model, so that when data is updated in the model, all views using it, will also update their view accordingly right?
Now I have multiple widgets in my application, which should have individual selections, but they should operate on the same underlying data. So when a row is added in one of the panels, the others should be able to display this new row as well.
Since the QListWidget provides all the features that I need, there would be no point in writing my own model and use it with a QListView. But I realized that QListWidget doesn't allow me to change the model, because the setModel()method is made private.
So is there some way that I can achieve this, without the need of writing a full model on my own? I'm rather new to Qt so maybe there is a ready made general purpose model, that I can use? But so far I haven't found one.
You are trying to use QListWidget to set your own model which is not possible.
You are better off using the MVC pattern the QT imposes. You can refer here on how to use the MVC pattern. This way would be more manageable and correct. Also you can make of the QStandardItemModel or the more general QAbstractListModel or QStringListModel model for lists. You can refer here for more details
But to answer your question yes they is a hack you can use.
Create a QListWidget and treat that widget as your model.
For other views create a QListView and set the model that is returned by the QListWidget
.
For e.g. refer
QAbstractItemModel* model = listWidget->model();
listView->setModel(model);
listView_2->setModel(model);
Then you can use the listWidget as your model. Any operation (add/delete) performed on the listWidget will also affect the listView and listView_2.
I am still of the opinion that instead of the hack creating your own model would be better and more correct.
I have encountered an issue that is most likely WAD but I still need to solve. I originally thought it was a problem with my custom models but it is in fact present with Qt native model classes as well.
Consider this little program: https://drive.google.com/file/d/0B9MLVHQaeHKxeFBSYzVGVF9sQ0U/edit?usp=sharing
It is just fresh Qt GUI app with 2 QTreeViews and two sets of buttons for inserting/removing rows and columns on each view. The underlying models are QStandardItemModel in one view and QIdentityProxyModel in the other. The navigation is accomplished by clicking on the models – the index is stored and then used by the buttons.
Try inserting/removing rows and columns and you will notice that the views do not update right after the underlying data structure will have changed. Rather they will be updated after you hover over them. And that is the problem because in my other project I have incoming network data that updates the model data that is being displayed to user via standard Qt views. Therefore I need the views to be updated after the data changed and NOT when user hovers over them which he may not do as he may not be aware of the change.
You may notice there is the updateViews() function where I have tried to force-update the views. Neither update() nor repaint() changed anything. The former probably correctly as the documentation says but the repaint should as I understand it cause the widgets to get repainted… Is there any other way to force-update the views?
Also, the reason why I set up the proxy model is that in my project the proxies are heavily used and therefore I need to cause the view-update via them rather than via external slot/function call as is the case in the example given. But if need be this could work as a work-around as well.
Thanks!
EDIT: Problem is manifesting with columns manipulation only it seems. See detail in comments below.
In Qt, I'm writing my own tree model (by subclassing QAbstractItemModel) which wraps around an existing data structure. It should be possible to update the data structure internally (not via the model) as well as via the model (so views can change it). In order to imagine it better: it's a scene graph which should be possible to edit using a scene view (without going via the Qt model) but also using an outliner (QTreeView which uses a Qt model as a proxy around the scene graph).
To avoid confusion we should consider two different scenarios (in the following, I use the "remove" operation as an example):
The user uses the Qt view to remove a node. The view wants to remove a row from the model using QAbstractItemModel::removeRow. This should in turn remove a corresponding node from the underlying data structure, the scene graph.
The user uses the scene view to remove a node. The scene view wants to remove a node from the scene graph. The model which wraps around the scene graph gets notified and in turn wants to notify connected views that a row has just been removed.
While I think I know how to implement 1., I don't know how to implement the notifying part in 2. There is the signal QAbstractItemModel::rowsAboutToBeRemoved() as well as rowsRemoved() which sound like they're my friends. But they are private signals (they say in the header source code: "can only be emitted by QAbstractItemModel"). There also is beginRemoveRows() and endRemoveRows() but according to their documentation, they should be called when the updates happens from the view, i.e. when removeRow has been called. Also, when I tried to use them, the view was screwed up totally.
According to the documentation it seems like it's not intended that the model class can model self-modifying data. Let's take a file system as another example. When using file system watching, which can detect changes in directories, a model should notify a view so the changes in the directory can be displayed live, even if the view was not used to modify the file system. Are such models even possible in Qt?
You're reading it wrong. The model must signal to its users when it's about to start changing its "geometry". So, no matter what is removing the rows from the model, it must tell the outside world that it happened. The sequence of events when a view removes rows from the model is such:
The view calls model->removeRows().
The model calls beginRemoveRows()
The model actually removes the rows from the internal data.
The model calls endRemoveRows().
If you implement some other interface that will remove the rows without calling model->removeRows(), you have to do exactly the same thing. It doesn't matter if it's a view or some other code that removes rows from the model, the model's behavior must be the same or else nothing will work.
You can architect an adapter class that's inserted between your SceneGraph and the Model. It should hold a pointer to the scenegraph and the model, and translate the operations between the two.
I've been reading about Qt's Model/View framework. I find it really helpful on working with tabled data like tables from a database. My question is: will it be useful for non-table data like property list or just some bunch of data of various types? If so, how should I approach it?
The goal is to come up with an editor for some property list like data. The list is constructed at runtime and the elements are of various types (numbers, strings, booleans, and file paths, to name a few). Each element is basically a name-value pair. The name, type, and restrains (limits for example) for each element are defined at compile time. They will be assembled at runtime into different lists depending on user input. And the list of elements can change during the edit session.
The UI will most likely be combination of various pre-designed widgets assembled according to user input. They may not be list or table views.
Some pointer to design pattern or examples are also much appreciated. Thanks.
I don't see a problem with MVC framework in QT for doing that.
Basically the difference between a standard table display and this is that you create a list dynamically akin to a map of:
QMap<QString, QVariant> property_map;
You can do a:
QList<std::pair<QString, QVariant>> property_list;
which you can then use to display in a table the property. The best way would probably be:
struct {
QString prop_name;
int prop_type;
QVariant prop_value;
};
QVariant basically will provide you with a single abstraction class for data storage and it is actually what's being returned by the data() function inside the QAbstractItemModel which you might be reimplementing.
So basically you will take a property list and boil it down to the same table like data as the database.
AMENDED
If you have a Widget that you want to have this widget populated with other predefined widgets you are quite likely to have multiple problems unless widgets are of same or well defined size.
What you can do is in you Display widget define a layout like: QGridLayout or other possible layouts and then add your other widgets to it using some set of parameters, which could be done but can be somewhat of a pain.
The other approach that you may take is to place all property widgets up front on the display UI and simply turn the ones you need on and the rest off, but this only applicable if you have a well defined limited number of pre-designed widgets.
I've been using Model/View framework for quite some time now and I usually implement my own models with a backend based on Qt containers (vectors, list, etc). Even if data eventually comes from a database, working with (e.g.) a vector of database ids can dramatically improve performance (and sometimes is the only way you can do).
This trivial example from Qt docs (see "Creating a Custom Model) is the point where I started and shows how to use a QStringList as a backend for a custom model.
Once defined your model you can define your custom Views, which will draw arranged widgets based on the content of the model underneath.
When the model change, your view will change accordingly rearranging widgets when necessary.
Leveraging QVariant capabilities you should be able to render the proper widget for every datatype (e.g. a QSpinBox for a float a QComboBox for a QStringList, and so on...)