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

[Bill Haneman]

Hi Eric:

..

>  
>
>>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.
>>    
>>
>
>The good thing would have to think about this problem *before* writing ATK...
>  
>
We did, quite carefully.  This is why ATK has so very few dependencies.

>Technical question: how much of GNOME does ATK need? Would that be easy to get 
>rid of it?
>  
>
It doesn't need ANY of "gnome", other than GObject - which is what it 
does include, in its dependencies.  GObject is needed because ATK is an 
object-oriented C API and therefore some sort of object/type/signal 
system is required.  There really isn't a better cross-desktop 
candidate, as far as I am aware.

>>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.
>>    
>>
>
>DBus is probably at the center of those discussions? ;-)
>  
>
Partly.

>  
>
>>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,
>>    
>>
>
>These are second-degree dependancies, i.e. dependancies induced indirectly by 
>glib and pango. And these in turn induce third-degree dependancies...
>  
>
NO, this is incorrect.  I am beginning to wonder if you are just trying 
to invent objections, now.
A quick look at the dependency chain of glib/gobject will show almost 
nothing beneath it.

>In fact, when I see some software that needs pango, I usually stop installing 
>it, because there are good chances that it will pull half of GNOME behind it. 
>If GNOME users read this, please take no offence,
>
Sorry, too late.

> I am sure that you hesitate 
>a lot before installing something that has "kdelibs" as a dependancy. It's 
>the same. That's normal, it's just an administration issue.
>
>  
>
>>and you don't have to use a cairo-dependency version of pango.
>>    
>>
>
>Well, if you use a distribution "out of the box", there are good chances that 
>this dependancy exists. You said above that disabled users don't care about 
>purity, I also doubt that they recompile applications themselves ;-).
>
>  
>
>>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.
>>    
>>
>
>That sounds good. And what about removing glib?
>  
>
Not possible.

>  
>
>>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.
>>    
>>
>
>If glib is used in ATK only because of the gobjects, using C++ objects in ATK 
>instead of gobjects would be IMHO a good idea;
>- smaller code
>- more standard technique
>  (C++ is a recognized OOP language, while gobjects in C are kinda hack)
>- something easier to maintain
>- one major dependancy less for ATK.
>  
>
ATK is a C library, to allow it to be used in C based APIs such as 
Gnome.  It is also a mature interface with binary compatibility 
requirements. 

This is not the place for a C versus C++ discussion, it is not productive.

regards

Bill

>And the transformation from C with gobjects to C++, even if not trivial, is 
>somehow mechanical. For ATK, project, that would be a rather boring task to 
>do that switch, but it would have the merit of giving it a status of real 
>universal unix library.
>
>
>  
>