Re: Help needed: About gnome architecture - auditory desktop

[Bill Haneman <bill haneman ireland sun com>]

Eduardo Trapani wrote:
> 
> I considering the possibility to develop a software to map the gnome
> desktop and applications into an auditory desktop that will not
> necessarily follow the same metaphor as the grafic one.  This would
> create peers for each object in the desktop.

Hi Eduardo:

I recommend that you look at the Gnome Accessibility Project pages
(http://developer.gnome.org/projects/gap) and review the ATK API. 
There is work already underway that, in effect, creates ATK "peers"
for desktop objects.  The textual and other information provided by
these ATK implementations is intended for use by alternative interface
presentations, such as auditory interfaces.

> I really don't know where to start, I am reading the documents on the
> gnome architecture, but the API is huge and it will take me a lot of
> time just to know if can do what I want to do.
> 
> This is why I am asking for your help and maybe some pointers, including
> of course the right mailing list to post this message to :) in case
> there is one more appropiate.
> 
> At least I would need to know if I can do the following things (and
> where):
> 
> a1) be able to hook myself at the factory/destroy level, so that I can
> create/destroy the peer objects at the same time that happens at Gnome.
> Even if it involves changing gnome-libs.  Actually I want to know if
> there is a single entry point for all object creation/destruction.

Again, I would recommend that you use the existing AtkObject
interfaces, which already are integrated into the GtkObject
life-cycle.
 
> a2) be able to traverse (walk) the whole tree of objects.

GTK allows enumeration of widget children.  However ATK also supports
this feature, and allows for alternate interface peers to have trees
that are slightly different from the normal UI trees when appropriate.

> a3) be able to register myself so that I get informed each and every
> time a object is created/destroyed/(modified?).

ATK supports property change listeners, by exposing several kinds of
notifications: property changes on AtkObjects (UI peers); deletion and
addition of children; object focus events.
 
> b) send events to widgets so that I can gateway the input from the
> auditory desktop to the gnome desktop.

GTK widgets are being patched to better support keybindings.  Vision
impaired users should be able to access all of the GTK widget actions
from the keyboard, and by using ATK an auditory interface can be
notified of the user's actions.  Regarding other types of input, look
at the definitions of AtkEditableText and AtkSelection, for instance,
which allow alternative interfaces to perform text editing and
selection.

In order to support multiple applications running in separate process
spaces, and also to support non-GTK+ applications, Gnome 2.0 will
provide a "service provider interface" to which "adaptive
technologies" should connect.  This interface will support basically
the same featureset as ATK, but in a way usable by external processes,
and also provide this information for Java programs (and other
programs using non-GTK+ widgets, for which "bridges" may be written).

Perhaps you could describe in more detail the particular applications
and "use cases" which you would like to support, then we could discuss
how existing and planned Gnome accessibility interfaces could best be
used. 

If you truly want to present a different metaphor, then perhaps GTK+
is not the right tool, you might consider other ways of providing
alternate interfaces to applications.  If you do so, I think that the
ATK or Gnome Accessibility SPI should still be supported, in order to
interoperate best with other adaptive technology solutions that are
anticipated for the Gnome desktop.

Best regards,

Bill
 
> Thanks, Eduardo.

--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland