[Kde-accessibility] Timeframe for KDE 4

[Bill Haneman]

On Tue, 2006-02-21 at 12:06, Olaf Jan Schmidt wrote:
> [ Bill Haneman ]
> > I agree with you, as I'm sure you saw from my recent post (I hadn't read
> > your reply yet).  Switching to DBUS makes sense, but I believe that we
> > will get better traction short-term by proceeding with the Qt/KDE to ATK
> > approach which Harald had already partially implemented last year.

Hi Olaf;

> I am not sure whether I understand you correctly. Do you recommend against 
> adding AT-SPI support to KDE based assistive technologies, at least short- to 
> medium-term?

No, surely it would be good to add AT-SPI support sooner rather than
later.  But I am not sure how this would be possible without either
introducing a CORBA dependency on the KDE ATs, or building some kind of
bridge to an as-yet-undefined non-CORBA API.

I would however recommend against implementing a DBUS variant of AT-SPI
without making it part of a cooperative migration effort.  Creating a
new KDE-only accessibility API "just because it's not CORBA" doesn't
seem like an effective use of resources, or a good way to achieve
interoperability.

However I do see some ways that the KDE Accessibility apps can be made
interoperable with the "GAP" (aka 'Gnome Accessibility Project', but
really should be called 'Free Desktop Accessibility Project' or perhaps
'GNU Accessibility Project).  There are two main things to consider:

1) The existing KDE ATs are mostly less complex than a full-featured
screenreader or onscreen keyboard; in a way they are more like AT
utility programs, instead of entire supplemental interfaces/user agents
for the desktop experience.  As such, it may be reasonable to
encapsulate the small number of AT-SPI interfaces which KDE ATs need in
a dlopen()-able library which is a consumer of the existing AT-SPI
interfaces, and which could be conveniently replaced later.  In this
way, things like KMag could take advantage of a few AT-SPI calls to do
better focus tracking, for instance, for keyboard navigation, and some
KDE speech tools could use the AT-SPI text APIs to help them read
onscreen content.

2) The most logical way to integrate most of the existing KDE AT
utilities is as services.  The GAP architecture includes APIs such as
"gnome-speech", "gnome-mag, and "gnome-braille", for advertising and
interacting with such services; however these APIs are not actually
included in AT-SPI.  I think that moving these service APIs away from
CORBA and on to DBUS is something that could and should be done sooner,
before we have an IDL compiler.  I would happily accept a patch for
gnome-mag which converted it to use DBUS, and I expect the Gnome AT
providers like gnopernicus and orca would be very receptive to such a
change as well.  Similarly I think we can move the speech API away from
its current CORBA dependency.  The gnome-braille API already has
eliminated any CORBA dependency, and thus could be used by KDE as well
as Gnome without serious dependency problems[1].

Best regards,

Bill

[1] gnome-braille does use glib/gobject, but this dependency is not
something we can easily do without because of its need for sophisticated
UTF-8 transformations and conversions, beyond what is available in ansi
C or even most other unicode class libraries.


> 
> Olaf
> 
> -- 
> Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
> accessibility networker, Protestant theology student and webmaster of 
> http://accessibility.kde.org/ and http://www.amen-online.de/
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility