QML Data Model and columns
-
wrote on 23 Apr 2012, 22:54 last edited by
I started to port a QWidget application to QML. I'm slowed down by QWidgets use of Columns and QML's use of roles from QAbstractItemModel. After searching the problem, "QMLifyProxyModel":http://www.qtcentre.org/wiki/index.php?title=QMLifyProxyModel was found. I haven't tested out the solution, however I'm wondering what was the reasoning for using columns with QWidget and Roles in the QML world?
By QWidget I mean specifically QTableWidget.
Also, It looks like QMLifyProxyModel was updated 1 1/2 years ago. I would like to know if there is a better solution to bridge a column based model to a role based model.
-
wrote on 28 Apr 2012, 15:35 last edited by
The widget world also uses roles. The problem is that qml views only work with list-type models at present so roles find a greater use for more freedom.
Please feel free to get involved and write some more versatile qml views that can be used with table or even tree-like models.
I will be very interested to see what solutions you come up with for this problem.
-
wrote on 28 Apr 2012, 19:29 last edited by
Thanks for the response, I'll look into making a QML table view. Do you know of any benefit of using Columns instead of Roles? Besides being compatible with a QTableWidget.
-
wrote on 29 Apr 2012, 08:12 last edited by
Before you start from scratch, let me point to the Desktop Components project. It already supports a table view with columns, but indeed, it is based on rows.
From a design perspective, I get that using roles may be the better design for many situations. Often (not always), the items on a single row in a table really just represent aspects of a single underlying item. For instance, if you are displaying contacts, all the items in the columns (name, d.o.b., phone number) represent aspects or attributes of a single entity: the person. That makes it logical to be able to treat them as such. Representing such information as a table model, pre-supposes that you want to display such information always in a table form. That may not be the case. Perhaps you want to use a representation that looks like a set of business cards instead, for instance. Having the model in the form of a table would then be harder to use. Using a table to represent objects with a number of attributes is one way to represent them, but not the only way.
1/4