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-
_______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
