+1 for the setSize, setPosition, and setExtents methods. On Tue, Jan 18, 2011 at 3:09 AM, Mike Gorse <[email protected]> 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
_______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
