On Mon, Nov 03, 2014 at 10:47:56PM -0200, Tomaz Canabrava wrote: > On Mon, Nov 3, 2014 at 10:21 PM, Dirk Hohndel <d...@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 _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface