trying to figure out the filter code

Dirk Hohndel dirk at hohndel.org
Mon Nov 3 20:51:11 PST 2014


On Mon, Nov 03, 2014 at 10:47:56PM -0200, Tomaz Canabrava wrote:
> On Mon, Nov 3, 2014 at 10:21 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> > So I'm trying to understand how this all hooks together and it's clear
> > that there's some Qt magic in the background that I'm missing...
> 
> There is a bit of black magic, yes.

Beginning to shine a light on it :-)

> but if you wanna check if something happened just *after* the filter was
> due,
> you need to implement something inside of the
> 
> void MultiFilterSortModel::myInvalidate()
> {
>     invalidate();
>  // HERE.
> }
> 
> The 'invalidate()' method is internal to Qt and all it does is mark the
> model as dirty and filter everything again based on the filterAcceptsRow.

Excellent. I just did that and I think I managed to clean up part of the
issues with the selection. I pushed two changes that did that.

> > Another question. In the regular model code for the dive list - we have
> > lots of selection modification code there. That needs to become aware of
> > filter data so that selecting a trip in the filtered view only selects the
> > dives inside this trip that are visible under the filter - and similarly,
> > the trip row in the view needs to show the number of visible dives in that
> > trip, not the number of total dives in that trip.
> >
> 
> Very hard to do with our current setup:
>  The state of the DiveModel is unchanged, we are applying a filter on top
> of it.
>  so it doesn't know about the filter at all.
> 
> 
> > To illustrate:
> >
> > I have a trip with 12 dives
> >
> > I filter for dives with Buddy Tomaz
> >
> > Then only the 6 dives with Tomaz are shown, but similarly the trip summary
> > row should read
> >
> > Dive trip (6 dives)
> >
> > instead of "(12 dives)"
> >
> > So when I'm in TripItem::data() member, how can I figure out how many of
> > the dives in that trip are visible with the current filter?
> >
> 
> *right now* we cant. simple as that ( unless we do something really ugly to
> the code. )
> so, Options:
> 
> 1 - We hack around that, but the code will be easy to break and hard to
> maintain, for now.
> 2 - We hm....
> okay, some light came, maybe we can.
> 
> the MultiFilterProxyModel acts as 'proxy' so we can use it's own data()
> method to retrieve information about
> the filtered trip - but I'm not really sure it works, I need to test and
> see, the setup should be as this:
> 
> 1 - Implement the data() method for MultiFilterProxyModel,
> if the current index is a dive, call the default implementation
> if the current index is a trip, verify the number of children it has in the
> proxy model, not in the real model.
> return the correct string.

I got stuck there - didn't manage to figure out how to do that. :-(

/D


More information about the subsurface mailing list