Skip to content
This repository has been archived by the owner on Feb 23, 2021. It is now read-only.

Latest commit

 

History

History
159 lines (88 loc) · 6.54 KB

244.md

File metadata and controls

159 lines (88 loc) · 6.54 KB
Raw
original_url created_at updated_at status type reporter owner priority milestone component version
2009-02-21 09:37:47 -0800
2015-10-23 10:27:28 -0700
assigned
usability
mitch.haile@…
jeremyhu@…
Nice to Have
later
xserver
2.3.2 (xserver-1.4.2-apple31)

Accessibility API bridging

Currently using 2.3.2.1.

The X11 windows do not appear in the AX* objects.

For example, AXMainWindow, AXFocusedWindow, etc are not implemented.

I am looking at X11 using the Accessibility Inspector Sample Code:

http://developer.apple.com/samplecode/UIElementInspector/UIElementInspector.dmg

<AXApplication: “X11”>

Attributes:

AXRole: “AXApplication” AXRoleDescription: “application” AXChildren: “<array of size 1>” AXFrontmost (W): “0” AXHidden (W): “0” AXFocusedUIElement: “<AXApplication: “X11”>” AXTitle: “X11” AXMenuBar: “<AXMenuBar>” AXWindows: “<array of size 0>” AXMainWindow: “(null)” AXFocusedWindow: “(null)”

All I'd like to do is get the window list and be able to manipulate the window dimensions through AX*. This is to enable apps like Mercury Mover to manipulate X11 windows.

I would be more than happy to test any patches.

mitch.haile@… commented on Feb 21, 2009

Sorry about the mess; I always forget Trac thinks everything is a Wiki. Here's the real snippet:

<AXApplication: “X11”>

Attributes:
   AXRole:  “AXApplication”
   AXRoleDescription:  “application”
   AXChildren:  “<array of size 1>”
   AXFrontmost (W):  “0”
   AXHidden (W):  “0”
   AXFocusedUIElement:  “<AXApplication: “X11”>”
   AXTitle:  “X11”
   AXMenuBar:  “<AXMenuBar>”
   AXWindows:  “<array of size 0>”
   AXMainWindow:  “(null)”
   AXFocusedWindow:  “(null)”

jeremyhu@… commented on Feb 21, 2009

  • Milestone set to 3.0

I'll look into this in the future, but it's not a high priority right now, sorry. I'm not even familiar with the accessibility framework to know how difficult it would be to implement. If you were willing to do some research or submit some patches, it would certainly speed things along, but I don't see this coming about in the next few months.

mitch.haile@… commented on Feb 21, 2009

Sure, I can help out:

The first step is to get AX data for Window objects exposed.

I can imagine two ways to do this; since quartz-wm isn't open source (it's not applewm.c in the xorg git tree, right?), I am not sure I can comment on the best approach.

  1. Assuming quartz-wm is creating NSWindow objects that correspond to X Window objects, maybe it's good enough to somehow reflect (proxy) the published AX data out of quartz-wm through the X11 "app". I am not quite sure what the cleanest way to build this would be. I think I can test the possibility of this by modifying UIElementInspector to dump AX data from a specific pid, but I haven't sorted through the code yet.
  1. Another option would be for the X11 app to use XQueryTree() to present AX data representing Window objects known by the X11 server.

Based on my 30 minutes of reading up on the AX docs on developer.apple.com, I am guessing either approach is do-able--there's a lot of chatter in these documents about how to provide AX information for custom widgets. Exposing windows is the first step to exposing widgets, but Apple seems to assume everyone is using WindowPtr/NSWindow, so there's a little investigation to be done, but hopefully it's no different to serve up a window object vs. a non-OS button object.

If you have any insight or suggestions here, please let me know.

jeremyhu@… commented on Feb 21, 2009

quartz-wm doesn't actually own the windows. The windows belong to X11.app (the X server) as far as OSX is concerned. You could even replace quartz-wm with twm, and it should still work.

It's not creating any NSWindow. The windows are a much lower level than that. It's CG, not NS. That's what concerns me. We're not Cocoa (and it's not trivial to become Cocoa).

Therefore, it looks like we'll need to treat our windows like "custom widgets" and go that route.

mitch.haile@… commented on Feb 21, 2009

Right. So I'll look at how to use XQueryTree to serve up dummy Window AX objects.

jeremyhu@… commented on Apr 18, 2010

  • Status changed from new to assigned

<rdar://problem/4606472>

ross@… commented on Mar 19, 2014

I'm attempting to use apps like BetterSnapTool which resize and move windows using the a11y APIs but my X apps don't move, presumably because of this. I might be foolish enough to attempt adding this (no experience of ObjC, but plenty of C and have worked on X before) if someone can give a few pointers...

jeremyhu@… commented on Oct 23, 2015

Mass Edit

As you may have noticed, we have had issues with spam in trac for the past couple years. We've decided to migrate to using freedesktop.org's bugzilla for our bug tracker (more details will be coming on the mailing lists in the next couple weeks).

I don't want us to loose valuable bug reports in the transition, so I want to make sure that any relevant open issues in this MacOSForge trac are migrated over to the new system. If you are interested in this issue, please take a few minutes to file a new bug for this issue in bugzilla. Please make sure to do the following:

  • Copy over all relevant information into that report, just in case we loose this one.
  • Set the URL field of the bugzilla report to this trac ticket's URL.
  • Paste the URL of the new bugzilla report as a comment in this ticket, and I'll close it out.