[Accessibility] [Kde-accessibility] Orca/KDE Integration
Bill.Haneman at Sun.COM
Wed Aug 30 11:28:05 PDT 2006
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...
>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
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
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
Everything interoperates immediately, as in #1. Fairly
short lead time,
proven infrastructure. KDE code sees no gnome API
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
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 freedesktop.org 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.
>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
>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.
More information about the Accessibility