Like in your example as of now I think I'd make one tree model.

I had considered creating a tree model, but I have some reservations. Store, Department, and Employee have additional responsibilities beyond being simple data containers, and I worry that either I end up decoupling the data from the logic (which goes against OOP principles), or I have to subclass the three classes from a common class, override functions, and therefore haven't achieved clear separation of UI and business logic.

To my mind at least, it makes sense to design this as if it were a command line application, and then throw some code on top to interface with a GUI. Maybe that's not the right way to think about things, but I don't like the idea of the GUI framework I'm using dictating how I should structure my data.

Aren't you describing a use case for a database and thus Qt's SQL module and its models ?

Truthfully, the application has nothing to do with stores, departments, or employees. I changed the names to make the problem easier to reason with. I don't think the data layout is so complex that it justifies introducing relational databases. And besides, with the very frequent live updates coming over the network I can see latency issues arising.

I was able to fix this with the following:
https://github.com/qt/qtbase/commit/7d92ef63d7c

And the following patch in Qt-5.15.2 which tremendously improved the timing:

Screenshot 2024-10-25 at 9.59.59 AM.png

@jdent
You have to iterate through the rows looking for the value you want.
If you use a QSortFilterProxyModel you can take advantage of binary search for speed if you sort by primary key. QSqlRelationalTableModel is not important here, all that gives is a "lookup" on one field to map e.g. an integer value to a corresponding string from a related table for display.

Please read the docs of submitAll():
"In OnManualSubmit, on success the model will be repopulated. Any views presenting it will lose their selections."

@hemang_1711 I have just gone back to your original post and I see again what originally confused me.

If you recall, I asked about GraphParam, which you are trying to access in your QML. I looked for this in your model implementation, but your model does not have a role "GraphParam".

You do have a role "GraphList", which seems to return the first element of the list member named GraphParam in the GraphModelItem struct in your implementation. Although GraphParam is the name of the struct member, QML does not know anything about this name. It only sees the names you have defined in your roles.

@GrecKo the problem is, that GridView releases it delegates when model's elements is removed. It provokes Image to reload if delegate is shown again. No meter if I set cache: true

Such a shame that GridView don't have reuseItems like ListView

I've come with next decision. I've created Repeater containing Image that use source model. GridView's delegate Image use Repeater's function itemAt() giving delegate's index after mapping to source model:

//Image in deleagte Image { Component.onCompleted: { source = appModelImages.loadImage(appFilterModel.mapRowToSource(parent.delegateIndex)) // custom implementation } ... } //Repeater Repeater { id: appModelImages visible: false function loadImage(index){ return itemAt(index).source } model: AppModel delegate: Image { visible: false asynchronous: true source: model.boxart } }

This may be not the best decision, but "faster" than create own delegate pool for GridView. Didn't see any examples of implementing mechanism like this. Repeater should work fine, as it relays on source model. And as I expected, images live when source model does.

@JoeCFD said in QVariant to QList:

Understand. Thiink about you can never be number 1 anymore if you play chess.

Oddly enough, that was never a concern of mine.

@SGaist
That's What i want bro Really Thank you <3

@JonB

Huge thanks, you solved the puzzle for me!

@Gojir4 thank you so much

The problem arises from the usage of the method m_model.setStringList(). The latter always clear the previous data, hence the index always reset upon its call.

Solution:

Use m_model.setStringList() only in the constructor to init the model.

After that manually insert the row on the model and set the data for the respective row. This can be achieved with a simple modification in the slot method.

MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent) , ui(new Ui::MainWindow) { ui->setupUi(this); m_model.setStringList({"1","2"}); ui->comboBox->setModel(&model); } void MainWindow::on_pushButton_clicked() { m_model.insertRow(model.rowCount()); m_model.setData(model.index(model.rowCount()-1), "3"); }

In the example above, "3" is appended to the list model without changing the current index from the QComboBox.

Hi @LeLev,

I tried your solution. Its showing the image. That is fine.
Now if i have more elements then its filling in the same space.
I need to scroll thorough the screen to see the elements.
How to do that ? How should I use Flickable in this case.

Note: For example: If the screen layout is 500x500, and each element size id 50x50,
then i should only see 16 elements initially. I have to scroll down on the screen to see the remaining elements.

@jeanmilost
I can't answer all your questions, as I'm not an expert on Qt's Model/View system, what I do know is,

that all models have a QAbstractItemModel as base model and that is also the ABI for all views.
For that reason alone, you can assign all models to all views. You will however not get a useful representation of all your data in all views.

As I understand it, and anyone fell me to correct me here, the other higher level classes of models are only there to make your life easier, as in you do not have to implement all functions/functionalities of the whole AbstractItemModel class

@daljit97 said in Unable to edit QSqlTableModel from QML:

, Qt::EditRole);

Then you should probably pass the role and not editRole, otherwise model won't know which column to update.

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