Re: Orca [Kde-accessibility] /KDE Integration

[Bill Haneman <Bill Haneman Sun COM>]

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.
>
> 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.
>  
Yes, but I don't think that the proposals I have made in the past would 
have saddled KDE4 with any API problems, unless you feel that glib would 
have been totally out of the question. 

Using the existing CORBA transport, and existing atk-bridge libraries, 
would not impact KDE's API, except potentially KDE-based assistive 
technologies which might need to be at-spi clients.  I feel there were 
some alternatives there as well (as Gary's work with python bindings is 
showing).

> 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.
>  
That's why ATK makes more sense, from the point of view of application 
developers (i.e. user agents/productivity apps, I don't mean AT developers).

> 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.
Actually I think that would be a perfectly reasonable thing to tell KDE 
developers (as long as they don't incur any 'hard' dependencies on 
CORBA/Bonobo). 

Just making Qt/KDE apps "work" in any AT-enabled environment will be 
challenging, I can speak from experience.  IMO building a new and 
untested infrastructure to go with it only makes it harder and slower.

> Both the desktop and all applications will need to read 
> gconf keys and GNOME specific environment variables. 
I don't agree with this.  There is only one gconf key of interest, and 
it can easily be made an XSetting (which is the preferred cross-desktop 
mechanism) instead.  All the relevant Gnome env variables are in the 
process of being made into xsettings already.  If KDE were to use/need 
them then it would help to prioritize this work, which we (gnome etc.) 
already believe ought to happen eventually.

The activation issue is similarly something that is going away, as 
AT-SPI will use an Xatom in gnome 2.17 and later. 

> There might be more, 
> since we do not have a complete dependencies list of the current AT-SPI code 
> available. 
Why not?  I don't think this is so hard to produce.

> 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."
>  
I don't know what you're quoting from there.

But there is no motivation or reason to remove any dependencies from the 
existing code unless we have agreement on sharing it.  From that point I 
believe we can usefully trim them a great deal.

Bill

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