On Mon, Nov 3, 2014 at 10:21 PM, Dirk Hohndel <[email protected]> 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.
So, everytime a filter is changed, *every* row on the dive list is send to
a specific function,
trips and dives, doesn't matter:
this one:
bool MultiFilterSortModel::filterAcceptsRow(int source_row, const
QModelIndex &source_parent) const
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.
> Let's assume I want to have a function called every time the filters
> change. How would I go about this?
>
Add it after the invalidate() call.
or create a new signal inside of MultiFilterSortModel called
'filterFinished()', call it after the invalidate() call, and connect it to
your own slot.
>
> 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'm not asking you to implement any or all of this - I'm hoping that
> you'll be able to teach me enough to understand how all this works so I
> can implement it myself.
>
> /D
>
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
