[Kde-accessibility] OpenOffice and KDE4 Accessiibilty [was: Orca/KDE Integration]

[Éric Bischoff]

Le Jeudi 7 Septembre 2006 12:51, Bill Haneman a écrit :
> Eric - I understand and agree with some of what you said, but I think
> you may have missed some of the point.  Running OpenOffice.org without
> gtk+ would be desirable for KDE, that's not quite what we're talking
> about.

Yes, that possible.

Perharps you missed my point too, Olaf ;-). I just said that "java" and "gtk+" 
were frightening me. Read again my message, you won't find the word "ATK" in 
it.

> The issue of GTK+ is separable from the issue of using ATK for 
> OOo accessibility, since ATK does not link to or otherwise pull in
> GTK+.  It pulls in glib and pango, but by comparison with the other
> gtk+/gnome dependencies this is very lightweight indeed!

And glib and pango in turn have dependancies (gnome-filesystem, libgobject, 
cairo, ...), which in turn have their own dependancies... So the notion of 
"lightweight" is very relative. The fact is that it won't run on a pure KDE 
system.

> Until fairly recently OOo used Java for all of its accessibility
> support.  On Windows this will continue to be the case.  There are
> indeed many downsides in using Java for this,

And for using Java in OOo at all ;-). In fact every dependancy to other 
technologies that are not directly related to the field of application can be 
perceived as a drawback, it's not only Java...

> which is why the OOo team 
> changed the Linux/Unix implementation to use ATK instead.

Okay, this is a point where I needed clarification. I was wondering whether 
ATK was Java-based. I just said that the words "java" and "gtk" were 
frightening me, wanting to stress that any solution that would be based on 
gtk or java would be suboptimal.

> However, if 
> for some reason KDE doesn't want OOo to use ATK when running in the KDE
> environment, reusing the already-existing Java accessibility code in OOo
> may still be the best alternative.

I know neither of both (ATK and old Java solution). Again, all what I wanted 
to say is that _dependancies are evil_ ;-).

Of course you need dependancies to be able to draw widgets. But the user 
should have the choice and not be obligated to mix environments.

> Also, realize that because OOo is based on its own custom widget set,
> moving the accessibility support to QAccessible would not just be a
> matter of porting to Qt, it would be considerably more work than that.

I have no idea of the technical implications of writing a Qt accessibility 
bridge. If ATK acts a a common, desktop-neutral, library of course it's a 
useless effort. However, from what you say above I'm wondering whether it's 
that much desktop-neutral (as pango and glib dependancies show), and if the 
Qt bridge solution is not at least worth evaluating the effort.

Perharps we should have people from Trolltech involved to assist us in the 
evaluation of the real implications. So far they have not been implied in 
this discussion.

> It's not clear to me that the result would actually do what you want or
> need, since the QAccessible API seems to provide only a subset of what
> AT-SPI needs for comprehensive assistive technology support, at least at
> the moment.  Certainly until full-featured KDE-based assistive
> technologies come on line (which will take some time), it makes sense to
> reuse the existing code base and interfaces so that OOo can continue to
> work with orca, gok, gnopernicus, dasher, etc. under the KDE environment.

I understand. But I think the user should have a choice, at least on the long 
run.


-- 
La monoculture informatique fragilise le système d'information, elle est aussi 
toxique pour les données de l'entreprise. (Guy Brand)