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

[Li Yuan <liyuan gnome org>]

+1 for the setSize, setPosition, and setExtents methods.

On Tue, Jan 18, 2011 at 3:09 AM, Mike Gorse <mgorse novell com> wrote:

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.

 I feel "if they can not get the window handle from X, we should not provide them the handle either".

Li