From kde-accessibility Mon Aug 28 12:24:11 2006 From: Bill Haneman Date: Mon, 28 Aug 2006 12:24:11 +0000 To: kde-accessibility Subject: Re: [Kde-accessibility] Orca/KDE Integration Message-Id: <1156767836.12061.16.camel () linux ! site> X-MARC-Message: https://marc.info/?l=kde-accessibility&m=115676781324726 On Sat, 2006-08-26 at 12:02, Olaf Jan Schmidt wrote: > Hi Gary! > > Thanks a lot for your work on this. > > I fully agree that the D-Bus version of AT-SPI should use the IDL. We want to > make the migration as easy as possible. > > Some additional thoughts: > * It is impossible to run two registries in parallel because of the way XEvie > is written. To be more specific, XEvie only allows one client per Xserver DISPLAY, currently. This means that two registries in parallel would not both be able to communicate with XEvie. The current Registry: interface doesn't directly use Xevie though - the interface whose implementation requires XEvie is called DeviceEventController. DeviceEventController is responsible for device event notification and synthesis. One possibility would be to have two Registry instances, but only one DeviceEventController. Because clients of "both flavors" of Registry would need access to DeviceEventController, you would still need somehow to either proxy the singleton D.E.C. or have the D.E.C. speak both protocols. But really, more than this would be needed to solve the problem of interoperability. If there are two Registries (and two AT-SPI protocols, which is implied by all this), then in order for AT written to either wire protocol to work with the whole desktop, the two protocols/registries would have to proxy one another. > Maybe it makes more sense to have a registry that can speak both > CORBA and D-Bus (via modules). Does the current CORBA AT-SPI registry code > support a move to D-Bus? I am not sure what you mean by "does the code support a move to DBus". I think there are a number of significant obstacles to such a move but if they can be removed, I think the codebase could be changed fairly easily. There is not a whole lot of CORBA-specific code in the at-spi/registryd/*.c codebase. > * There is a compiler that generates various D-Bus bindings from an XML > description. If it is possible to express the whole IDL in D-Bus > Introspection XML, then we would get bindings for all languages and toolkits > supported by D-Bus. Otherwise it might perhaps be possible to reuse code. I think we should be really careful to avoid using XML in our standard RPC protocol here, for performance reasons. But for instrospection along (i.e. interface query and obtaining interface handles) I guess it would be fine. I am not sure what exactly you are proposing above. Perhaps it would make more sense to use the D-Bus binding generator you mention as a codebase for extension to IDL, i.e. use it to build an IDL compiler rather than go from IDL to XML and then D-Bus. It may be that DBus Introspection XML is not a good fit, but that some other extension to DBUS, or some other API built on top of DBus, is. One thing that worries me a little is talk of Orca "integration" if in fact the modified Orca won't work with Firefox, OpenOffice.org, and Gnome/GTK+. That would seem more like a fork than a port ("FOrca" ?). Bill > 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/ > _______________________________________________ > kde-accessibility mailing list > kde-accessibility@kde.org > https://mail.kde.org/mailman/listinfo/kde-accessibility _______________________________________________ kde-accessibility mailing list kde-accessibility@kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility