On the model you are free to expose the internal structure. QStandardItemModel does it by exposing QStandardItem for example. However if you don't want to make use of the QAbstractItemModel interface and its seamless integration with views and delegate and just use your custom classes why bother subclassing a model in the first place? Just start from scratch. I'm not suggesting this is the most efficient way in terms of developer time but if performance is the only priority then feel free to go as low level as you can

After thinking about this problem more and looking at the interface for QAbstractProxyModel, I am beginning to think that a subclass of a proxy model is not the answer. I am wondering if the best course of action would be to create a new model which keeps a pointer to my base model. Every time the various data changed signals are emitted from the base model, my "proxy" model determines if a new sequence has been found. It then keeps track of all the various sequences in its own internal data structure which keeps QPersistenModelIndex indexes into the base model. Then my "proxy's" data() method would use these indexes to get the real data from the underlying model but parsed into the correct format.

Do this sound like a better approach?

In this case, I am also wondering how to display my data as a table where each row could have a different number of columns. Perhaps I could keep track of the row with the maximum number of columns and return this in columnCount()? Then my data() method would just return QVariant() for columns that don't exist in a given row.

@VRonin That's really useful, thank you very much. Also I didn't know about the "Model test", that's nice too.

@hieuht said in Tree View with varying column counts:

First, the child's count cannot more than the parent's count.

Hmm, I did not see that mentioned. Indeed https://doc.qt.io/qt-6/qabstractitemmodel.html#columnCount says:

In most subclasses, the number of columns is independent of the parent.

Maybe it's a limitation on QTreeView rather than on the model?

Second, the child's column size depend on the parent's size like the following picture.

It looks like the child is only really using the parent's existing columns, just (according to you) it can only use the same number or fewer. Understandable, but not what your picture shows.

Could you provide an example of using delegate to handle this?

Quite beyond me! This is not just a simple delegate, it's virtually the drawing of a complete new table.

@SGaist sometimes picks out something which KDE has added in https://api.kde.org/frameworks/index.html. You might look through that, maybe there is something there for you?

So it's built into the Qt base library then.

I noticed also that any time the table gets clicked that method must get called again because I get another complete set of qDebug() messages. So paint() makes sense then as to why that happens.

Thanks

@tskardal said in How do you persist and update your models?:

I'm thinking that the goal is having "plain" models that are not QObjects.

That's a quite normal thing to do. Let the Qt model be just an intermediary between actual data model/tree and the GUI.

If your implementation works, then it's OK I guess. I'm not sure if there any actual question to answer here :-)

I'm doing something similar in sort of objects property tree. It works pretty well for large number of items. Definitely a massive win over a widget per item approach.
One difference to your approach is that I don't use grab(), but instead have the editors created by the delegate a static drawing function that uses QStyle::drawControl and friends to draw an image of itself. This is because I don't want to instantiate all the editor widgets upfront to grab them (I have a bunch of them and it takes time). It's sort of a trade-off because it can get out of sync with the actual widget look. Whether this is something you'd be interested in or not is up to you, but the general idea of drawing an image is a valid one.

Interestingly, if I make the plugin static, it works fine. Only when the plugin is dynamic does this error happen... Very strange.

@rahulch_pp Try to comment the line 18 of main.qml " animationOptions: ChartView.AllAnimations".
It seems to be buggy from Qt5.12 (and also Qt5.12.1)

Hi! Just to be sure I understood this correctly: You have a single DB with a humongous number of identically structured tables? Do you really believe you can store 2^128 bits / rows / tables / whatever in your database / filesystem / datacenter?

In worst case I will have to keep in RAM about 4e+38 of 16 bytes pointers

Even that is way more rows than what a SQLite table can hold (see: https://www.sqlite.org/limits.html).

I had create a model with key and value and pass it to qml, it worked!!!
Sorry for late reply.
Thank you @raven-worx

The easy way:
get rid of PortalMapItemInfo, store the values in 4 different QStringList and use a QStringListModel

The proper way:
in HomeController.h add Q_DECLARE_METATYPE(PortalMapItemInfo) http://doc.qt.io/qt-5/qmetatype.html#Q_DECLARE_METATYPE

Instead of a List store your data in a 1-column QStandardItemModel and expose it via a Q_PRPERTY

@Mathan-M Why do you want to bind to ListElement?
ListElement's are added to ListModel.
You should probably try to access this model from C++. ListModel is also a QAbstractItemModel.

@VRonin said in Smarter way to get a list of children in Tree Model:

the overridden data is to store somewhere the level in the original tree before it gets flattened by KDescendantsProxyModel.

I don't believe you need that. Pushing a tree model to a list/table view should give you list/table with the root-level items (speculation again!). In my mind it should be just enough to "move" the root of the model before giving it to the view.

I didn't feel like going through building a QAbstractProxyModel from scratch

Well, yes, I can see why, but if you think about it, most of your methods should turn out trivial (more or less) - similarly to the identity proxy model.

Kind regards.