Re: Orca [Kde-accessibility] /KDE Integration

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.


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]