Here is the reply from Trolltech. Have fun, Daniel ---------- On Wednesday 27 November 2002 15:25, Volker Hilsheimer wrote: ---------- Subject: KDE Accessibility Date: Wed, 27 Nov 2002 15:25:21 +0100 From: "Volker Hilsheimer" To: Hi Daniel, I'm the author of the accessibility support in Qt, and Matthias forwarded me your summary of the first meeting. One of the issues mentioned that the Qt API for accessibility support was not versatile enough to be used by KDE, and that the implementation we have would need to be extended (and implemented on UNIX). Well, here is some infrastructure overview (from a Windows perspective), since the documentation of the Qt stuff is rather thin this might give some insight: On Windows, an application is queried by accessibility clients (like a magnifier or screen reader) for the accessibility interface (COM interface IAccessible) for a specific object. This is done via a window message WM_GETOBJECT to a window handle. - Qt receives the WM_GETOBJECT message Qt uses the static function QAccessible::queryAccessibleInterface( QObject*, QAccessibleInterface ** ) to get hold of the accessibility implementation for the widget that the WM_GETOBJECT message had been sent to. queryAccessibleInterface is cross platform - it loads the plugins that implement the factory interface, figures out which plugins implements a accessibility factory for the widget class in question (and goes up the class hierarchy if there is no plugin for that specific widget class, so MyPushButton:public QPushButton will get the accessibility implementation for QPushButton), and asks the factory for an interface to that implementation. The implementation and factory stuff is also all cross platform, and in a plugin that is part of Qt. - If Qt receives a interface pointer it creates a Windows specific wrapper around the cross platform interface implementation (the Qt accessibility interface is "easier" than IAccessible, but just as powerful), and uses Windows magic to return some integer value to the accessibility client (the WM_GETOBJECT message contains some information important for the Active Accessibility infrastructure which is used here). The accessibility client receives the pointer, and calls the functions via RPC (since IAccessible is a COM interface COM does all the magic for that). - Additionally to that, Active Accessibility provides a notification mechanism that allows applications to tell accessibility clients that something important has changed or happend (e.g. a checkbox changed it's state). The static QAccessible::updateAccessibility() is provided for that, and a large set of "event types" (e.g. ValueChanged) is defined in an enum (the enum values are identical to the respective values in Windows, but can easily be mapped to something else). Since Active Accessibility has been around for a while and is the standard and obviously approved infrastructure around on a lot of Windows desktops I would assume that the flexibility it offers is sufficient (so the interface we have in Qt is sufficient - it is even more flexible). If it is not sufficient it is trivial to add another interface and implement that as well in the plugins (e.g. right now we only have one default action, and can execute that action, but we could implement an interface that returns the list of public slots (without parameters), and that executes any of those slots etc). Implementing the communication layer between the accessibility client and the "server" is where CORBA - or whatever middleware - enters the scene. All you/we have to implement is a way for the accessibility client to ask for the interface to a widget, to call function of that interface, and to do something useful with the results. And maybe you could use the QAccessibleInterface directly without a wrapper implementation. Any RPC will do for that, and we would definitely be interested in putting some efforts into this (e.g. implement the server side for the RPC in Qt). Naturally, we would prefer this to be independent of e.g. CORBA ;-) The second platform dependent part is the notification mechanism, which is trivial enough. Well, please fwd. this to the respective lists/people. I would of course like to know more details about what parts seem to be insufficient or not flexible enough, so that we can add some fu in Qt. At least the implementations we provide for all the Qt widgets should be reusable. Cheers, Volker PS: And somebody should do something about the HTML of your webpage - it's somehow misformatted with IE and Mozialla ;-) ------------------------------------------------------- _______________________________________________ kde-accessibility mailing list kde-accessibility@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-accessibility