Re: GtkTree*
- From: Tim Janik <timj gtk org>
- To: Jonathan Blandford <jrb redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GtkTree*
- Date: Fri, 17 Aug 2001 20:33:45 +0200 (CEST)
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]