On Oct 10, 2009, at 2:55 PM, Martin Pilkington wrote:
Hey,
I'm wanting to write code that will drive another application via the accessibility APIs. Now to make things simpler for myself I'm wanting to wrap this in Cocoa APIs. NSAccessibility provides 99% of what I need, but doesn't seem to provide a way to get the AXApplication of another item. I'm hoping to take an approach where I have an object that represents a UI element and contains an AXUIElement, which will then implement NSAccessibility (mostly because the API is already there and so I don't have to invent my own) which will call the appropriate.
Now that is the bit that's obvious to me, what isn't so obvious is how well the various other parts of NSAccessibility interact with the C based AX APIs. Would I be right in assuming that all the string constants for notifications, attributes, roles etc in NSAccessibility are the exact same constants as defined in the AX APIs and so I can use them interchangeably due to toll free bridging? And when dealing with notifications, if my objects add themselves as observers to NSNotificationCenter, when I receive a notification via the AX APIs can I use NSAccessibilityPostNotification() to then forward that to the notification center observers?
NSAccessibility never interacts directly with the C-based AX APIs. An assistive app, such as yours, calls the C-based AX API. The AX framework communicates with the appropriate application using interprocess communication. It is in that other application that NSAccessibility methods are called to return the appropriate information, which get set back via IPC to the caller of the AX API in another process. The AX APIs are client APIs running in one process, the NSAccessibility API are the 'server' API running in a completely different process.
NSAccessibility is the protocol that objects in an application implement so they can report accessibility information.
I definitely understand your goal, to write a small Cocoa wrapper around the AX APIs, and the approach you describe is reasonable. However, it will probably become a little confusing for you to reuse the NSAccessibility protocol as the API of your wrapper object.
Since you already know that the object of your custom class is an accessibility UI element, it might make sense, for instance to drop the 'accessibility' from the names of the methods in your custom class. Again, it is up to you, but using the same exact API that AppKit uses as the accessibility info 'server', also as the API for your accessibility client object is bound to cause some confusion at some point.
Your assumption is currently correct, but you shouldn't rely on that assumption if you don't need to do so. You could always imagine a case where for some reason we need to munge the incoming string from a client and report it as a slightly different string to the application. If we were to do that then the AX and NS strings would not be the same, and your assumption would break.
(There should be no need for you to make that assumption anyway. If you find constants defined in one place that are not in the other, please file bugs.)
Finally, NSAccessibility notifications do not interoperate at all with NSNotifications. A Cocoa application, using the NSAccessibility API can only send an accessibility notification using NSAccessibilityPostNotification(). It has nothing to do with NSNotifications or NSNotificationCenters. It tells the application to send a cross-process notification to any clients of the AX APIs who have registered for particular accessibility notifications (using the AXObserver APIs).
-James
Thanks
---------------------------------
Martin Pilkington
Writer of Weird Symbols
--------------------------------------------------
James Dempsey
AppKit Engineering
Apple