Re: Proposed implementation agnostic GNOME Speech API



Olaf said:

[Bill Haneman, Di 16.12. 2003 13:07:13]
I already addresses the cross-desktop interoperability issue.  Also,
remember that in the accessibility cases at least, KDE will be
working with (and indirectly depending on) CORBA also, via its
at-spi support layers.

This description is quite misleading, unfortunately. No KDE accessibility=20
tool currently uses CORBA, and noone in the KDE project currently plans=20
to use CORBA.
Sorry if you feel this was misleading; I however stand by my comments. I don't see any plans for KDE-based screen readers, focus-tracking/intelligent magnifiers which rely on application-accessibility data, or other KDE-specific assistive
technologies which use the information provided by ATK.

I think this is a _good_ thing, since writing such assistive technologies is a very large effort which would be damaged by excessive fragmentation, at least at the current time. The nominally 'GNOME' assistive technologies were designed _not_ to be GNOME-specific, as is evident by their interoperation with Mozilla and OpenOffice.

As you saw in the Harald Fernengel's recent email, KDE/Qt has already been
bridged (at least in proof-of-concept stage) to ATK and AT-SPI. In order to use at-poke
as shown in the screenshots he sent, the ATK-to-AT-SPI bridge is loaded
dynamically as you mention below; Thus interoperability with the existing API-based FOSS ATs requires AT-SPI communication via a 'bridge' layer. No matter what you do, ATs of this type will require rather powerful IPC service-based APIs, and CORBA has strong
advantages in this respect for cross-platform and network transparency.

The Qt Accessibility Framework can be briged by Qt to ATK on Unix, MSAA on=
=20
Windows and Apple's accessibility framework on MacOS. This way, KDE=20
applications will be fully accessible via whatever native accessibility=20
API is used on the host system.

Note that MSAA appears to be going away; it probably won't be available on
MS platforms going forward (i.e. Longhorn). But I agree that creating platform-appropriate
bridges makes a lot of sense.

If we decided to use the CORBA-based AT-SPI directly for KDE=20
Accessibility, then we would loose interoperability on the native MacOS=20
port of KDE.

Please note that the Qt-ATK bridge is a server side bridge only. AT=20
clients based on KDE would still have to speak CORBA to connect to=20
AT-SPI. This is the reason why I doubt that any KDE-based AT-SPI clients=20
will be written. But since doublicating the effort of writing Gnopernicus=20
or Gok or dasher is not my aim, this is OK for me. There are, however,=20
some KDE developers for whom having native AT clients is important, and I=20
have not yet managed to convince them to write a client side bridge from=20
AT-SPI to a new KDE assistive technology API.

=46or text-to-speech services, using CORBA as IPC is not possible at all fo=
r=20
KDE. I plan to add text-to-speech functionailty to the messaging=20
framework in kdelibs, which means only DCOP or maybe later D-BUS can be=20
used. Requesting CORBA usage for any application using tts is not an=20
option in KDE.
There are two considerations here; first use of text-to-speech by 'assistive technologies', which will by and large require AT-SPI or a yet-to-be-created KDE equivalent (which I still think would be a shame); and secondly, 'self voicing' applications which do their own speech. Self-voicing can be useful at times, but great care must be taken not to conflict with screenreaders - in many cases better consistency can be achieved by doing all speech from
the screenreader.

While I agree that D-BUS currently is not stable enough, introducing an=20
implementation independent API now would make it much easier to move to=20
D-BUS once it has become stable enough.

If you wish to tie speech synthesis to CORBA on GNOME, then this is OK for=
=20
me as long as a future transition to an implementation independent=20
protocol is not completely ruled out for the case that D-BUS is being=20
adopted by both KDE and GNOMEat a future point.
One reason why we chose CORBA/Bonobo for the implementation layers in AT-SPI and also gnome-speech is that it is really the IDL, not the bits, that are normative. Of course full binary compatibility requires CORBA, but as long as the gnome-speech IDL is used as the basis, the implementation need not be CORBA. That is, if a DBUS-based transport can be
compiled from (CORBA-like) IDL, the systems can be trivially bridged.

What is desirable is a one-to-one mapping of features and parameters between the systems; these features and parameters are defined by the IDL, which need not always be "CORBA IDL" in the sense that it is fed into a CORBA bindings generator. My recommendation would be that if the KDE community feels strongly enough about excluding CORBA, the logical response would be to create idl-to-source creation tools from which alternate implementations of _all_ the accessibility IPC could be created, including gnome-speech, gnome-mag, and AT-SPI. Then, alternate versions of the at-spi's "cspi" bindings could be created so that the existing at-spi clients could transparently
operate using the non-CORBA IPC mechanisms, without recompilation.

regards

Bill

Olaf







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]