Re: extension of Glade DTD to support accessibility

[Bill Haneman <bill haneman sun com>]

James Henstridge wrote:
> 
> [ I have CC'd Damon on this, as he is the glade maintainer ]
> 
> On Thu, 10 May 2001, Bill Haneman wrote:
> 
> > > or alternatively,
> > >     g_object_set (atkObject, "name", "Quit", NULL);
> >
> > These are not (generally) GObject properties (see below).  So one must
> > use the above "atk_object_..." API.
> >
> > > (using the properties support for GObjects).  Does ATK expose all the
> > > properties you might want to manipulate through the properties interfaces?
> > > One of the goals for the change is to move as over to using properties
> > > where possible.
> >
> > For various technical reasons these are not GObject properties.  For
> > one thing, they are computed on-demand, and may be complex data types
> > with reference counting implications.  This API is also intended for
> > non-GTK contexts, so a new API was appropriate.
> 
> Well, g_object_set() is an API in glib, and part of the object system used
> by ATK, so properties aren't tied to GTK+ :)  I don't see how the computed
> values thing should be a problem -- you can compute values during a
> get_property() -- there isn't that much difference between properties and
> a set/get pair for an object.

The "not just GTK+" issue with GObject properties is not one of
dependencies, it's based on the fact that a library dependency is
different from "dependency" on an API metaphor.  Some users of ATK may
be unfamiliar with glib.

> Although I do remember Tim saying that you couldn't introduce new
> properties with an interface, which would be a problem for ATK.  Shouldn't
> cause much of a problem for libglade.

This is one of the reasons why ATK attributes are not GObject
properties.

> > > Well, I have been proposing that we rewrite the glade XML format for gnome
> > > 2.0, so adding support for AtkObject properties sounds like a good idea.
> >
> > Great!  It would best of all if the port to GTK 2 happenned as soon as
> > practical, so that there was ample time for applications to test their
> > accessibility support and make changes if appropriate before feature
> > freeze.
> 
> At the moment, I have just made the GladeXML object into a GObject and am
> now looking at making changes to the XML format, so this was a good time
> to ask me about this.  I will try to have something you can play with
> soon (I can't say how soon it will be ready though).
> 
> Damon: what are your current plans w.r.t. glade and gtk 2.0?  It will
> probably take longer than a port of libglade (if both ports are aiming to
> take advantage of new features in the gtk/gnome 2.0 platform rather than
> just making the minimal changes to get things working).
> 
> > > Maybe adding a section like this to the XML:
> > >   <widget id="name" class="GtkButton">
> > >     ...
> > >     <accessibility>
> > >       <property name="name">Quit</property>
> > >     </accessibility>
> > >     ...
> > >   </widget>
> >
> > That sounds right, or
> >
> >      <atkobject id="button1_acc" name="Quit"/>
> >
> > if we use attributes.  There are subinterfaces, thus:
> >
> >      <widget id="table1" class="GtkTreeView">
> >         <atkobject id="table1_acc" parent="window1_acc">
> >           <atktable id="table1_table_acc" caption="Table of Foo vs.
> > Bar Values"/>
> >         </atkobject>
> >      </widget>
> 
> As I said, I haven't looked at ATK much, or looked at many examples of its
> use, so I could be totally wrong about the following comments.
> 
> I would have chosen the following syntax for your AtkTable example:
>   <widget id="table1" class="GtkTreeView">
>     <property name="expander_column">0</property>
>     <accessibility>
>       <property name="AtkObject::description">blah</property>
>       <property name="AtkTable::caption">Table ...</property>
>     </accessibility>
>     ...
>   </widget>
> 
> ie. The <property> elements are in the same/similar format to those used
> for widget properties (in the new XML format I want to use for libglade
> 2.0).

Fine by me, though it's more verbose than using XML attributes.
 
> Is it common to want to set the parent of an AtkObject gotten through
> gtk_widget_get_accessible?  Wouldn't it just be the accessible of the
> parent widget?

Not always, and if not, you need the set_parent() API.  It's there in
order to simplify or adapt widget hierarchies for alternate access,
sometimes the best hierarchy for adaptive technology access is not the
same as the "best" for purely visual presentation.

> Is it common to set attributes of an AtkObject that isn't directly related
> to a GtkWidget (like the ones returned by atk_table_ref_at).  

Not really, and it's probably not very implementable in Glade since
the "ref_at" children will sometimes be flyweight objects that don't
persist. 

> If it isn't
> common, then it might be easiest to limit what glade/libglade can
> manipulate to just the AtkObject associated with the widget.  Complex
> manipulations can always be done after libglade has finished building the
> UI (people already do this with libglade to add extra widgets to the UI or
> change some settings on widgets).

Generally you'll want to manipulate the atkobject properties, which
may include properties defined in atkobject subinterfaces (atktext,
atkselection, atktable, etc.).

> Is there any sample GTK programs that manipulate AtkObjects?  It is a
> little difficult to work out which bits of ATK a programmer might want to
> use and which bits are just hooks for toolkits built on top of ATK.

Since these are GTK+-2.0 only interfaces, and have only been in CVS
for a week or so, no... I'm afraid that all I can offer is the
enumeration, below, of the ATK methods that are most likely to be used
in applications for enhancing their accessibility support.

> >
> > > >
> > > > I believe that the ATK attributes of most interest are those ordinarily
> > > > set by the following ATK methods:
> > > >
> > > > atk_image_set_image_description (AtkImage *image, gchar *desc);
> > > > atk_object_set_name (AtkObject *accessible, gchar * name);
> > > > atk_object_set_description (AtkObject *accessible, gchar *desc);
> > > > atk_object_set_parent (AtkObject *accessible, AtkObject *parent);
> > > > atk_object_set_role (AtkObject *accessible, AtkRole role);
> > > >  (ROLES are readily specified via a string)
> > > > atk_table_set_caption  (AtkTable *table, gchar *caption);
> > > > atk_table_set_column_description (AtkTable *table, gchar *desc);
> > > > atk_table_set_row_description  (AtkTable *table, gchar *desc);
> > > >
> > > > also (very important!) need to have multiple attributes of type
> > > > "atk_relation" settable on a widget.  The atk_relation consists of a
> > > > relation type flag (such as LABEL_FOR) and a reference to some other
> > > > widget (implementable using an "id" attribute if glade XML supports such
> > > > attributes on the XML elements). AtkObject's set_parent method likewise
> > > > takes a reference to an "AtkObject" object.  The other methods are
> > > > readily implemented using character strings as attribute values.
> > > >
> > > > Comments, suggestions (and volunteers :-) welcome...
> 
> James.
> 
> --
> Email: james daa com au
> WWW:   http://www.daa.com.au/~james/

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