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.
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
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.
@Kofr So is it that you want to access the roles (namely hue, saturation, brightness) values from outside of this ListView delegate ? If so then did you accessing ListVIew model from outside ? Once you get hold of it the data can be accessed too.
code above is just example, not my case. what I need is to get model.roleName of delegate j when I work in delegate i
@Qmyo You can create a 2 Q_INVOKABLE functions. One will return the Repeater's model number and other will return ListView's models. You can make use of index attached property which can be passed to the Q_INVOKABLE functions to return particular model.
In dropEvent called a new function from model which stores all the parameter of item when droped and emitted layoutAboutToBeChanged() before appending to my TableList and then emitted layoutChanged() which worked for me.
Thanks for your efforts.
As you said it works in a project I have a second look at my code.
I'm not writing a Quick-App but a QWidget-App and use the map inside a QQuickWidget. I have read about another approach to embed qml content in a QWidget-App using QQuickView inside a QObject-Container.
This approach works as expected. I don't know why it doesn't work with a QQuickWidget but my problem is solved.