Re: GtkTree*

[Jonathan Blandford <jrb redhat com>]

Tim Janik <timj gtk org> writes:

> On 17 Aug 2001, Jonathan Blandford wrote:
> > Actually, we don't want to connect to the signals until we actually
> > care about the model.  I really don't want there to be a substantial
> > speed difference between:
> > 
> > model = gtk_tree_model_new ();
> > add_ten_thousand_rows (model);
> > view = gtk_tree_view_new_with_model (model);
> > 
> > and
> > 
> > model = gtk_tree_model_new ();
> > view = gtk_tree_view_new_with_model (model);
> > add_ten_thousand_rows (model);
> 
> note that you still have the penalty if those ten-thousand rows are
> added after realization (e.g. due to a reread-dict button or similar).
> so special casing just row additions right after tree view creation is
> a bad hack, and APIs like the one for selection have to work prior
> to realization as well.

Erk.  You're right about selection.  I'll keep what you did.  We'll just
have to let people who setup very large models that setting their data
before adding to the tree will speed things up.

> so what you probably want is gtk_tree_view_freeze()/gtk_tree_view_thaw(),
> so users get a chance to tell the tree view when to not pay attention
> to possibly expensive model chnges, no matter what state the tree view
> is in (since freeze/thaw should work incrementally like in other APIs
> we have, it might be convenient to auto-freeze the view upon creation and
> thaw upon the first size request).

Freeze and thaw are evil.  I'd rather not add them.

> if the treeview doesn't come with freeze/thaw APIs, you basically force
> users that need to code around long model update periods after realization
> time to implement hacks like:
> /* emulate freeze */
> gtk_tree_view_set_model (tree_view, NULL);
> update_mdoel (model);
> /* emulate thaw */
> gtk_tree_view_set_model (tree_view, model);
> which would be a pity API wise.

A better idea is to add incremental reflow.  *Sigh*.  That should go in
bugzilla somewhere.

-Jonathan