Re: [orca-list] Orca/KDE issues and what we need to do?

[Piñeiro <apinheiro igalia com>]

From: "Alex H." <linuxx64 bashsh gmail com>

> I'm coming at this from a semi-advanced user and just want to know
> what's up with KDE and their accessibility.
>
> 1. What needs to be done to make KDE accessible to Orca? Does a new
> wrapper need to be written to convert KDE window classes etc into GTK
> ones? In other words, reclass windows to make them visible to
> at-spi/orca?

When at-spi was reimplemented to use DBUS (at-spi2) it was splitted:

     * at-spi2-core: the common part

     * at-spi2-atk: specific ATK part, including the bridge. This is
       used for toolkits that implements ATK (Gtk, Clutter)

     * qt-at-spi: equivalent to at-spi2-atk, for qt. Qt doesn't
       implement ATK, so it is required a different way to do the
       communication user application<->at-spi

AFAIK, after some informal conversation with Jeremy Whiting, the
problem with qt-at-spi is that it was created several months ago, and
although it worked on that time, after the changes on the core, it is
not working anymore.

> 2. If KDE is totally different and it requires more work than above,
> is it more likely we'll see Korka or something totally different?

No, in theory this shouldn't be neccesary. Orca "talks" with at-spi
using pyatspi, the python bindings, and AFAIK, this is something
defined on the core. In that sense, the toolkit in the other side
should be transparent to orca (or almost). So the communication
at-spi<->AT application should be always the same.

AFAIK, that was one of the reasons to split at-spi2 in core, atk,
etc. Be able to implement specific-toolkit things, but maintain a
common core.

> Hats off to the orca devs and to making GNOME/Linux accessible and I
> hope one day to join you guys!

If you want more to dig deeper, qt-at-spi repositories here [1][2]


[1] http://gitorious.org/qt-at-spi
[2] http://gitorious.org/~jpwhiting/qt-at-spi/jpwhitings-qt-at-spi

===
API (apinheiro igalia com)