Re: OpenOffice and KDE4 Accessiibilty [was: Orca/KDE Integration]

Hi Bill,

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

Sure ;-). Sorry if I had not been more clear earlier...

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

Dependancies related to the problem, yes.

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

OK.

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

Technical question: how much of GNOME does ATK need? Would that be easy to get 
rid of it?

> 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? ;-)

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

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, 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?

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

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.


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