Re: extension of Glade DTD to support accessibility

[Bill Haneman <bill haneman sun com>]

James Henstridge wrote:
> 
[Regarding ATK support for libglade...]

> Sounds interesting.  Recently I started looking at porting/rewriting
> libglade for gtk 2.0, so I will try to keep ATK in mind when doing so.

Hi James!

Thanks for such a quick followup.

> > As has been pointed out before, in many cases applications may need to
> > provide accessibility hints in addition to or instead of those provided
> > "automatically" by the ATK implementation for stock GTK widgets.  For
> > example, an unlabelled button may wish to set an accessibility "name"
> > without actually containing a label:
> >
> >   AtkObject atkObject = gtk_widget_get_accessible (aButton);
> >
> >   atk_object_set_name (atkObject, "Quit");
> 
> 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.

> > I believe that a libglade application can do this by querying libglade
> > for a pointer to the appropriate widget, via the widget's unique
> > identifier.  However it would be nicer if some ATK properties (at least)
> > were settable via attributes in the Glade XML.
> 
> 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.

> > This presumably suggests three steps:
> >
> > extension of Glade's XML DTD to include these (optional) attributes;
> > extension of libglade to parse these attributes and call the appropriate
> > atk methods (as above);
> > (eventually) extension of Glade to expose these attributes when a
> > developer is setting widget properties in the Glade UI builder.
> 
> 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>

> >
> > 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...
> 
> Sounds like a good idea.  I will need to read up on ATK a bit now (also
> for the python bindings).
> 
> James.

Again, thanks for the response, let us know any questions that
arise...

Best regards,

Bill


> --
> Email: james daa com au
> WWW:   http://www.daa.com.au/~james/

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