[Kde-accessibility] my crazy thoughts

[Gunnar Schmi Dt]

Hello,

> [...]
> But before we agree on how to code the bridge, we have to agree on how =
KDE
> internally handles accessibility. Gunnar's and my idea was to use DCOP,
> so the bridge could be a DCOP service.
>
Well, that was an idea before the meeting on IRC. I thought there we had =
at=20
least decided to do the bridging within each KDE application (either as a=
=20
pard of the KDE-core-libraries, as a library each application has to incl=
ude=20
or as a library that can be loaded dynamically).

> [...]
> > I am dreaming, but Qwidgets could be extended using something like
> > QAccessible to hold all the information needed and dcop to export all
> > that information.
>
> As QAccessible and kde-libs code doing DCOP export already exist, this
> seems to be a very realistic approach.
>
> The approaches I see are:
> 1. Extend existing the qt object in DCOP in kde-libs (requires big chan=
ges
> in kde-libs)
> 2.1 Export a new accessibility object in a) DCOP or b) MCOP in kde-libs
> (requires big changes in kde-libs)
> 2.2 Export a new accessibility object in a) DCOP or b) MCOP at the
> application layer. This would not be a long-term solution, but rather a
> way of trying out things before moving them to 2.1 kde-libs later
> (requires small changes in kde-libs and an extra library to be imported
> by KDE programs that wish to be accessible).
> 3.1 Extend QAccessibleObject and export it to a) DCOP or b) MCOP in
> kde-libs (requires changes to Qt and kde-libs)
> 3.2 Export enhanced QAccessibleObject at the application layer using a)
> DCOP or b) MCOP to get started and switching to 3.1 later (requires
> changes to Qt and kde-libs)
> 4. Try to put everything into Qt, so pure Qt applications can use this =
as
> well
>
> I personally would prefer to go with 3
>[...]

I think we need to ask Trolltech to extend their QAccessible-architecture=
 to=20
something similar to the ATK-API. Then we can implement either of three=20
bridging approaches:
1) QAccessible <-> ATK <-> AT-SPI
2) QAccessible <-> AT-SPI
3) QAccessible <-> DCOP/MCOP-AT-SPI <-> AT-SPI

The first two approaches would add some dependencies on GNOME libraries o=
r on=20
CORBA. The third approach would put all dependencies into a stand-alone=20
DCOP/MCOP-CORBA bridge and would require the most work.

I would like to go for the first approach as all three have similar resul=
ts=20
and the first it is the one with the fewest work ;-)

BTW: Why exactly is the ATK-API based on GObject? Is it possible to modif=
y ATK=20
to be able to use some toolkit-independend classes (which then could be=20
instanciated through multiple inheritance from either GObject or QObject?=
)?=20
In that case we would only to do four things:
1) Ask Trolltech to base their extended QAccessible objects on those=20
toolkit-independent classes
2) extend the KDE classes
3) modify ATK to use the toolkit-independent classes in the API
4) Start KDE-applications, load the ATK-library and feel happy.

It would not matter if the ATK<->AT-SPI bridge would internally still use=
=20
Gnome libraries.

Gunnar Schmi Dt