Hi Olaf: > I am getting the impression that the GNOME accessibility developers do not > care about making it easier to implement interoperability with Qt and KDE, > and would instead like push a libbonobo-based AT-SPI version into the LSB and > make people believe that all full-featured assistive technologies are GNOME > tools anyway.
As the lead for the Orca project, I can tell you that my primary agenda is making the desktop and its apps a productive and compelling environment for users. The AT-SPI happens to be the solution we are using because it helps us meet this agenda. The client/server model to accessibility is something I've been working on since the early 90's when I worked on RAP (the Remote Access Protocol for the X Window System), which I also helped carry forward into the Java Accessibility API when I joined Sun in early '97. No solution is perfect, and we learn as we go. IMO, the AT-SPI model works and we should continue to work with it and with each other to improve it. Incompatible and competing infrastructure solutions for the same platform seem more detrimental than helpful to me. If there were any disruption to happen in this space, I think I'd rather see the entire industry rally behind a common model that works across all platforms and operating systems. Who knows, maybe a web-services approach with well-defined interfaces might be neutral ground. But...that's future work. More specific to the discussion at hand... ;-) Under the covers, Orca's main view of the world is via the IDL interfaces for AT-SPI, gnome-speech, and gnome-mag. We view these IDL interface definitions as primary specifications for the assistive technology's side of the world. A big benefit of using IDL is programming language independence: you write your server in whatever programming language you want, I write my client in whatever programming language I want, and we both communicate using the IDL as our normative language. In addition, environments such as Python have features (e.g., PyBonobo and PyORBit) that will dynamically provide Python bindings directly from IDL, thus eliminating the need for anyone to hand craft client-side bindings. The communication with IDL-based services is done via the Python support for bonobo/ORBit/CORBA. As such, there are some bonobo/ORBit/CORBA dependencies in Orca's source code, but we've pretty much limited these specific bonobo/ORBit/CORBA references to the small set of modules needed to manage the setup and tear down of the communication. The remainder of the code in Orca that talks to the outside world is primarily concerned with the IDL. As such, my hope and recommendation is that any non-bonobo/ORBit/CORBA solution taken on by KDE would continue to support the IDL model. >From other e-mail, I see that Gary Cramblitt is looking at what it would mean to add support in Orca to allow it to talk with both the CORBA-based IDL solution and the KDE DBUS-based IDL solution for AT-SPI. I'm not sure we've heard from Gary directly, but we're happy to discuss ideas with him! Will _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
