Re: Proposed GtkTreeView API change

[Jonathan Blandford <jrb redhat com>]

Tim Janik <timj gtk org> writes:

> On 10 Sep 2001, Jonathan Blandford wrote:
> 
> > Currently GtkTreeView has a "range_changed" signal on it that is
> > supposed to let the view know when a series of rows change.  It was
> > added when signals were slower, and sizing of rows was different.
> 
> signals haven't gotten any faster recently, the speed optimizations
> are still outstanding.

Ah, but I'm emitting more signals, so the cost of one isn't so painful. (-:

> > Unfortunately, since then row sizing has changed such that you need to
> > walk the range anyway, and you emit a bunch of signals per row (a
> > "property_notify" per column).  Additionally, none of the models emit
> > it, and the TreeView doesn't support it.  Changing GtkTreeModelSort to
> > support it will be a nightmare.  All this leads me to believe that we
> > need to change it to be just "changed" (or maybe "row_changed").  I'd
> > like to do this, though it will break anyone's code who's using this or
> > writing their own model.  Comments??
> 
> i'd be in favour of this, and i doubt there are lots of third-party models
> out there currently. also, signals _will_ get faster, so the number of
> emissions should become a smaller concern.
> 
> what's the exact matter with ::property_notify you mention though (or do
> you mean GObject::notify)? once you change more than one property per
> object, you might want to free/thaw notify first.

I do, and there is a freeze/thaw in effect.  However, I emit a ::notify
per view column when every row changes, so these signals are more likely
to take time than the initial notification signal.

I'll go ahead and change it to "::changed"

Thanks,
-Jonathan