[Qt-interest] FW: QAbstractItemModel: Hiding rows

[Eric Clark]

You make a very good point about the views not being able to react to my data appropriately unless I was to inherit those views and implement one of each for my model type. This is definitely not desirable. However, the main reason for using the model/view architecture in my application is for the purpose of separating the GUI from the execution code. My application has two modes, GUI and console and needs to be able to perform all of its tasks without a GUI, that includes no linking to any GUI libraries in Qt. This is to make the memory footprint as small as possible. It is very important that data not know about the GUI or have any direct calls to any GUI functions. As such, even if I chose to use a special role, it would STILL make sense to use the model/view architecture. However, thanks to both of your responses I have become much more familiar with the model/view architecture. It is taking time to really truly grasp it, but it is coming to me. 

I am going with a solution similar to what Arnold proposed with the separate list of hidden models, however, it is only an ending index in my case. Objects that are created during our simulation are not to be added to the GUI, but do show up in the model. They need to be hidden, these are the objects I am referring to with my question. All I really need to do is keep track of the index at which the rows stop before hidden rows begin. And I can then return a shorter representation of the rows for the views to show.

Thank you so much! You have both been very helpful!

Eric

-----Original Message-----
From: qt-interest-bounces at trolltech.com [mailto:qt-interest-bounces at trolltech.com] On Behalf Of Arnold Krille
Sent: Friday, July 10, 2009 5:13 PM
To: qt-interest at trolltech.com
Subject: Re: [Qt-interest] FW: QAbstractItemModel: Hiding rows

Hi,

On Friday 10 July 2009 23:52:53 Eric Clark wrote:
> I am not real sure why Brad said you were wrong, but I can see how it 
> would work with a Proxy model. And I do believe that for most cases 
> the proxy model is probably the correct solution. However, for my 
> case, we have come up with some other solutions due to the speed we 
> need to have. I cannot call insert or remove rows during certain 
> circumstances in my application because we need to be as fast as possible.

Actually my mentioning of removeRows/removeColums was only to point you to the concept. Unless you implement these functions in your model, they will do
nothing.:-)

You could be faster if you have your list of real data and a (small) additional list of the rows that are hidden. QAbstractItemModel::rowCount() would then return data.size()-hidden-size().
And for accessing an item, the index i to access data would be index.row() + the number of items in "hidden" that are smaller then index.row().

> What Brad suggested is based on my view using the data internally. I 
> could easily add a data role called VisibleRole or something and 
> return a Boolean flag, true if visible, and false if hidden. Then the 
> view could just hide the item or not create it at all. This is a great 
> solution and probably the easiest solution as it only requires my 
> model to return an extra role in its data function. No need for mapping of reordered indexes or anything.

My point is: If you use special roles in the model and therefor can only use it with a special view, why go through all the loops of the model-view- concept? While it might be interesting to part the data from the gui, there is then no additional benefit from using Qts QAbstractItemModel- and QAbstractItemView-classes for this as all the standard-views will not react to your special features in the model.

Have fun,

Arnold