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

Ooops.  I meant to say that GailTreeView (the parent) generates
the children_changed signals.  The arguments passed with the signal
specifies just those children that have actually changed.

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

I do not believe that range_changed ever got generated when row reorders
or column reorders occur.  I assume that the GtkTreeView
"columns-changed" signal and the GtkTreeModel "reordered" signal (meaning
rows) are not being affected by this proposal, or am I wrong?
 
> 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.

For row/column reorder, yes just one signal should be received and passed
along via ATK.  This is how GtkTreeView used to work, and I do not think
this proposal is changing this.  However if many cell values change,
then many children-changed signals do get generated. 
 
> >> 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