Re: extension of Glade DTD to support accessibility



[ 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.

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.


> > 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).

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?

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).  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).

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.

>
> > >
> > > 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/






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