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

[Bill Haneman]

Hi Eric:

When you mentioned that Java and GTK+ were "frightening you", I took 
that to possibly mean that you thought ATK implied GTK+.  I think we're 
"on the same page" now.

You also say "dependencies are evil" but then again code sharing and 
interoperability are good.  If you want to interoperate with anything 
other than your own program, you have to accept dependencies. 

"KDE-only" installations do exist of course.  But the majority of KDE 
installations are not so pure, and I daresay the majority of disabled 
users won't care about purity; they will of course care about 
performance and function , so one should be very conscious about the 
dependencies one accepts.  It is however a tradeoff.  It would be 
useless to blind users, for instance, to have an "accessible KDE 
desktop" with no gnome dependencies while the existing screen readers 
all link to Gnome libraries.  

What I have the most doubts about is whether maintaining the "two of 
everything" approach that has characterized the Free Software desktop 
throughout the KDE/Gnome epoch makes good sense for these complex 
assistive technologies.  I understand the desire of KDE developers to 
ensure that all these features work in all KDE deployments, but it means 
dilution of effort.  I can speak from the experience of doing this in 
Gnome for six years, that it is far from easy, and I would be willing to 
bet that it will take much longer than you imagine.

For this reason I think KDE developers and KDE users will both get the 
most value out of reusing key parts of the existing "gnome 
accessibility" codebase now, with the goal of moving as much as possible 
to a shared codespace with reduced, shared dependencies later.   For 
example, the pango dependency in ATK is nearly trivial and could easily 
be removed, and various ways in which any ORBit2, Bonobo, or even CORBA 
dependencies in orca, gok, and at-spi could be eliminated are under 
active discussion.

ATK's only "gnome-ish" dependencies are glib/gobject (which are not 
separable,  the two are part of the same package) and pango.  cairo is 
not a dependency, nor is the gnome filesystem, and you don't have to use 
a cairo-dependency version of pango.  As I said above, the pango 
dependency is really quite trivial; a few minutes hacking configure.in 
and a couple of #ifdefs should produce a binary-compatible libatk 
without pango which KDE could use.  Also, to clarify, while ATK links to 
glib/gobject, it doesn't require the use of the glib mainloop, so the 
mainloop integration issues which have been mentioned for atk-bridge 
re-use should not be a concern here.

Best regards,

Bill


Éric Bischoff wrote:

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