[Interest] Help with Model / View Programming (FilterProxyModel) -- sorry complex question!!

[André Somers]

Hi,

Op 2-10-2013 14:34, h schreef:
> Hi,
> I have a QT project I am developing on OpenSUSE 12.3, using QT 5.1 (64
> bit)
> I am using the QT Model /View, currently using table views.
>
> My raw data in my model (subclass of QAbstractTableModel) is a linked
> list of pointers. Each item in the list maps to a row in the view and
> there are a fixed number of columns. The view supports editing.
>
> Currently I have a QSortFilterProxyModel which I use to both filter and
> sort the data in the views.
>
> This is all functioning well.
>
>
> I want to introduce a new table view where the number of rows and
> columns is related to groups of data, not to individual values in my
> linked list.
>
> The basic class structure will look like this:
>
> 	myQAbstractTableModel
>          	|
> 	myQSortFilterProxyModel
>          ________|____________
>          |                   |
>       myView1             myView2
>
>
> where the 2 different views have different ways of calculating the
> number of rows, number of columns and the data in them.
>
> Currently myQAbstractTableModel calculates the number of rows and
> columns and data for myView1, but not for myView2.
>
> To calculate the number of columns in myView2 I need more information
> than the result of myQSortFilterProxyModel::filterAcceptsRow (yes, the
> number of columns in the view is dependant on the result from which
> data items are being displayed.  Am I correct in assuming that the row
> in this function refers to a "row" or tuple of data in the model, not a
> row in the final view?
>
> To be able to calculate the data to display (and edit) and the numbers
> of rows and columns I think I need to override the int
> myQAbstractTableModel::columnCount( const QModelIndex & parent ) etc
> functions in myQSortFilterProxyModel so that I know what data has been
> filtered out.  I also need to know what type of view the data is being
> supplied to.
>
> An alternative would be for me to subclass myQSortFilterProxyModel once
> for each view type.  This way at least I do not need to know which view
> type is requesting the data.
I think this is the *only* way to go. There is no way you can know the 
caller of functions in your (proxy) model, so you do not know which view 
is asking for the information. If you need different representations of 
the data, or different subsets, use different proxy models.

Note that there is a bit of headache involved with synchronizing 
selections if you need that. You can't just use the same selection model 
on the two views, as they have a different (proxy) model set as their 
model. There is a class in KDE that can help you deal with this though.

> Either way, because I need to calculate using several fields in the raw
> data I think I ant to hold a list of pointers, similar to the one in
> myQAbstractTableModel, but with the filter applied.  With this list, I
> want some way of ensuring that when data is added or removed from
> myQAbstractTableModel, or the filter is changed that I can update the
> pointer list in this derived class.
>
> Does this make sense?
Not much. I think you should expose the information you need for your 
views in your (base) table model. I would not expose the raw data, 
though it can make sense to expose some special struct or perhaps an 
iterator-like class that contains multiple bits of information at one go 
if you need more than one field from the base model at the same time for 
your calculations. Otherwise, you'll end up doing the lookup for your 
calculations multiple times because you need to request the data 
role-by-role.

If you stick with using data from the base model in your proxies, you 
will not have synchronization issues. Your base model will signal 
dataChanged() (if it is implemented well) if you change a bit of data. 
Your proxies will/should use that to signal their clients that data has 
changed, if needed.

André

-- 
You like Qt?
I am looking for collegues to join me at i-Optics!