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.
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
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface