Important: Please read the Qt Code of Conduct -

QML Data Model and columns

  • 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": 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.

  • 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.

  • 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.

  • 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.

Log in to reply