Re: 'reloading' gtktreeview when model changes drastically

[Peter Clifton <pcjc2 cam ac uk>]

On Sun, 2007-06-24 at 15:19 +0200, Kristian Rietveld wrote:
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> > disconnect them? Bad!
> > 
> > We need some new API I guess - which signals any connected views that
> > the data it has cached about the model should be invalidated, and that
> > the model may be changing without emitting signals.
> > 
> > Once the model is updated, a further signal will inform the view that it
> > can keep cached state again.
> 
> In practise this won't be all that different compared to setting a new
> model on the tree view, except that with a signal it will be initiated
> from the model.

That was the intention - its the same as the workaround described
before, but is model initiated (avoiding the need to break the MVC
abstraction).

> After the model emits the "I am finished changing
> everything" signal, the tree view will have to rebuild its internal
> rbtree by iterating over the full model again (any other model that is
> connected to this model will have to rebuild its internal state tree
> too), since it has no clue what has changed.  This will probably also
> involve unreferencing all nodes when the model emits "invalidate" and
> re-reference the new nodes after the mass changing, and remembering
> selection and expansion state during the mass-changing (this information
> is kept in the internal rbtree too), etc.

If the model changes underneath - its very difficult to say which nodes
should still be selected / expanded (unless of course we use a
change-set type arrangement as you suggest below.

> I think a much better solution would be to be able to group a bunch of
> changes together in a kind of "atomic changeset" which is then emitted
> with a single signal.  All connected views/models could then process the
> full changeset in one pass.  (Possibly this could also add/remove ranges
> of nodes, etc).

This sounds good, although its not entirely clear what such a changeset
would look like. Such a change-set would have to be easy to produce, and
flexible enough in its description that we can be vague.. (perhaps
saying "everything below this node changed"?)

Does anyone use these models for really huge data-sets? If so, I don't
think the change-set (if it lists ALL changes in FULL) is as favourable
as invalidating the model (or parts of it). Perhaps this is just not the
intended use of the models though.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)