Re: [g-a-devel] proposing ATK/AT-SPI API additions

[Mike Gorse <mgorse novell com>]

Thanks for the reply,

On Mon, 17 Jan 2011, Piñeiro wrote:

> > I also propose to add an atk function with the following prototype if
> > no one objects / people think it makes sense:
> >
> > gpointer atk_object_get_native_window_handle (AtkObject *accessible);
> >
> > This would return a handle from the native windowing system for the
> > given object, if available.  It may return NULL.
> >
> > I have had a discussion with someone who is working on porting a macro
> > language from Windows and requested this functionality.  Apparently it
> > is possible with this package to change the title of a window, for
> > instance, and this can be done under Windows but not through AT-SPI
> > under Linux. Both of these additions would also help for the
> > AT-SPI-to-UIA bridge, since UI Automation exposes functionality
> > corresponding to what I am describing.  I am not really sure what I
> > think of the get_native_window_handle bit, since it would allow a
> > program to do things other than what an end user could do, so I am not
> > sure if there are security implications.  Perhaps similar
> > functionality is already available through X, though, in which case I
> > don't think it would create significant security issues beyond what is
> > already there.
>
> Instead of exposing the native window handle, what about expose the
> missing functionality? You mentioned that your proposal would solve
> the missing functionality compared to the Windows UI Automation, but,
> does the Windows UI Automation expose the native window handle or that
> functionality?

Elements have a property called NativeWindowHandle (which I currently 
can't implement very well based on the information that AT-SPI provides). 
I don't know how (or if) people are actually using this.

> Because this solution seems something like "expose the more
> common/identified functionality, and then expose the native window in
> case the apps wants to do extra things". As both ATK/AT-SPI tries to
> expose the information in a standard/homogenous thing, this sound as a
> open door to do "whatever they want".

When we are talking about functionality available to a user, then I agree 
that it should be exposed in a standard way.  Tobias was specifically 
asking me for a way to programmatically change the title of a window or 
for a way to get the native X handle for a window so that this could be 
done through X.  Changing a window title seems to me to fall into the 
"whatever they want" category rather than being functionality that I would 
expect ATK/AT-SPI to expose, since there is no corresponding way for a 
user to do this, whereas there generally is with existing ATK/AT-SPI 
methods.  So, for this case, I feel like we should either provide the 
native window handle or not expose anything.  The counter-argument is that 
exposing the window handle could lead to people writing code specific to 
particular windowing systems, but what I was being asked for seemed 
somewhat obscure to me.

> In the same way, if the native window handler is exposed, IMHO, it
> would be also required to expose somehow, the native window system, so
> the AT tool could do something like:
>
>  window_system = atk_thing_get_window_system_description ()
>  window = atk_thing_get_native_window_handler ()
>
>  if (window_system = X)
>    do X things with window
>
>  if (window_sytem = wayland)
>    do wayland things with window

Good point.

> Anyway, I'm not saying that this is a bad idea. Ie, both clutter and
> gtk allows to get the native window handler (via clutter backends or
> gdk respectively), so we can thing in something similar here. I just
> would to debate if this is required or if it would be better to just
> expose the missing functionality.

BR,
-Mike G-