CC'd the -devel list as I think this is relevant there..
On Tue, 2007-06-19 at 11:56 +1000, Daniel Kasak wrote:
> On Thu, 2007-06-14 at 21:54 +0200, [EMAIL PROTECTED] wrote:
[snip]
> > The data model often changes drastically, a lot of rows and
> > subtrees are modified, deleted, created, etc.
> If you change the model significantly, you want to do one of 2 things.
>
> Option 1 ) Create a new model, populate it, and then use
> gtk_tree_view_set_model to tell the treeview about the new model, and
> dump the old one.
>
> Option 2 ) use gtk_tree_view_set_model to point the treeview at another
> ( empty ) model ( or maybe NO model ... I'm not sure if you can do this,
> I've never tried it ). Then do your changes to the real model. Then use
> gtk_tree_view_set_model once more to point the treeview back at the real
> model.
>
> The idea with both of these approaches is that when you do lots of
> changes to the model, it forces the treeview to keep updating, and this
> is slow. It's best to do all your changes with the treeview
> *disconnected* from the model, and then connect it back. Works for me
> anyway.
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.
Here is a possible interaction flow...
Model: Emits "invalidate" signal
View: Knows its internal state may loose track with the model,
if it needs to ask the model for any information, it must
not assume the model's state.
Model: Re-populates without emitting any "changed" type signals
View: (What does it do whilst we're repopulating??)
Model: Still repopulating without emitting any "changed" type signals
Model: Emits a some signal to notify that it has finished
- any further updates emit "changed" type signals.
View: Redraws?
Anyway - the design might suck - IANACS (CS= Computer Scientist).
Adding support of the new signal to the GtkTreeView ought not to break
existing API, as old models just won't emit that signal.
(IANAGTKDeveloper, so could be wrong about that).
Regards,
--
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!)
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
