[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-accessibility
Subject:    Re: [Kde-accessibility] [Accessibility]  Orca/KDE Integration
From:       Bill Haneman <Bill.Haneman () Sun ! COM>
Date:       2006-08-30 18:28:05
Message-ID: 44F5D8B5.1050109 () sun ! com
[Download RAW message or body]

Olaf Jan Schmidt wrote:

>[ Bill Haneman ]
>  
>
>>Like you, I worry about the performance. It seems to me like a lot of
>>work just to avoid using ORBit2 in the short term...
>>    
>>
>
>Short term?
>
>Sorry to disappoint you, but KDE 4 will still take some time. We can only make 
>medium to long term plans at the moment.
>  
>
I am not sure we agree on what "short term" means.

Moving at-spi to a different back-end will also take time, possibly 
quite a bit of it, and it's not something that should be rushed.

The way I see it, the options for KDE boil down to a few basic 
approaches.  I will assume first of all that gconf  or 
activation-related issues are solvable short-term (and I am confident 
that they are, with a bit of will), and I'll similarly assume that any 
spurious dependencies can be purged from the existing implementations.  
So the possibilities look like this:

1) Bridge from QAccessible to ATK and use ATK as the in-process KDE 
accessibility API.  Then KDE apps can reuse all the "gnome" code and 
will seamlessly interoperate with our existing AT-SPI clients (GOK, 
dasher, gnopernicus, orca).   KDE apps will be accessible when run in 
the Gnome environment, and vice-versa, and OpenOffice and the mozilla 
suite (as well as some commercial software such as Adobe Acrobat reader) 
will will be accessible when run in the KDE desktop.

Pros:   Everything works short-term, no new IPC code required in KDE 
codebase short-term,
             maximum code reuse.       
            Proven infrastructure.  Shortest lead time.
            AT-SPI dependencies are invisible to KDE code and gnome libs 
are only loaded if available
            and required for accessibility.
Cons:  KDE takes on a glib dependency which may be unpopular.  KDE 
Accessibility doesn't work without 
             the Gnome libraries.  KDE Assistive technologies must link 
to a CORBA ORB (albeit possibly
             via cspi or python bindings which may hide this effectively 
and permit a simple swap-out of the 
             backend later).

2) Extend QAccessible to provide all the features required for AT-SPI's 
methods (see IDL), and use the           
QAccessiblePlus as the KDE in-process accessibility API.  Write 
QAccessible-to-AT-SPI (or QAccessible-to-ATK) wrappers, and load the 
existing atspi libraries at runtime until such time as a dbus at-spi 
backend is mature and shared by both desktops. 

Pros:  No glib dependency, KDE and Qt application APIs remain "KDE 
native". 
            Everything interoperates immediately, as in #1.  Fairly 
short lead time,
            proven infrastructure.  KDE code sees no gnome API 
dependencies (except
            possibly the bridging code above).
Cons: QAccessible must be extended and bridged - more new code than #1. 
           Short-to-medium term, KDE accessibility requires gnome libs 
at runtime.  KDE assistive technology 
           situation same as in #1 above.
           Some "disposable" code required which will be replaced when 
AT-SPI shared dbus backend
           becomes available, longer term.

3) Create a new dbus ABI based on the existing AT-SPI IDL.  Write to 
this inside KDE, instead of AT-SPI.

Pros: No gnome libs in KDE, even short-term.  Forward-looking.  KDE 
doesn't have to wait for consensus 
          before writing code.  Works for embedded environment fairly soon.
          KDE assistive technologies don't need to use gnome libs even 
short-term.
Cons: KDE apps not accessible when run under Gnome, and vice-versa.  
OpenOffice and mozilla suite not 
           accessible under KDE.  KDE assistive technologies don't work 
with OpenOffice and mozilla.
          
4) Wait for a new dbus ABI for AT-SPI to be adopted by consensus.  Write 
to this as above.

Pros:  Ideal code sharing and interoperability.  No "foreign" libs 
required, only freedesktop.org libs.
Cons:  Possibly a very long lead time, with an untested infrastructure.  
There could be delays in adoption by            OpenOffice and mozilla.  
Performance problems and extensions of to dbus likely. 
           May requires rewriting of some existing ATs.  Maximum amount 
of new code required.

I am a little concerned about #3 becoming the de facto path if #1 or #2 
are unacceptable.  Since no one really wants to delay KDE accessibility, 
it's very tempting to press ahead with a new ABI.  It's my sincere hope 
that such a new ABI effort be closely coordinated across the different 
desktops (even if KDE deploys it first), in order to preserve 
interoperability.  I also think that if #3 goes ahead without a 
consensus outside of the KDE developer community, the momentum and 
motivation for #4 will be undermined.

On the other hand if #1 or #2 are something KDE developers wish to 
re-examine, I for one would be willing to put more time into addressing 
some of the downsides (activation issues, spurious dependencies, etc.) 
in the current at-spi libraries.

best regards,

Bill


>KDE development is currently in an extensive API review phase, where all code 
>in the libraries is evaluated for possible changes. Once this review is 
>complete, we will have to stick with the API for a really long time.
>
>Our short term goal is to educate the other KDE developers about what is 
>needed in the applications and libraries to properly support AT-SPI. We can 
>do this best if we can sell them a nice API that is expected to be around 
>long term.
>
>I agree with you that using atk plus the existing AT-SPI implementation (with 
>gconf, bonobo etc) would have been a nice short term strategy to integrate 
>KDE applications into the GNOME desktop accessibility-wise, but Qt3+KDE3 have 
>too many limitations to do this and KDE4 is just not ready yet.
>
>If we attempt to apply this short term strategy to our medium term plan of 
>making the KDE4 desktop itself accessible, then it quickly becomes obvious 
>that we need a different plan for this.
>
>Neither you nor me would like to tell the KDE developers: "To make KDE4 
>accessible, the desktop will need to use CORBA+Bonobo. We will also have to 
>restrict key parts of KDE Accessibility to those platforms where a suitable 
>C++ ORB is available, at least until we have a consensus between all players 
>to migrate to D-Bus. Both the desktop and all applications will need to read 
>gconf keys and GNOME specific environment variables. There might be more, 
>since we do not have a complete dependencies list of the current AT-SPI code 
>available. A D-Bus migration might be a possible alternative, but the GNOME 
>team discourages work on this (at least short term), citing interoperability 
>concerns and likely performance problems. We also discussed removing some of 
>the other dependencies, but it would not benefit the user to destabilise 
>AT-SPI at the current point of time."
>
>My hope is that we can decide on the long term plan for AT-SPI soon, so that 
>we are able to define the KDE4 APIs accordingly. It shouldn't be too 
>difficult to agree on a version of AT-SPI that fits the needs of both KDE and 
>GNOME if we make this a joint effort.
>
>Olaf
>
>  
>

_______________________________________________
kde-accessibility mailing list
kde-accessibility@kde.org
https://mail.kde.org/mailman/listinfo/kde-accessibility
[prev in list] [next in list] [prev in thread] [next in thread]