Not sure if this is a bug or just another one of GTK's quirks.
When using a GtkTreeModelFilter to filter a GtkTreeStore, if a top level
row node (parent?) is set to hidden (via returning FALSE in the
visibility function or otherwise via the visibility column), it remains
hidden even if a sub node (child) has been set visible. Thus in essence
the filtered view hides the child even though it requested to be seen.
When a child has requested to be visible, the view must make sure all
parents required to make the child visible, are indeed visible as well
regardless of the parent's setting.
According to the docs, GtkTreeModelFilter provides two ways of
"filtering" rows out of a view. Both ways make it very difficult to
ensure the parent(s) are explicitly set to visible if only the child
matches the filter expression.
Example: Filter based on textual string comparison of row text
- Filter Method 1.
If one chooses to employ the "visible function" method of filter, the
function is called once for every row in classic tree depth fashion. ie.
P1
-> C1
-> C2
-> GC1
-> GC2
-> C3
P2
-> C1
-> C2
etc...
would result in "visible function" being called for
P1,C1,C2,GC1,GC2,C3,P2,C1,C2 etc...
Hypothetically, if P1 does not match the search expression, return
FALSE, its marked hidden. C1 comes round, and it matches the search
expression, return TRUE, its set to visible. C2 is next and it doesn't
match the expression, return FALSE, its marked hidden etc...
However when the view is drawn, C1 will not be visible. The view hides
C1 because it's parent P1 was marked hidden.
How do you counter this behaviour? Even if you look up "parents" for the
arbitrary nodes passed to the "visible function", how do you change
their visibility statuses?
- Filter Method 2.
Using the "visible column" approach it becomes possible, but not very
plausible.
One can call gtk_tree_model_foreach() and walk through all the
G_TYPE_BOOLEAN fields of the corresponding rows and mark them TRUE/FALSE
and look up parents of nodes (like C1) and mark them TRUE even if they
did no match the search criteria. However looking up parents
continuously like this takes a massive performance hit when you have
large stores.
Thus both filter approaches are useful when only the parent node is
basis for filter criteria. In a list store this is perfectly fine, but
in a tree store it is definitely not.
Does anyone know how to get GtkTreeModelFilter to treat it's model more
like a tree and less like a list?
thanks,
Vik.
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
