[Kde-accessibility] Orca/KDE Integration

[Bill Haneman]

Gary Cramblitt wrote:

>Thanks for your comments Bill.
>  
>
Sure.

>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.
>  
>
Cool. That sounds reasonable.

>>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.
>  
>
I see from reading your wiki/website for the orca/dbus work that you 
intend to provide an orca that can talk to either backend data source, 
transparently. That seems as though it would address my concern below.

>>>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. :/
>  
>
Well the CORBA stuff should all be in the impl stubs. It should be 
easily factored out so that two sets of wrappers were around.

| * 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.
>
Sounds like redundancy/duplication which would just be one more thing to 
keep in sync manually. Not really an attractive idea.

>  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.
>  
>
Understood. Automation is good, runtime binding is even better.

>>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.
>  
>
Understood - and this was clear when I read your online docs about the 
work so far. Thanks for the pointer and thanks for explaining your plans 
so clearly!

>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.
>
>  
>
I hope to keep chatting with you about that. So far it's not apparent to 
me that this need be so, perhaps there are some things I can do to make 
registry unification more practical.

Like you, I worry about the performance. It seems to me like a lot of 
work just to avoid using ORBit2 in the short term...

Best regards,

Bill