Re: Proposed GtkTreeView API change

[Tim Janik <timj gtk org>]

On Tue, 11 Sep 2001, Bill Haneman wrote:

> Tim Janik wrote:

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

i think if you're going to make syncronous two way CORBA calls from
row changes, you'll end up with really bad performance. depending on
the model being in use, row updates may be huge, say 100+ rows changed
in response to a single button click.
also, you might get yourself real reentrancy hadaches, e.g. for call
stacks like:

main()
gtk_main()
[...]
gtk_button_clicked()
[...]
application_clicked_handler()
appmodel_foo_update()
appmodel_bar_update()
[...]
gtk_tree_view_row_changed()
[...]
atk_row_changed_handler()
CORBA_two_way_row_changed()
CORBA_wait_for_response()
[...]
CORBA_handle_incoming_request()

and then have CORBA_handle_incoming_request() query stuff from tree view
or button, etc..., just because appmodel_bar needs to do some shuffeling
for a while.

i don't think there's a good way around aggregating row changed signals,
especially if you have to take incoming CORBA calls while emitting atk
notifies.

as for when the end of a "group" of changes is reached, "group" here is
certainly pretty arbitrary. in the above scenario, which is what will
happen most times, your best bet is to implement atk_row_changed_handler()
via an idle queue, i.e. something like:

atk_row_changed_handler (guint row)
{
  atk_row_hash_add (row);
  if (!atk_idle_handler_id)
    atk_idle_handler_id = g_idle_add (atk_idle_handler);
}
gboolean
atk_idle_handler ()
{
  GSList *ranges, *node;
  
  atk_idle_handler_id = 0;
  
  ranges = atk_row_hash2ranges ();
  for (node = ranges; node; node = node->next)
    atk_notify_row_range_changed (node->data);
  atk_row_ranges_free (ranges);
  
  return FALSE;
}

that also gives you lesser reentrancy problems for incoming CORBA
calls from atk_notify_row_range_changed() as the call stack above
that function is pretty flat.

> 
> -Bill
> 

---
ciaoTJ