Re: Orca [Accessibility] [Kde-accessibility] /KDE Integration

Olaf Jan Schmidt wrote:

[ Bill Haneman ]
Like you, I worry about the performance. It seems to me like a lot of
work just to avoid using ORBit2 in the short term...

Short term?

Sorry to disappoint you, but KDE 4 will still take some time. We can only make medium to long term plans at the moment.
I am not sure we agree on what "short term" means.

Moving at-spi to a different back-end will also take time, possibly quite a bit of it, and it's not something that should be rushed.

The way I see it, the options for KDE boil down to a few basic approaches. I will assume first of all that gconf or activation-related issues are solvable short-term (and I am confident that they are, with a bit of will), and I'll similarly assume that any spurious dependencies can be purged from the existing implementations. So the possibilities look like this:

1) Bridge from QAccessible to ATK and use ATK as the in-process KDE accessibility API. Then KDE apps can reuse all the "gnome" code and will seamlessly interoperate with our existing AT-SPI clients (GOK, dasher, gnopernicus, orca). KDE apps will be accessible when run in the Gnome environment, and vice-versa, and OpenOffice and the mozilla suite (as well as some commercial software such as Adobe Acrobat reader) will will be accessible when run in the KDE desktop.

Pros: Everything works short-term, no new IPC code required in KDE codebase short-term, maximum code reuse. Proven infrastructure. Shortest lead time. AT-SPI dependencies are invisible to KDE code and gnome libs are only loaded if available
           and required for accessibility.
Cons: KDE takes on a glib dependency which may be unpopular. KDE Accessibility doesn't work without the Gnome libraries. KDE Assistive technologies must link to a CORBA ORB (albeit possibly via cspi or python bindings which may hide this effectively and permit a simple swap-out of the backend later).

2) Extend QAccessible to provide all the features required for AT-SPI's methods (see IDL), and use the QAccessiblePlus as the KDE in-process accessibility API. Write QAccessible-to-AT-SPI (or QAccessible-to-ATK) wrappers, and load the existing atspi libraries at runtime until such time as a dbus at-spi backend is mature and shared by both desktops. Pros: No glib dependency, KDE and Qt application APIs remain "KDE native". Everything interoperates immediately, as in #1. Fairly short lead time, proven infrastructure. KDE code sees no gnome API dependencies (except
           possibly the bridging code above).
Cons: QAccessible must be extended and bridged - more new code than #1. Short-to-medium term, KDE accessibility requires gnome libs at runtime. KDE assistive technology situation same as in #1 above. Some "disposable" code required which will be replaced when AT-SPI shared dbus backend
          becomes available, longer term.

3) Create a new dbus ABI based on the existing AT-SPI IDL. Write to this inside KDE, instead of AT-SPI.

Pros: No gnome libs in KDE, even short-term. Forward-looking. KDE doesn't have to wait for consensus before writing code. Works for embedded environment fairly soon. KDE assistive technologies don't need to use gnome libs even short-term. Cons: KDE apps not accessible when run under Gnome, and vice-versa. OpenOffice and mozilla suite not accessible under KDE. KDE assistive technologies don't work with OpenOffice and mozilla. 4) Wait for a new dbus ABI for AT-SPI to be adopted by consensus. Write to this as above.

Pros: Ideal code sharing and interoperability. No "foreign" libs required, only libs. Cons: Possibly a very long lead time, with an untested infrastructure. There could be delays in adoption by OpenOffice and mozilla. Performance problems and extensions of to dbus likely. May requires rewriting of some existing ATs. Maximum amount of new code required.

I am a little concerned about #3 becoming the de facto path if #1 or #2 are unacceptable. Since no one really wants to delay KDE accessibility, it's very tempting to press ahead with a new ABI. It's my sincere hope that such a new ABI effort be closely coordinated across the different desktops (even if KDE deploys it first), in order to preserve interoperability. I also think that if #3 goes ahead without a consensus outside of the KDE developer community, the momentum and motivation for #4 will be undermined.

On the other hand if #1 or #2 are something KDE developers wish to re-examine, I for one would be willing to put more time into addressing some of the downsides (activation issues, spurious dependencies, etc.) in the current at-spi libraries.

best regards,


KDE development is currently in an extensive API review phase, where all code in the libraries is evaluated for possible changes. Once this review is complete, we will have to stick with the API for a really long time.

Our short term goal is to educate the other KDE developers about what is needed in the applications and libraries to properly support AT-SPI. We can do this best if we can sell them a nice API that is expected to be around long term.

I agree with you that using atk plus the existing AT-SPI implementation (with gconf, bonobo etc) would have been a nice short term strategy to integrate KDE applications into the GNOME desktop accessibility-wise, but Qt3+KDE3 have too many limitations to do this and KDE4 is just not ready yet.

If we attempt to apply this short term strategy to our medium term plan of making the KDE4 desktop itself accessible, then it quickly becomes obvious that we need a different plan for this.

Neither you nor me would like to tell the KDE developers: "To make KDE4 accessible, the desktop will need to use CORBA+Bonobo. We will also have to restrict key parts of KDE Accessibility to those platforms where a suitable C++ ORB is available, at least until we have a consensus between all players to migrate to D-Bus. Both the desktop and all applications will need to read gconf keys and GNOME specific environment variables. There might be more, since we do not have a complete dependencies list of the current AT-SPI code available. A D-Bus migration might be a possible alternative, but the GNOME team discourages work on this (at least short term), citing interoperability concerns and likely performance problems. We also discussed removing some of the other dependencies, but it would not benefit the user to destabilise AT-SPI at the current point of time."

My hope is that we can decide on the long term plan for AT-SPI soon, so that we are able to define the KDE4 APIs accordingly. It shouldn't be too difficult to agree on a version of AT-SPI that fits the needs of both KDE and GNOME if we make this a joint effort.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]