Re: Proposed GtkTreeView API change

[Brian Cameron <Brian Cameron Sun COM>]

Jonathan & Bill:

> >> 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.

Let me see if I understand you so far.  You are only suggesting
replacing range_changed with row_changed.  So that you would get
a signal for each row that has a changed value.  Is it possible
that you might get the signal when no value has changed on the row?

I am assuming that no other signals (row_added/row_deleted/
column_added/column_deleted, etc.) are being affected by this
proposal?

I don't think this is a big change from the previous range_changed
implementation since I don't think GtkTreeView or its various models
ever generated the range_changed signal for a range larger than one
row anyway.

> >> 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??
> >
> Tim said:
> >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.
> 
> However, accessibility support *does* use these signals, and 
> in an assistive technology use case there are likely to be multiple 
> CORBA calls per signal of this kind.  

Bill, I think you are wrong here.  The gail logic listens to the
signals from GtkTreeView and that it tries and calculates specifically
which cells have changed...then it generates children_changed signals
only on the children that are necessary.  So whether or not gail
receives one signal or multiple signals only affects how GailTreeView
works, not someone who is listening to signals being generated by
GailTreeView.  I hope this makes sense.

It might also make the Gail code run faster.  Instead of having to
check the GailTreeView cell cache for *every* cell in the range,
we only have to check the cells in the row.

It would be even better if GtkTreeView could specify what cells in
the row have changed (or generate a separate signal for each cell).
If it were done this way, then we would not have to check the cache
at all, and a lot of ugly code that we wrote to do this checking
could go away.  This would be more signals between GtkTreeView and
GailTreeView, but not having to check the cache would speed things
up, I think.

> The way it works:  we listen to relevant signals from GtkTreeView, and 
> in our signal handler we construct appropriate out-of-process signals to 
> pass to assistive technologies (this is where the first of the CORBA 
> calls occur; on receipt the assistive technology generally responds with 
> some synchronous queries of its own).  We can't really aggregate these 
> signals, since we can't know when we've received the last of a "group" - 
> better if we receive only one signal for an operation like a reorder.

Since the signals are only transfered between GtkTreeView and GailTreeView,
and only the appropriate children_changed signals are then sent via CORBA,
I do not think the performance issues are as severe as you think.

> Anything that increases the number of signals for range changes is 
> indeed a problem.  It's also true, however, that a generic "changed" 
> signal is problematic since, for to avoid a flurry of out-of-process 
> accessibility calls, the assistive technology client will keep a cache 
> of objects for the treeview cell data.  Without range information, a 
> "changed" signal would require invalidating and re-reading the entire 
> cache, or at least re-validating each individual member of the cache via 
> multiple out-of-process calls.

If they are generating a signal that says "some cell on this row has
changed", then this gives GailTreeView enough information.  It would
be better if they generated a signal for each cell, actually (as I
mentioned above).
 
> If the "changed" signal has range information, then we can connect to it 
> (only, rather than the property_notify signals).  It would be best if it 
> is emitted *after* the change has been applied, otherwise an assistive 
> technology can't revalidate its cache inside the (out-of-process) signal 
> handler.

I'm not sure how GtkTreeView works in this case, but yes, it breaks
ATK if the signal is generated before the change is actually made.
Jonathan?

Anyway, I hope I've added something to the conversation.  :)

Brian