Re: GtkTree*

[Tim Janik <timj gtk org>]

On 17 Aug 2001, Jonathan Blandford wrote:

> Tim Janik <timj gtk org> writes:
> 
> > On Wed, 15 Aug 2001, Tim Janik wrote:
> > 
> > > setting up a static model for a treeview, then adding columns, then doing
> > > gtk_tree_selection_select_path (tsel, path); doesn't result in a selection
> > > because gtk_tree_view_setup_model() aborts on tree_view->priv->columns == NULL.
> > > i guess you should setup tree_view->priv->tree as soon as the first column is
> > > added (and you have a model). (though, i'm not sure why you can't setup the
> > > rbtree right when you have a model and no columns yet).
> > 
> > investigating this further showed that gtk_tree_view_setup_model() and
> > gtk_tree_view_set_model() don't sanely maintain tree_view<->model relationship
> > state (e.g. gtk_tree_view_setup_model() could setup the signal handlers,
> > but not update GTK_TREE_VIEW_MODEL_SETUP, no handling at destruction time etc.).
> 
> Those are bugs that need fixing.  I'll see what I can do about them.
> 
> > appended is a patch that i intend to commit soon, it fixes the above selection
> > probelm and also gets rid of tree_view signal handlers connected to the model
> > being executed after the tree_view got destroyed.
> 
> 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.
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).
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.

> That is why I delay building the model until size_request.  I'm going to
> revert that part of your patch and try to fix the bugs above.

i'd rather see you implement freeze/thaw ;)

> 
> -Jonathan
> 
> 

---
ciaoTJ