Re: issues with X Window

[Paolo Molaro <lupus lettere unipd it>]

On Sun, Aug 22, 1999 at 08:33:15AM -0700, T. V. Raman wrote:
> and given the way both Gnome and kde are architected,
> the foundations are there for building good speech
> applications on top of either of those environments.

I don't know KDE and Qt very well, but I think it's not possible
(as it is now, at least) to enable a speech/audio interface.
I'll try to explain some of the requirments for an effective
approach and describe what gtk provides and makes GSpeech possible.

There are two basic requirements: 
1) the thing should work with the applications unmodified
2) the thing needs access to the application internals

The first requirement means that our tool should work with an
application without changes to the application itself. This is not 
always possible, sometimes an applications needs some usability 
enhancements, but the point is that the tool must be external
to the application, otherwise you will need to upgrade your tool
whenever you upgrade the application, keep them in sync, have
a different tool for every different application and so on.
This is not going to work in the long run without a general, 
application-independent approach.
The problem is that there is another requirement to be satisfied:
to be effective the tool needs access to the application's internals,
the widget hierarchy, the relative positions of the user interface
components etc.
This requirement is what makes the difference between reading email
with elm and a screen reader and reading email with emacspeak, the
latter being the most effective approach.

Now, Gtk+ is an object oriented library written in C.
This means that there is an object hierarchy, and objects have
properties and methods. In addition Gtk+ objects have what are
called "signals": signals are emitted whenever something important
happens in an object. For example, the "clicked" signal is
emitted whenever a GtkButton widget gets clicked with a mouse
or activated with the keyboard.
It's important to highlight that a signal has a textual name and
that the properties of an object have names as well that are
exposed with a standard and unified interface.

This means that I can request the "title" property of a window
the same way I request the "active" property of a toggle-button.

Also, object properties as well as additional arguments of signals
carry type information with them: I know that the "title" property 
of a window is a string, while the "active" property of a toggle-button 
is a boolean value.

In gtk it's possible to listen to the signals emitted by the widgets
that build the interface and thus provide the proper speech or audio
feedback to the user.
The tool that translates the signals to the audio feedback is
loaded in the address space of the application (GSpeech is a shared
library, in the end) automagically by gtk setting an environment
variable or with a command-line argument.

In addition to this, GSpeech will provide other features, but this mail
is already too long:-)

lupus

-- 
lupus debian org
Se devo emigrare in America, come mio nonno, prendo il tram!        [F.G.]
If I have to emigrate to America, like my grandfather, I'll take the tram.