[g-a-devel]Re: gnopernicus question: why only report selection on combox.

[Bill Haneman <bill haneman sun com>]

Hi Remus:

I am glad to hear that gnopernicus can handle various event orders.

However, gnopernicus should handle the general case of selection-changed
events for different ROLES, not just one or more specific ROLE, since
the at-spi roles are designed to allow new roles to be registered by
applications.

Your current logic means that the selection-changed event does not
result in user feedback for new roles, or in fact for any existing roles
other than combobox.  I do not think this is correct, as in the general
case a user will need to be informed of changes to the selection of the
currently focussed object, at least.  You are correct in preventing
redundant or duplicate information being presented to the user, so you
do need to handle the case of 'focus' plus 'selection-changed'.  The
problem with doing it the way you currently handle it is that it fails
to achieve our goal of presenting useful information to the user for the
'general' ROLE case.

It seems to me from Bolian's original question that gnopernicus current
logic is not working for evolution's selection events.  However, adding
special cases for those ROLEs is not the most flexible approach, it
would be better to handle consecutive "selection-changed" and "focus"
events in a general way.  If you handle this generally, rather than by
role, you are more likely to work properly with lots of different
applications and toolkits (evolution, mozilla, Java, gtk+, Qt/KDE,
StarOffice, etc.).

I think that this is a very strong argument, and it's the way at-spi was
intended to be used.  Special casing according to 'ROLE' type was never
intended as a secondary technique, not something we want to use if
alternate, more general logic can be used instead.  In all cases we need
to handle the general case effectively, i.e. when we don't know the ROLE
or the ROLE doesn't match one of our special cases.  

- Bill

On Wed, 2003-09-10 at 06:33, remus draica wrote:
> 
> Hi Bill,
> 
> Please read my comments.
> 
> Regards,
> Remus
> 
> On Tuesday 09 September 2003 15:23, Bill Haneman wrote:
> > On Tue, 2003-09-09 at 13:07, remus draica wrote:
> > > Hi,
> > >
> > > Because in other cases this event is followed by a focus: event. In case
> > > of menus after a selection-changed event for the menu a focus: event for
> > > new focused item will came. So, gnopernicus is interested by this event
> > > only in case of combos.
> >
> > Remus:
> >
> > I don't think you can or should count on this behavior.  Recall that we
> > DO NOT guarantee even the order of event delivery, and we certainly do
> > not guarantee that focus: events follow all selection-changed events.
> 
> IN NO CASE GNOPERNICUS MAKES ANY PRESUMPTION THAT EVENTS SHOULD BE IN A 
> PARTICULAR ORDER.
> 
> Let say that you typed 2 characters in a text field. Then, all next events 
> will be received:
> 	1. text-insert
> 	2. caret-moved
> 	3. text-insert
> 	4. caret-moved
> 
> First 2 events are fired when first char is typed and last 2 when the second 
> char is typed. Event #1 and #2 can came in any order. Same observation for #3 
> and #4. But in no case  ALL events can came in any order, let say #4 #2 #1 
> #3. Also I think (and hope) that situation never happens because of at-spi.
> 
> >
> > If you wish to ignore selection-changed events for menus only, that
> > might be appropriate, but I think that it would be safer and more robust
> > to ignore "focus:" events that immediately follow selection-changed
> > events and which are the same as the newly-selected item.  That would be
> > a more general and robust heuristic.
> >
> 
> I don't think this is a good idea, because till now, in case described above 
> everything works ok. If you have any STRONG argument, please let me know.
> 
> > - Bill
> >
> > > If you know a case in which gnopernicus is not working properly, please
> > > let me know.
> > >
> > > Regards,
> > > Remus
> > >
> > > On Tuesday 09 September 2003 13:54, Bolian Yin wrote:
> > > > Hi,
> > > >
> > > > currently gnoperniucs only report "selection-changed" signal when the
> > > > current focused widget is a combox, why not report it on all object
> > > > that support selection interface?
> > > >
> > > > Thanks,
> > > > Bolian
> >
> > _______________________________________________
> > Gnome-accessibility-devel mailing list
> > Gnome-accessibility-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>