Re: AtkText attributes

[Brian Cameron <Brian Cameron sun com>]

Peter:

> Ok.  I'm suggesting we return an attribute struct that looks more or less like
> this.
> 
>   GetAttributeStruct {
>    int startIndex;
>    int endIndex;
>    boolean isBold;
>    boolean isItalic;
>    ...
>    char *fontName;
>    int (or maybe char *) fontSize;  // char * if we deal with fractional nos.
>    char *attributeStr;              // full string form, including attrs not
>  }                                     in our boolean list
> 
> Yes we're returning a struct, but it's one that can be allocated on the stack by
> the caller.  We're not malloc-ing an array of potentially very large size.
> 
> Does this proposal make more sense now?

Yes, that would work.  However, your suggestion has different assumptions than
what Bill & I talked about last week.  Bill suggested returning key/value pairs
because he didn't want to hardcode into ATK which attributes are supported.  He
pointed out that different bridges (like GTK+ and Java) may not share the same
concept of what constitutes an attribute and coming up with a definitive list
would be difficult and possibly limiting.  He pointed out that it would be 
cumbersome if the ATK had to be updated every time a new attribute needs to be
supported by some bridge.

So he was thinking that the function would work more like this.  He thought that
the function would blindly pass back the attributes in whatever form makes sense
for that bridge.

However, I'm not sure I completely buy Bill's suggestion.  Just for the sake
of conversation, let's assume that the "key" value for bold is "BOLD" in GTK
and "<b>" in Java.  I'm not sure how useful this.  It seems to me that this
requires that the person implementing any accessible program be aware of the
"key" values for each bridge and code for each separately (unless they happen
to have the same keys anyway).  So this means that anytime a new bridge is
added with new key representations for its text attributes, the person would
have to update their code to work with it.  While just returning name/value
pairs is easy for us to code and avoids having to figure out which attributes
are important, I think it might make havoc for the person trying to use the
interface.

For reference, the list of attributes supported in GTK is here (refer to
section "args")

   http://developer.gnome.org/doc/API/2.0/gtk/gtktexttag.html

You probably see where I'm leading.  Since we have not yet created a definitive
list of which attributes are important, someone will have to do so before we
can implement it the way you suggest Peter.  Does the Java accessibility API
have a discrete set of attributes it supports returning information about?
Any help in defining which attributes are important would be great.

Brian