Re: Notification of shadowing by gtk_grab_add()

[Owen Taylor <otaylor redhat com>]

Bill Haneman <bill haneman ireland sun com> writes:

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

There seem to me to basically be two architectures possible here:

 3rd party AT <=SPI=> AT Daemon <==> AT Module <-> GtkSocket
                                                      |
                                                      |
                                                   GtkPlug


 3rd party AT <=SPI=> AT Daemon <==> AT Module <-> GtkSocket
                                \                      
                                 \                     
                                  --> AT Module     GtkPlug


The first, whether the communication betwen GtkSocket and
PLug is the AT SPI or a hand-crafted protocol is
unattractive because:

 - Plug/Socket would require detailed knowledge of the AT
   apis so they could proxy them.

 - The Socket/Plug communication channel (XSendEvent (!)) needs
   to be elaborated to carry vastly more information then
   it does currently.

The second requires somewhat more complexity at the glue
level seems fundementally more workable.

The only addition necessary to the GTK+ level API would seem
to be the concept of a "remote handle" accessibility context
from which an XID could be extracted and a new connection
opened to the other process.

Regards,
                                        Owen