[Kde-accessibility] Timeframe for KDE 4

[Willie Walker]

Hi All:

As the lead for the Orca screen reader project, I've been following  
this thread with some interest.  In my opinion, whatever work is done  
probably should include consulting with the AT developers, as they  
are the ones who will most likely get the benefit (or pain) from the  
solution that is developed.

My interest is in getting a screen reader developed to provide access  
to the desktop, and I'm relying on the AT-SPI to do this. My  
*preference* here would be to have KDE accessibility provide  
interaction with the AT-SPI much like GTK+, Firefox, OpenOffice,  
etc.  That is, Orca can discover apps via the AT-SPI Registry and  
interact with AT-SPI Accessible's via the PyOrbit interfaces like  
Orca is doing now.

That is, Orca currently uses the PyOrbit Python module to discover  
and interact with the AT-SPI registry as well as gnome-speech.  All  
interaction is done via pure IDL with no C-SPI or other hand crafted  
layer in between: PyOrbit takes care of all of that for Orca.  The  
direct interaction with IDL greatly simplifies the problem by getting  
Orca "closer to the metal" and eliminates another abstract layer that  
might contain bugs in its own right.  This underlying simplifying  
assumption has helped me focus more on the screen reading problem  
rather than needing to write/debug/maintain yet another AT-SPI (e.g.,  
CSPI<->Python) or gnome-speech abstraction layer.  If things could  
remain as simple as discovery and interaction with IDL-based objects,  
my life would be easier.

Will

>> 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
>
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility