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

[h]

On Wed, 02 Oct 2013 14:53:54 +0200
André Somers <andre at familiesomers.nl> wrote:

> 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é
> 

Thankyou.  I will need to put some thought into this...
H