@Christian-Ehrlicher It caches entries that could have fairly high resolution images in them. 100MB consumed is quite reasonable for my particular use case. I've solved my problem my creating a general-purpose list model class which does not retain too many recent items in memory, and then implementing an application-specific subclass that will automatically produce small, low-resolution thumbnails and save them to a separate table to allow for faster loading later on.

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.

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.

Yeah but the user also want to be able to reorder things as he wants, not just sort (ie, put this row here, drag all my selection at this position, invert these two rows, ...)

Ok. Thank you for your answer. I never use QAbstractListModel. Do you have some keys to start ? What is difference between using QAbstractListModel and QQmlListProperty ? In which case is it better to use them ?

That's a brilliant and elegant solution! Thank you bro for spending your precious time with a newbie like me!

@p3c0 said: @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

@Mark81 Even in JavaScript you have two models, you just don't typically think of it that way: model 1: the database, model 2: the results on the client side. Here, you have two models: 1 - the database, 2 - the QML side. So what you need to do is create a paginated model using LIMIT/OFFSET queries.

@Mark81 If index is 0 then don't start the animation. Well something like: property int myIndex : 0 function animate(idx) { listAnimation.running = false var pos = list.contentY; var destPos; list.positionViewAtIndex(idx, ListView.Beginning); destPos = list.contentY; listAnimation.from = pos; listAnimation.to = destPos; listAnimation.running = true; } Timer { ... onTriggered: { if(myIndex==0) list.positionViewAtIndex(myIndex,ListView.Beginning); else animate(myIndex) myIndex++ if(myIndex==list.count-1) myIndex = 0 } }

@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 to @kshegunov , @SGaist , @mrjj for the help.

Sneaky one ! Glad you found out :)

@SGaist I don't mind refactoring it, it's not very long. I will definitely look into this. Thanks!

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. Best Regards

Code would help. And do you see any error messages when your app crashes? Did you try to debug?

@Alexander_Lanin didn't see you already found it before I submit my reply...

Thanks for reply. I already solved it too. It's necessary to return pointer to AnimalModel and not reference. Also there is no necessity for NOTIFY. So this is the correct way: Q_PROPERTY(AnimalModel * modelAnimals READ modelAnimals CONSTANT) AnimalModel* modelAnimals() { return &m_model;}

Hi and welcome to devnet, To make models accessible to QML you have to do sum customization like described in the QtQuick Model Views Data documentation. QSqlTableModel example here