Re: Proposed GtkTreeView API change

[Bill Haneman <Bill Haneman Sun COM>]

>Date: Tue, 11 Sep 2001 14:13:25 +0100 (BST)
>From: Brian Cameron <Brian Cameron Sun COM>
>Subject: Re: Proposed GtkTreeView API change 
>To: gtk-devel-list gnome org, jrb redhat com
>Cc: Brian Cameron Sun COM, Bill Haneman 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.

However it would be a shame to enshrine this behavior, presumably 
GtkTreeView/Model could be enhanced to generate aggregate range_changed 
signals without changing the API, in the future, with the previous model.

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

The intention was for children_changed to be emitted on the parent, not the 
child.  So perhaps we have another problem lurking here...

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

I disagree.  We should not be generating a storm of events when a reorder 
occurs.  If this is the current gail/atk behavior then we have a problem.

Given the assumption that we do not generate ATK signals on every 
changed/reordered cell (which may be a false assumption, given the current 
implementation), we need an aggregated signal from GtkTreeView, not lots of 
little ones.

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

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland