Re: [g-a-devel] Extensible states (or properties)

[Bill Haneman <Bill Haneman Sun COM>]

Hi Aaron:

I've looked into this issue recently.  I now think that it's probably 
not a good idea to allow unknown/un-enumerated states in our statesets, 
because of the way the StateSet API is used.

While in general we have tried to use 'States' for binary properties of 
objects, most of the examples below feel more like attributes or "tags" 
to me.  As such, they can be expressed using the new "object attributes" 
API in ATK HEAD.

regards

Bill

Aaron Leventhal wrote:

> One thing that has come out in the working group for DHTML 
> accessibility is the need for extensible states.
>
> Some sample use cases:
>
> _Email:
> _An email message may be marked with states such as "Junk", "Flagged 
> for follow up", "Unread"
>
> _IM client:_
> A buddy in a buddy list can have one of the states: idle, away, do not 
> disturb, etc. These may not be boolean as there may be a status string 
> such as "Idle for 33 minutes" or "Away: at lunch"
>
> _Calendar:
> _A schedule item make have a state: conflicting, repeating, tentative, 
> etc.
>
> We can try to expand the states table to contain all of these use 
> cases, but I don't think we can ever name all of the useful potential 
> states or properties. At the moment people stuff this information into 
> a tooltip or accessible name, which isn't a good long term solution. 
> UI Automation will provide a localized statusString which will provide 
> this info, but that is not semantic -- it would not allow the toggling 
> of these states via on onscreen keyboard. On the other hand, it is a 
> practical, simple solution which gets most of what's needed.
>
> What will ATK provide?
>
> - Aaron
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel