Re: Orca [Accessibility] [Kde-accessibility] /KDE Integration
- From: Bill Haneman <Bill Haneman Sun COM>
- To: Olaf Jan Schmidt <ojschmidt kde org>
- Cc: accessibility-atspi freestandards org, kde-accessibility kde org, accessibility freestandards org, Harald Fernengel <harald trolltech com>, orca-list gnome org
- Subject: Re: Orca [Accessibility] [Kde-accessibility] /KDE Integration
- Date: Wed, 30 Aug 2006 19:28:05 +0100
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 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.
best regards,
Bill
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.
Olaf
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]