Re: Accessibility and the recent GNOME announcement

[Bill Haneman <bill haneman sun com>]

JP S-C wrote:
> 
> Dear GNOME-Accessibility,
>      Just read the great news for GNOME on:
> 
> http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00199.html

Hi JP:

>      My question for the list and more specifically for
> the actual hackers at Sun is "With your added manpower
> and fulltime hackers, do you forsee any changes in how
> the community is involved?"  

I wouldn't expect any substantial changes; however just the influx of 
new hackers can be expected to have some effect, and we'll have to 
try and grow a structure that can maintain efficiency.  New coders
can either make maintainers' lives easier or harder; probably the 
latter will happen before the former as a natural consequence.  However
having more hands to tackle bugs is expected to be broadly welcomed...

> A follow  that is less
> GNOME specific is "Do you think you're goals would be
> attainable without all the full-time hackers you have
> and have recently acquired?"  I ask because I'm also
> involved in KDE Accessibility, a project / issue for
> which there is no similar corporate support.

Well, there is TrollTech ;-)

I think that most of the work we've accomplished so far has been
comtributed by only a few people, and conceivably could have come
about via volunteer effort rather than from corporate employers.
Moving forward, I think the main impact of having many hands will 
be to accelerate the process of moving from architecture to system,
but I think that the end result of accessible apps ported to the
accessibility framework would happen even without the extra
hands, albeit more slowly,  

The (relatively) good news is that we tried, as Peter said,
to be as platform-neutral as possible in both architecture 
and implementation.  Given the fact that KDE and GNOME
frequently (usually) coexist and can be expected to do so
for years to come, KDE can reuse ("leverage" to use the jargon ;-)
not only our APIs but implementation code as well.

There will no doubt be grumbling about using CORBA and/or
Bonobo, or glib, if KDE chooses to leverage our work.  But
code does speak, and there is no reason why an alternate
implementation could be provided that used other libraries.
However from a cost-benefit viewpoint I think that KDE's most
effective strategy at this point (or at least most expedient)
would be to reuse as much of the GNOME accessibility stack as
possible.

One approach would be to link KDE apps to glib, and use our
in-process "ATK" API/ABI for accessibility.  From there, KDE could
reuse the rest of the GNOME accessibility stack, no inter-service
protocols or bridges would be required (aside from the Java
Accessibility
Bridge which will be used by GNOME accessibility for Java apps), 
and existing assistive technologies written to use the GNOME APIs would
run without modification using KDE/Qt apps.  Alternately, a simple
bridge from Qt 3's accessibility interfaces (currently only functional
under Windows/MSAA, I believe) could be constructed; this would probably
require extension of the Qt3 accessibility APIs beyond what MSAA
requires.

Alternatively, Qt or KDE could present its own accessibility API,
provided
it was "well matched" to the GNOME APIs, and bridge it to the
accessibility
APIs defined in the GNOME "at-spi" module.  These APIs are defined as 
CORBA IDL but of course since they are IDL they could use other IPC
protocols, provided they were eventually bridged to our existing
CORBA-based accessibility service provider interface (SPI).  So there
are
two layers into which one could connect, one being in-process and
requiring
glib, the other being out-of-process and requiring either CORBA or a
bridging service that can communicate with our CORBA services.

Similarly, if an effective alternative to CORBA for these services
were made available, a set of API-compatible C bindings would be
sufficient to allow reuse of the "GNOME" ATs.

These are the sorts of topics I would like to explore (among others) in
the 
linux accessibility interoperability roundtable at LAC2.

Best regards,

Bill
> Best,
> 
> --JP
>