Views - what are the correct rules to use models?
-
I my projects I often need to create views, which are linked to models written in c++. From my perspective, and the way I understood how view/model/delegate systems work, I prefer select the basic model which seems the best designed to interact with the view as a parent for my custom model, e.g a
ListViewneeds aQAbstractListModel, whereas aTableViewneeds aQAbstractTableModel, because always according to my point of view, such models contain the functions required by the view to manage the format they own, e.g aTableViewunderstands what a column is, whereas aListViewknow nothing about columns, for that reason aQAbstractTableModelis a better choice as a base to write my custom model when I have to deal with aTableView.However my supervisor does not agree with me. From his point of view, a model should always match with the data it handles. For example, we recently needed to modify a
ListViewto support a small concept of columns. These columns are written in custom qml components and delegates, and theListViewitself continue to know nothing about columns. For that reason I proposed to use aQAbstractListModel, but my supervisor think I'm wrong and aQAbstractTableModelshould be used instead, because the model should include the concept of columns.I admit to being a little puzzled about that. For that reason, I want to know:
- Is it better to select a model based on its interaction with the view, or on the data it handles?
- May any type of model be used with any view, e.g may a
QAbstractTableModelbe used with aListViewwithout problems, or is it a mistake (and why)? - What are the correct rules and good habits to apply to select a model for a view?
- What should (or should never) be done when selecting a model for a view, and why?
-
I my projects I often need to create views, which are linked to models written in c++. From my perspective, and the way I understood how view/model/delegate systems work, I prefer select the basic model which seems the best designed to interact with the view as a parent for my custom model, e.g a
ListViewneeds aQAbstractListModel, whereas aTableViewneeds aQAbstractTableModel, because always according to my point of view, such models contain the functions required by the view to manage the format they own, e.g aTableViewunderstands what a column is, whereas aListViewknow nothing about columns, for that reason aQAbstractTableModelis a better choice as a base to write my custom model when I have to deal with aTableView.However my supervisor does not agree with me. From his point of view, a model should always match with the data it handles. For example, we recently needed to modify a
ListViewto support a small concept of columns. These columns are written in custom qml components and delegates, and theListViewitself continue to know nothing about columns. For that reason I proposed to use aQAbstractListModel, but my supervisor think I'm wrong and aQAbstractTableModelshould be used instead, because the model should include the concept of columns.I admit to being a little puzzled about that. For that reason, I want to know:
- Is it better to select a model based on its interaction with the view, or on the data it handles?
- May any type of model be used with any view, e.g may a
QAbstractTableModelbe used with aListViewwithout problems, or is it a mistake (and why)? - What are the correct rules and good habits to apply to select a model for a view?
- What should (or should never) be done when selecting a model for a view, and why?
@jeanmilost
I can't answer all your questions, as I'm not an expert on Qt's Model/View system, what I do know is,that all models have a QAbstractItemModel as base model and that is also the ABI for all views.
For that reason alone, you can assign all models to all views. You will however not get a useful representation of all your data in all views.As I understand it, and anyone fell me to correct me here, the other higher level classes of models are only there to make your life easier, as in you do not have to implement all functions/functionalities of the whole AbstractItemModel class
