Hi Gary; I'll try to give some initial thoughts on your points (#1 through #3) below. They seem right on target to me. The only thing that strikes me as possibly a little odd is the continuing use of the term "KDE developers" in the context of AT clients. I would prefer to just say "developers" in this context; in what sense are they "KDE" rather than some other sort of developer, or perhaps new developers without such a strong "brand loyalty" ? In the context of making KDE applications (apps that are part of KDE, or are built with Qt, etc.) accessible, the notion of "KDE developer" makes a lot of sense. But of course assistive technologies can be built without using either gtk+ or Qt, and they may use a mix or libraries and services traditionally considered part of Gnome and/or KDE. Perhaps the question, from the _client_ point of view, is "how can I write AT clients which use Qt", and "how can I write AT clients which use gtk+"? Ideally the interfaces those two kinds of AT clients use to talk to the AT-SPI subsystem will be the same - if not immediately, then certainly eventually. Rather than make a "Gnome screenreader" and a "KDE screenreader", which IMO dilutes our efforts, I would hope that our AT development efforts would try to combine forces where possible. I think that this is already happening and I am very glad to see it. For instance the orca screenreader doesn't currently present any GUI at all, and although it's hosted at cvs.gnome.org, about the only gnome-ish thing about it is the use of the pyOrbit bindings to AT-SPI. So I don't see why it can't talk to, for instance, a Qt-based magnifier service or SpeechDispatcher or KTTSD if that makes sense.... just to give some examples. Okay, enough rambling, I'll make some comments inline... Gary Cramblitt wrote: >Thanks Bill. > >It would be nice if someone fully knowledgeable about the KDE plan could >update the accessibility.kde.org website and explain all this so we >developers can have a better understanding. I'm sure the following exposes >my ignorance, but as they say, there are no stupid questions.. > >I *think* it breaks down to 3 possible scenarios: > >1. How can KDE developers write KDE 3 AT clients today (using ATK bridge)? > > The ATK bridge isn't needed by the AT client; it is used to 'export' accessibility info from ATK-implementing applications to AT-SPI. So an AT client using the KDE 3 libraries would need, at present, to speak the AT-SPI "interface protocol", the simplest way is to link to libspi (which for the time being pulls in ORBit2) or to use other bindings such as the pyOrbit bindings. >2. How can they develop AT clients with KDE4 libraries in conjunction with >Gnome libraries? > > Are you sure you are talking about AT clients here? The existing AT clients should work with KDE4 applications, because the KDE4 apps will export AT-SPI information via (if I understand Harald's work correctly) ATK and the atk-bridge. The clients won't "see" the bridge, but they will need one of the AT-SPI bindings in order to "communicate" with the AT-SPI subsystem. So in KDE4, the big change will be that ATs will be able to work properly (disregarding, for the moment, bugs) with KDE applications. >3. How will KDE devs develop AT clients when the AT-SPI DBUS version is in >place and how do we get there? > > This is an interesting question and a tough one. Ideally we don't want to have to re-write existing ATs or break interoperability, so we want the AT-SPI interfaces as seen by ATs to change as little as possible. At the same time, we want them to be as "generic" as possible, which from a KDE perspective probably means reducing the dependency on Gnome libraries as much as possible. I don't think this is because of an anti-Gnome sentiment, at least I hope not, but rather it reflect the fact that nobody wants to pull in a lot of new dependencies which they are not otherwise using, and I respect this. I agree however that it's not trivial to do. Two approaches that come to mind: 1) IDL compiler generates new client stubs whose API signature, at least in C and Python, matches the existing C and Python CORBA stubs; ATs then only need to re-compile in order to work using the new backend (which would presumably use DBUS as its IPC transport). 2) Keep ORBit2, but change its internals so that an "ORBit2-lite" implementation which doesn't use IIOP is available, and replace the IIOP wire protocol with DBUS. This would eliminate most of the stuff in CORBA which people think is broken IMO, except for the ugly C bindings (which might be unavoidable, C being the non-OO language that it is). If we "fix" the C bindings, then we break compatibility and have to re-write apps, so that's not an attractive idea anyway. The pyOrbit bindings look the same, so apps like orca don't really have to do anything, it "just works". I suspect #2 is the more feasible way to go, but it would mean that the "shell" of ORBit2 would end up living on as part of the accessibility infrastructure. Some people might be unhappy with this, but it seems more practical to me than writing an IDL compiler, unless there are other good reasons for doing so. Perhaps the combined Gnome+KDE forces have enough interest in making DBUS more programmer-friendly that this bigger job will happen anyway. I have heard rumors of IDL compiler work going in in the DBUS space but I don't know any hard facts about it. Best regards Bill >The IDL compiler approach strikes me as the most plausible way forward for #3. >I say this because very few people in the KDE community understand >Bonobo/ORBit2 enough to do the port. Is anyone working on such a compiler? >How difficult would it be to do that and how would one get started if one >were inclined to work on it? > >If anyone wants to write this up (whatever format you like), I'd be happy to >post it on the website. > > > _______________________________________________ kde-accessibility mailing list kde-accessibility@kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility