From kde-accessibility Fri Aug 04 17:13:29 2006 From: Bill Haneman Date: Fri, 04 Aug 2006 17:13:29 +0000 To: kde-accessibility Subject: Re: [Kde-accessibility] [g-a-devel] AT-SPI questions Message-Id: <1154711608.7039.49.camel () dhcp-226-192 ! ireland ! sun ! com> X-MARC-Message: https://marc.info/?l=kde-accessibility&m=115485327119619 Hi Everyone: I'll try to reply in some detail to Olaf's questions when I return from my holidays. Thanks Olaf for taking the time to enumerate them. For the moment, I'll just mention, regarding the issue of LSB, that as I understand the proposals regarding AT-SPI and the existing implementation, there should be no corresponding "cementation" long-term. Also, I don't think the current FSG proposal would enshrine any libbonobo dependencies. The libbonobo dependency of the current at-spi implementation library is only an implementation detail; in fact I do not believe that it would be appropriate to pull libspi.so into the ABI suite at all. So: first, the "many worlds" approach provides a path for eventual solutions which use non-CORBA transport. Personally I think an IDL compiler or at least a similar degree of 'automation' with regard to how the IDL is mapped to ABI would be a reasonable requirement for an alternative to be blessed. Secondly, I don't think that library dependencies should come into the LSB equation. I think that even for the current at-spi "world", only the client bindings and skeletons (defined by applying the OMG specification to the IDL) should be part of a conformance test. I certainly agree with you that making libbonobo part of the LSB conformance test doesn't seem like a good idea, rest assured that I have no desire to see that happen. More later, best regards, Bill On Fri, 2006-08-04 at 18:11, Olaf Jan Schmidt wrote: > 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? > > 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 _______________________________________________ kde-accessibility mailing list kde-accessibility@kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility