Re: Orca /KDE Integration

[Gary Cramblitt <garycramblitt comcast net>]

Thanks for your comments Bill.

On Monday 28 August 2006 08:24, Bill Haneman wrote:
> 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.

From the XEvIE 1.1 spec:

"The XevieStart? function requests that the X server enable XEvIE extension. 
Only one client at a time can enable XEvIE extension. Once XEvIE is 
successfully enabled, all the XevieSelectInput? specified events will be sent 
to the client who enable XEvIE. If XKB or AccessX? is enabled, the events 
that are sent to XEvIE clients are XKB/AccessX processed (filtered) ones. The 
XEvIE client takes full responsibility to handle the events. The events can 
be sent back to X server through XevieSendEvent? and can be consumed by the 
XEvIE client. Start from Ver1.1, XEvIE allows multiple clients to enable 
XEvIE extension in Read-only mode. Only one client at a time can obtain the 
write permision by invoking XevieLockWriteChannel?. The client who has write 
permision takes full responsibility to handle the events."

From this, my interpretation is that two cooperating registries could receive 
events.  One would have to be the "master" and the other a "slave" that 
forwards the write requests to the master.  Ideally, both the Gnome and the 
KDE registries could act as either master or slave.

> 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.

That sounds like a possible approach.

> 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.

It is my intention to use the same AT-SPI IDL files as Gnome, so the 
accessibility "protocol" is the same, but the wire protocol is different.

> > 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.

I browsed the code briefly last night.  It appeared to have a lot of CORBA 
stuff to me.   I came away very discouraged.  I will take another look with 
an eye towards the D.E.C strategy you mentioned. :/

> > * 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.

The current D-Bus XML spec falls way short of the needs for AT-SPI.  There are 
no enumerations, no way to embed comments, and no way to type objects 
beyond "o" = object reference.  I understand they are working on some of 
these things for the next iteration of D-Bus.

The only way I can see the XML being useful right now is in addition to the 
AT-SPI IDL files.  If one assumes that the XML is in sync with the IDL files, 
then the XML could be useful for generating the wire protocol part of the 
code.  One approach that has occurred to me is to use the dbus-binding-tool 
to generate .c code from the XML, then wrap that code in a Python extension 
module using SIP.  But this approach doesn't really gain a whole lot other 
than producing a bunch of .c files that can be re-used in other projects,  
but easily generated as needed anyway.  It does eliminate the need for using 
the dbus-python bindings in Orca, so its an approach I am still considering, 
given that dbus-python has some limitations.  OTOH, writing (and maintaining) 
all that .sip code is not something I want to do.

> 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" ?).

Its my intention for the Orca bonobo/ORBit and  D-Bus code to be loadable 
modules.  Both the bonobo/ORBit module and the D-Bus module could be loaded 
simultaneously, or singly at user's option.  If a KDE user wants Firefox, 
OpenOffice.org or Gnome/GTK+ apps to work with Orca, then they would load 
both modules.  A Gnome user who doesn't care about KDE apps would load only 
the bonobo/ORBit module.  So I don't see any need to talk about a "fork" of 
Orca.

Even if I can't get both modules to work simultaneously (either/or), at least 
KDE will gain a screen reader and KDE developers can work on making their 
applications more accessible.

I fully admit this is not a "full up" solution that unifies the two desktops.  
Assuming I can get my project to a working state, I would expect it to be 
replaced later with the "full up" solution, whenever and whatever that might 
be.

If nothing else, my efforts will identify the issues that need to be 
addressed.  What will the performance via D-Bus be like, for instance?  How 
to solve the problem of object lifetime?   Something that is becoming very 
apparent to me right now is that the Registry is going to be a serious 
obstacle to unifying the two desktops -- something I was not aware of prior 
to beginning this project.

-- 
Gary Cramblitt (aka PhantomsDad)