Re: [g-a-devel]grabFocus ...

[Bill Haneman <bill haneman sun com>]

On Tue, 2002-08-27 at 09:56, Michael Meeks wrote:

> 	Also; I think I'm going to have to add an 'async' 'doAction' method,
> since currently it's a roundtrip thing, and it seems if you 'do' an
> action such as 'Open' which throws up a file dialog; you get to block
> at-poke in the CORBA mainloop waiting for the Open dialog to return.

Actually this is a problem for AT also, since without threading its own
event loop (which I don't think is currently safe), the AT won't receive
events from the dialog.

However I don't think adding API is the right solution here; the
existing doAction call should return (synchronously) as soon as the
action in question has been invoked, not on action completion.  I don't
think this violates our semantics, the purpose of the boolean return
value is to indicate whether the action was invocable, and I don't think
that a different definition of "success" is very meaningful (for
instance there is little use in returning "false" for a dialog if the
dialog is cancelled, just the fact that it was, or soon will be, posted,
is the information of most interest).

This presents some challenges for the toolkit-side since it's fairly
easy for a developer to write a UI such that a button click call doesn't
return immediately; but I think this is a problem for the 'bridge' side
(i.e. the code that connects the UI components with the accessibility
API).  The doAction 'bridge' code needs to return its boolean
immediately; the potential issue is of course that the requesting party
(i.e. the assistive technology) doesn't get synchronous notification of
when the action is complete, but only notification of whether the action
request was/will be honored.  However I don't think that this is
substantially different from most other AT control flow, where things
are event driven.

The same problem exists in the Java accessibility implementation,
currently, by the way.  

So another reason for not using new API is that the existing API won't
be useful unless it's changed to behave 'asynchronously' with respect to
the action invocation.

Best regards,

-Bill

> 	[ That's normally fine for an AT since they don't have GUI's but
> somewhat sub-optimal. Sadly it needs new cspi API to make it
> asynchronous really ].
> 
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>