Re: [g-a-devel] AT-SPI questions

[Li Yuan <Li Yuan Sun COM>]

在 2006-08-04五的 19:11 +0200，Olaf Jan Schmidt写道：
> Hi!
> 
> I am probably still misunderstanding some things, so I am summarising what I 
> have understood so far of the whole AT-SPI picture. This email functions both 
> as an attempt to find possible misunderstandings, and as an explanation why 
> it is important for KDE to move AT-SPI onto D-Bus. Please correct all wrong 
> assumptions, and keep in mind that I have no power to tell Trolltech what to 
> do with AT-SPI.
> 
> Imaging a new, much improved version of kmousetool talking to KOffice on a KDE 
> desktop on FreeBSD or IBM AIX.
> 
> The GNOME accessibility team suggests to implement AT-SPI support in Qt by 
> linking to ATK. This requires significant changes in glib and/or ORBit2, and 
> significant effort for the Qt-ATK bridge. It would also only deal with the 
> application side. Doing a move to D-Bus later would be the same amount of 
> work as doing it now, meaning that going for D-Bus directly takes 
> significantly fewer resources altogether.
> 
> GNOME applications read a gconf key to check whether AT-SPI is enabled. Do 
> they also watch changes of the gconf keys during runtime in case the setting 
> gets changed? And what do non-GNOME applications do instead?

There are two ways to load an application's a11y lib. First is set
GNOME_ACCESSIBILITY macro in your env. If set it to 1, application's
will load a11y libs, if set it to 0, application's a11y will not load
them. If the GNOME_ACCESSIBILITY is not set, applications will read the
key("/desktop/gnome/interface/accessibility") to check whether they
should load their a11y libs. This work is done in gnome_program_init
which applications will call at the beginning of their lifetime. So I
don't think a11y libs can be loaded dynamically after the startup of
applications. For non-GNOME applications like firefox, they also look at
the macro in env and the key in gconf, but this depends on application
itself.

-Li


> 
> The assistive technologies use Bonobo-activation to start the AT-SPI registry. 
> Does this mean either linking to libbonobo or reimplementing it with a 
> different ORB?
> 
> There is no complete C++ ORB that runs on all platform KDE targets, which 
> means we have five options:
> 1. Abandon all plans that we have for assistive technologies.
> 2. Put a lot of work into a solution that works on only some of our target 
> platforms.
> 3. Make KDE applications support both Bonobo-AT-SPI and D-Bus-AT-SPI. This 
> would mean doing twice the work for only half a solution, because GNOME 
> applications would still fail to work with KDE-based assistive technologies.
> 4. Write an incompatible version of AT-SPI.
> 5. Convince GNOME to join us in our move to D-Bus, which means work on the 
> framework now, but significantly fewer work for the authors of KDE-based ATs 
> later.
> 
> The GNOME accessibility team suggests to make the CORBA- and Bonobo-based 
> version of AT-SPI a part of the LSB standard, which also means standardising 
> all dependencies of the AT-SPI registry. Which exactly are these?
> 
> The LSB requires interfaces to be around for at least 6 years, which means 
> that a D-Bus-based version of AT-SPI would be non-standard until at least 
> 2013.
> 
> ORBit2 is described by Michael Meeks as not sufficiently documented, virtually 
> unmaintained and only a "subset" of the OMG specification. Which role does 
> Michael Meeks have among the ORBit2 developers?
> 
> I once suggested to reduce the number of dependencies the AT-SPI registry has, 
> and Bill Haneman answered that this doesn't make sense since our long-term 
> goal is D-Bus anyway. Or did I misunderstand him?
> 
> Bill also say that a D-Bus-based variant of AT-SPI is not a real AT-SPI. How 
> does this fit to the agreed "many worlds" approach? Or did he only mean that 
> we should use an IDL compiler for themove to D-Bus?
> 
> I know that the GNOME team has spent a lot of time for discussing 
> interoperability with KDE, and I truly thankful for that. I also appreciate 
> the offer for constructive discussion of the obstacles towards AT-SPI use in 
> Qt and KDE.
> 
> And please don't see our push for a D-Bus-based as an attempt to create 
> incompatibilities. Quite the contrary - it is a compliment that we plan to 
> make the excellent work of the GNOME accessibility team useful for us.
> 
> Summary: My fear is that implementing the AT-SPI support in Qt via ATK 
> initially will make it impossible to prevent LSB cementation of 
> Bonobo-AT-SPI, which would totally evaporate the goodwill towards AT-SPI that 
> we have build within the KDE community. Making the decision to go directly 
> for D-Bus is certainly not popular with everyone, but it might be the wisest 
> course in a long-term perspective.
> 
> 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/
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel