Acc

Hi!

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 
so.

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.

[Bill Haneman]
> 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

-- 
Olaf Jan Schmidt, KDE Accessibility co-maintainer, open
standards 
accessibility networker, Protestant theology student and
webmaster of 
http://accessibility.kd
e.org/ and http://www.amen-online.de/

_______________________________________________
kde-accessibility mailing list
kde-accessibilitykde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility

Acc

Thread: Acc