Re: Introducing GtkTreeModelFilter

Kristian Rietveld <kris gtk org> writes:

> > > Sidenote: you can set a modify or (filter function/filter column) only
> > > *once*.
> > 
> > Why? Would it be hard to change? These types of restrictions 
> > tend to seem harmless, but often are a real pain for things
> > like GUI builders.
> I think this will be easy to add now I have this _refilter function. It
> will be slow though. I have actually discussed this with jrb, and IIRC
> he said it wasn't really needed and would be painful. But maybe it was
> unfair to mention that (sorry jrb) (:.

The reason that you can't change them is that it gets awkward for
observers of the model.  As GtkTreeModel doesn't really have the concept
of atomic changes, we can't propagate the changes that a new function
will have gracefully.  Consider a filter function that hides half the
rows.  When you change it to it's inverse, you'd have to walk the list
emitting insertions/deletions at every row.  While doing so, you're in
an indeterminate state.  This breaks things like the GtkTreeModelSort,
which expects the child model to always be consistent.  I told Kris it
would be easiest to just require the ModifyFunc etc. to be static for
the duration of the model.

> > Similar to the question above, would it be possible to have 
> > set_model(), set_root() functions? Mandatory arguments to the
> > constructor, can be done as construct-only properties, but
> > language bindings (and GUI builders) are happiest if there
> > are no mandatory arguments at all.
> Both are mandatory arguments and should be implemented as construct-only
> properties. Changing model and vroot after construction is really
> painful, and it would be much faster to just create a new filter model.
> I don't see much point in changing this function as there will be
> construct-only properties (if I remember correctly I already added
> those).

We allow you to change the number/types of columns in the Store function
by keeping track of whether anyone has inspected the model.  We can do a
similar trick here.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]