[Interest] Proper way of updating a model?

Stephen Chu stephen at ju-ju.com
Thu Aug 23 14:33:53 CEST 2012


On 8/23/12 5:04 AM, André Somers wrote:
> So, you *do* have a table model, but you are just displaying it in a
> QTreeView? That's very possible, of course. Note that QTableView can be
> given the same appearance as QTreeView, but is more efficient at
> layouting because it does not need to deal with the (complex) tree
> aspects of it.

I choose QTreeView mainly for its look and row-base selection. Our 
existing app on Mac uses Data Browser control (think Finder) and 
QTreeView provides the closest look and feel to it.

> Please keep in mind that *any* model can in principle be viewed in *any*
> view. You may loose certain aspects of the data of not use all features
> of the view, but normally, it will work. That's because views only rely
> on the common interface provided by QAbstractItemModel.

Yes, I understand I can use basically any view with and model. And I 
really appreciate that feature/function. Makes my prototyping a lot easier.

> For efficient updating, you will need to keep track of changes: inserts,
> deletes and updates of items. Just rebuilding will generally not be very
> efficient.

That's what I did in the existing app.

> No, resetting is not the way. It will result in loosing selection,
> scroll position and is generally visually disturbing for the user. As
> others have notices, the beginInsertRows, beginRemoveRows and their
> respective end* functions are your tools, together with emitting the
> dataChanged signal for updates to data.

Thanks to everybody pointing this out. I will give it a try. The issue I 
have is actually being coming from OS X Data Browser control. It tracks 
items by user supplied 32-bit IDs instead of indices. That makes 
updating the list a lot easier by just adding new IDs and removing old 
one without worrying about the indices change after each insert/remove. 
And also makes batch operations much more straightforward and efficient.

With Qt, I think, I have to add/remove ID and index pair together, one 
pair at a time, to keep the ID-to-index in sync. I probably can batch 
insert new ID-index pairs at the end of my list. But since IDs to be 
removed can be scattered in the list, it will be hard to remove them in 
batches.

> However, it also depends on the size of your dataset. Are you talking 10
> rows, 1k, 1M or even more?

It can be from Ks to 100s of Ks. But I am in the process to redesign it 
so we'll never deal with more than 10s of Ks.




More information about the Interest mailing list