[Kde-accessibility] Orca/KDE Integration

[Bill Haneman]

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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility