Re: Proposed GtkTreeView API change

[Bill Haneman <Bill Haneman Sun COM>]

Tim Janik wrote:

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

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.

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

-Bill

>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.
>
>> 
>> Thanks,
>> -Jonathan
>> 
>
>---
>ciaoTJ

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