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

[Piñeiro <apinheiro igalia com>]

From: Mike Gorse <mgorse novell com>

Sorry for the delay of this answer.

> I would like to propose a few additions to ATK and AT-SPI:
> 
> - In atk, the size and position of a window can be get or set.  Gail
> - already has code implementing this for gtk widgets, but the
> - functionality is currently not exposed over at-spi; there are methods
> - to get the extents, size, and position of a window but no
> - corresponding method to set them.  I propose to add setSize,
> - setPosition, and setExtents methods to the at-spi Component interface.
> - The GAIL implementation of set_extents only affects top-level windows;
> - it does nothing for all other widgets.

This makes sense. *

> 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?

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

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

Although it is true that right now, ATK is X oriented (I need to add a
bug to the metabug related with that).

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.

> Does anyone have any thoughts?

* And reminds me that I didn't implement those function on Cally
  http://bugzilla.clutter-project.org/show_bug.cgi?id=2521

BT

===
API (apinheiro igalia com)