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 _______________________________________________ kde-accessibility mailing list kde-accessibility@kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility