Re: Notification of shadowing by gtk_grab_add()

[Bill Haneman <bill haneman ireland sun com>]

Owen Taylor wrote:
 [...]
> 
> So, there ends my account of changes to the GTK+ core that
> have come up in my quest for for a really robust and fully
> functional plug/socket implementation.
> 
> I'll give people a few days to comment, then start committing
> this stuff, starting from the more straightforward parts.
> 
> Regards,
>                                         Owen

We have been worrying a bit over the treatment of plugins generally
(not just GtkSocket/GtkPlug).  In order to support an accessibility
API,
the plug/socket must be able to communicate all the information
in the API between one another.  It's cleanest if the two can
do this transparently, so that API calls on the socket are
passed to the plug and treated as though the plug's widgets
were local.  Barring that, the plug and socket will need to make
this information available over another channel.

In addition to the GTK+ accessibility API which the widgets and
applications will need, there is another API layer (really an SPI)
which GTK+-based applications will need to support, via a
bridge layer.  This SPI layer is the layer that actual assistive
technologies like screen readers, braille displays, screen magnifiers,
and alternate navigation devices will connect to.  (Though one
can conceive of ATs talking directly to a GTK+ accessibility API,
this would require much code duplication from AT vendors and
be problematic because of the need for consumers of the GTK+
API to be in-process).  

Since most existing AT is Wintel-specific, it is important to provide
a single SPI, to make porting more attractive - thus the SPI layer
would ideally be used by not only GTK+ and Gnome clients, but 
exported by things like OpenOffice.org and Mozilla clients that
might have their own internal accessibility APIs.  That is not
to say that we wouldn't like to have at least parts of the GTK+ 
accessibility toolkit reusable by non-GTK+ applications, but we
can't assume that it will be so.

So one solution would be to have plug/socket use the AT SPI, like
any of the other members of a "heterogeneous" desktop.  But this
SPI hasn't been specified yet, though we know its general shape :-(

The alternative is for plug/socket to implement the accessibility API
so that, for instance, a request for a socket's accessible child
widget "accessibility handles" would work as though the plugin's
widgets were local.

This is not a trivial task, but without it no plugin can be properly
"accessible".

Regards,

Bill

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