Hi Gary, All: I'll snip a bit, hope you can recall the context... On Wed, 2006-02-22 at 17:25, Gary Cramblitt wrote:... > Sorry, I'm a little confused. In phase A, what happens to the existing KDE AT > applications (KMag, KTTS, etc)? How do they make use of the QAccessible > framework? I was under the impression that as a minimum we'd need the Qt/ATK > bridge (non DBUS) that Harald Fernengel implemented last year. See Bill's > response in this thread. Or are you suggesting that in phase A, KDE AT apps > not interface with ATK/AT-SPI? ... > > > > b) Enabling our assistive technologies to make use of AT-SPI is more an > > open problem. AT-SPI is currently based on CORBA. As a long-term goal it > > is planned to move AT-SPI to DBUS, but this requires to write an IDL > > compiler for DBUS first. > > I'd like to look at this from the standpoint of a KDE developer wishing to > write AT applications for KDE4, or incorporate AT into KDE applications. > Will KDE4 permit me to do that and what does the interface look like? What > libraries, compilers, etc. will I need and what dependencies will my > application have? Given the level of effort to implement phase B, and the > need to coordinate with Gnome AT developers, it seems likely that phase B > won't be completed in time for the first release of KDE4. What, if any > options will I have then? I think it depends on the type of "AT application" you wish to write. When people say "assistive technology", they can mean different things. For the purposes of the discussion, we can distinguish between four categories of "assistive technologies": 1) platform accessibility features, such as the "AccessX" features build into the XKB X server extension, including SlowKeys, StickyKeys, and MouseKeys. These are unlikely to need to interface with QAccessible or AT-SPI, as they are behaviors of the platform itself. 2) accessibility-related services, which are used by other applications directly or by other assistive technologies (in categories 3 and 4 below); for instance KTTSD, gnome-mag, and brltty would be examples of services which provide important support for assistive technology. Choice of APIs is vital to interoperability, but the existing "AT-SPI" interfaces don't include these services, they are intentionally covered by separate service APIs. As relatively modular services, they also lend themselves reasonably well to bridging as a means of ensuring interoperability; see for instance the Speech Dispatcher back-end for gnome-speech, and discussion of supporting Speech Dispatcher in KTTSD. 3) small "utility" programs that provide helper applications or assistance in using some subset of the desktop environment; examples might include the existing simple version of KMag, KMouth, KMousetool, or a self-contained application for reading e-books. While support for QAccessible-type information via AT-SPI could enhance some of these applications, they can do useful, though somewhat limited, work without AT-SPI. 4) "full blown" assistive technologies, i.e. agents that interpose themselves between the end user and one or more major input/output modalities across the desktop environment. These are the ATs that are the end user's primary, or entire, means of interacting with the desktop environment, and in that sense they are like full-spectrum "UI Adapters". Examples include screen readers, which replace the visual user interface with spoken or brailled output; more advanced types of full screen magnifiers, which do sophisticated focus tracking and high levels of magnification; and adaptive onscreen keyboard such as GOK, which replace the entire input method for the desktop. These are the ATs that require the full power of AT-SPI, and they are also the most complex and difficult to write. They are also arguably the most important, in the sense that they bridge a bigger divide between the end user and the 'traditional' GUI. > Let's say for example that I want to implement a speech-to-text capability for > KDE. I might base it on Sphinx. My goal is to implement the STT capability > in such a way that it works with all KDE applications. If it also works with > Gnome applications, that's a bonus. So the AT-SPI seems like the best way to > implement it. Speech-to-text seems to me like a good example of an assistive technology "service", as in category 2 above. We don't have a speech-to-text or advanced-speech-recognition (ASR) API defined for the free desktop yet, but it makes sense that we should. So this example is sort of a green-field one. For existing service APIs other than AT-SPI, I think porting/migrating to a DBUS-based service merits consideration, and I think that it could be done in a coordinated way with the existing service users (e.g. mostly the "Gnome" ATs) without sacrificing interoperability. Certainly for newly defined service APIs that don't already have a proven implementation, DBUS seems like a logical choice. > How would I go about implementing my STT capability if only > Phase A is in place? If I understand what you and Bill Haneman are saying, > with only Phase A in place, I'd have to install Harald's Qt/ATK bridge, > install and compile my program against the ATK, and also install AT-SPI, > together with all the Orbit/Gnome dependencies these components bring in. Of course, the catch in the 'service' model above is that the end-user gets no benefit unless some application is using that service. For the speech recognition to be usable in anything more than a simple plug-in, some client of that service would need access to AT-SPI in order to interface between the ASR service and the application. (There are a couple of 'service' APIs that _are_ included in AT-SPI currently, which might be of interest to such a project - particularly, the upcoming "Selector" interface. We plan for GOK to expose that interface, which means that an ASR client could use GOK's knowledge of running applications in order to interpret spoken commands.) > My > users will of course also have to install these components. Will I be able > to commit my code to the KDE repository, or will I be banished to > extragear/playground because of the dependencies. If this is the case, I > have little incentive to write my application for KDE. I might as well go > join the Gnome developer's team where I can get better mainstream exposure > for my application. In practice I don't see such a division between teams. If someone on the KDE team writes an AT-SPI client that uses KDE libraries, I have little doubt that it would be welcomed by both desktop teams. Perhaps the only practical hitch would be that the project might need to be hosted on SourceForge instead of the KDE repository. As the dependency issues get resolved to everyone's satisfaction, projects can migrate from SourceForge (if there's a strong reason to do so). > I'm not asking all these questions in order to complain or throw cold water on > the plan. Partly, its for my own clarification, but mostly I'm asking all > these questions because I want the TWG and board to understand the issues and > the ramifications. > > I think it comes down to this (but I might be wrong). Phase A permits KDE > applications to work with Gnome AT applications. For instance, if I install > all the dependencies, I'll be able to use the Orca screen reader with KDE > applications. However, if I want to write a KDE AT application, it will be > heavily dependent upon Orbit/Gnome components. What will be the TWG's policy > or strategy for handling such applications? Will they be banished to > extragear/playground? Will the TWG recommend waiting for Phase B? As someone who is not a KDE developer per se, I have little to add here. But I do have doubts about the desirability of writing more ATs in 'category 4', as opposed to improving/assisting those that we already have. Orca, for instance, doesn't have much Gnome-like about it; being in python, the AT-SPI bindings just look like python objects. IMO it would be better for KDE accessibility to help the Orca team develop better custom scripts for interacting with KDE applications (i.e. using Phase A), so that blind users can use the KDE desktop. I agree that resourcing is not large; it's not big for the "gnome" ATs either, so sharing ATs as well as APIs seems like the best approach. Bill > Thanks for listening. > > -- > Gary Cramblitt (aka PhantomsDad) > KDE Text-to-Speech Maintainer > http://accessibility.kde.org/developer/kttsd/index.php > _______________________________________________ > kde-accessibility mailing list > kde-accessibility@kde.org > https://mail.kde.org/mailman/listinfo/kde-accessibility _______________________________________________ kde-accessibility mailing list kde-accessibility@kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility