Re: extension of Glade DTD to support accessibility



James wrote:

>Okay.  With proposed syntax for storing the accessibility properties in
>the XML, there is no reference to the name of the AtkObject.  Do you think
>it would be sufficient to use the name of the GtkWidget the AtkObject is
>associated with for the parent?  That is, if we had this in the XML file:
>
>  <widget id="widget1" ...>
>    ...
>  </widget>
>  <widget id="widget2" ...>
>    ...
>    <accessibility>
>      <property name="AtkObject::parent">widget1</property>
>    </accessibility>
>  </widget>
>
>then the parent of widget2's AtkObject would be widget1's AtkObject.

This probably would work OK.  

There are a few cases where the accessibility properties would be hard to 
describe with just an XML "body string", but I agree that those cases could 
be handled in application code after instantiating the UI.  For the most part 
these are things like Table headings (which may be, for instance, 
"containers" of atkobjects which correspond to rows/columns in the table).

Even this case could be handled in the XML reasonably well if we could 
specify an "accessibility" element that is not a child of a widget.  In this 
second case we would indeed want an id field for the <accessibility> element, 
or else we would want to allow <accessibility> elements to have 
<accessibility> children:

...
<accessibility>
  <property name="AtkTable::column_header_1">
    <accessibility>
      <property name="AtkObject::name">Sender<property/>
      <property name="AtkObject::description">
      Address from which email was sent</property>
      <property name="AtkAction::name">activate</property>
      <property name="AtkAction::description>sort by sender</property>
    </accessibility>
  </property>
  ...
</accessibility>

(In the above example the intention is to specify an atkobject that serves as 
the column header for column 1 of a custom widget, but which does not have a 
corresponding GtkWidget object.  This sort of flyweight element within a 
widget is fairly common in custom widgets).

Even in the simple case there is the problem that multiple actions may exist 
for one accessible object, in which case the above syntax doesn't connect the 
AtkAction::name and AtkAction::description with one another.  So the 
AtkAction stuff needs to (potentially) be grouped together:

...
<accessibility>
  <property name="AtkTable::column_header_1">
    <accessibility>
      <property name="AtkObject::name">Sender<property/>
      <property name="AtkObject::description">
      Address from which email was sent</property>
      <atkaction name="activate">
        <property name="AtkAction::description>sort by sender</property>
      </atkaction>
    </accessibility>
  </property>
  ...
</accessibility>

(I am assuming that multiple instances of a "property" element with the same 
name are disallowed, thus <atkaction> is a child of <accessibility>, not a 
property.)


This still seems a lot more verbose than using XML attributes:

<accessibility>
  <atkobject name="Sender" description="Address from which email was sent"/>
  <atkaction name="activate" description="sort by sender"/>
  ...
</accessibility>


But that is of course your call.


>Or would more fine grained control be appropriate?  I am trying to work
>out what would be a good compromise between how configurable to make it
>and how to make it easy to use from a UI builder.
>
>James.
>
>
>_______________________________________________
>gnome-accessibility-list mailing list
>gnome-accessibility-list gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list

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





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