[Kde-accessibility] [Accessibility-atspi] Accessible objects without Atk dependencies
Olaf Jan Schmidt
ojschmidt at kde.org
Wed Mar 29 15:17:23 CEST 2006
I agree with Richard and Bill that we need more people working on AT-SPI.
One of the reasons KDE developers did not contribute to AT-SPI so far is that
we have very few people knowing CORBA, which makes contributing to AT-SPI
very difficult for us - and seemingly for most IBM and Sun developers (apart
from Bill and Peter) alike.
I know people who would love to use AT-SPI for KDE4-based assistive
technologies, but currently there are no Qt/KDE bindings that allow us to do
We have several options to create these bindings:
1. Write code that bridges the gobject-based AT-SPI bindings to QObject-based
bindings, which probably involves solving the problem of having two event
loops. This approach is a lot of work, and it is no fun, which means that
volunteers are unlikely to work on it.
2. Write an IDL compiler that creates both gobject-based and QObject-based
bindings for AT-SPI. This approach is more work than option 1 or 3, but it
fits our agreed long term strategy. I don't know whether there are KDE
developers who want to work on this, and it seems none of the GNOME
developers are willing to contribute in the forseeable future.
3. Implement the AT-SPI API on top of DBUS, in addition to the CORBA version.
Qt4/KDE4 applications will be able to talk to both versions, so the existing
assistive technologies will not suffer. This is more work than option 1, but
we could start with a subset of AT-SPI to quickly have workable results. Once
the bindings are tested and stable, we can write the necessary bridges to
make sure that application using the glib-based bindings can also talk to the
KDE4-based assistive technologies (using option 1, option 2 or an external
CORBA-DBUS bridge). It seems most likely to me that people would be willing
to work on this.
Whenever I tried to convince KDE people to work on option 2 or 3, Bill
objected saying that we should not work on a DBUS-version of AT-SPI at the
current point of time. This gave me the impression that Bill favours option
1, and this is why I asked when the number of dependencies on the existing
AT-SPI implementation will be reduced.
I fully understand that Bill does not want to spend time on reducing
dependencies if we are planning to move to DBUS anyway at some point in the
future. What I don't agree with is discouraging KDE people (who would not be
able contribute to a CORBA-based version anyway) to work on the DBUS port of
AT-SPI, or calling this "NIH".
I know that Bill will be away for two months soon. Harald (who writes the
AT-SPI bridges for Qt) will also be on holiday for some weeks. When both of
you are back, then we will hopefully have DBUS support in the KDE4
development versions, which will put us in the position to start implementing
option 2 or 3.
[ Richard Schwerdtfeger ]
> Given the enormous task of managing the ATK/AT-SPI code base I believe Bill
> has done an incredible job.
I fully agree.
> Bill is an overwhelmed one-man band and we need to put more resources on to
> help rather than setting off a grenade.
Yes, we need more people contributing, and to achieve this, we must make sure
that AT-SPI is as easy to use as possible. For KDE developers, means DBUS.
Otherwise AT-SPI contributitions will stay limited to a very small number of
full-time paid experts.
Please remember that accessibility is not only about blind people or severely
impaired users. There is a huge number of needs - both for people with
disability and for people without disabilities. Some of these needs can
easily be met with small, modular tools. And some of these smaller tools can
benefit a lot from AT-SPI if using it is not too complicated.
A good example for this is GOK. GOK is a very sophisticated assistive
technology that works really great for people with severe mobility
impairments. But at the same time, there are people with other disabilities
that need an easier solution that can be used with the standard mouse. If we
only look at the big assistive technologies, then we forget the need to make
usage of AT-SPI simple enough for the authors of smaller tools.
> It also seems to be to be putting the "cart before the horse" to insist on a
> gnome-library-free accessibility stack before KDE application developers are
> willing to start testing their own applications' accessibility, or to start
> writing some AT-SPI based technologies.
I fully agree with you that it would be foolish not to test the accessibiilty
of KDE applications because the tools are not native. At the same time,
please keep in mind that most KDE developers are volunteers. Accessibility
testing is not exactly fun, and this is why I want to make it as easy for
them as possble. Every additional library and application that needs to be
installed might prevent some developers from doing these accessibility tests
- not because of bad intention or because of "NIH". It would simply mean
extra work to install the additional tools, and people would say "I'll do it
later" and forget about it.
> For instance, I have taken another look at the libbonobo/bonobo
> dependency issues in the atk-bridge today (presumably this is one of the
> areas where KDE would most like to reduce the number of GNOME libraries
> linked in). The dependencies do seem of a manageable size and sort, but
> on the other hand, libbonobo is not huge (about 1 MB), and you'd have to
> replace it with something (e.g. new code) if you removed it. It's the
> sort of thing that a patch could be reasonably created for.
> Frankly I think a patch to remove the bonobo-activation dependency
> (replacing it with DBUS activation, presumably) would make a lot more
> sense at this time, in terms of cost/benefit. That would be a nice
> opportunity for someone to fix the 'activation of remotely-displayed
> apps' problem as well, and to allow one AT-SPI registry per display -
> presuming DBUS can currently support that use case (i.e. per-display,
> user-agnostic activation and query).
Thanks for spending the time to come up with a specific suggestion where
people might be able to contribute.
Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards
accessibility networker, Protestant theology student and webmaster of
http://accessibility.kde.org/ and http://www.amen-online.de/
More information about the kde-accessibility