Re: AtkText attributes

[Peter Korn <peter korn sun com>]

Hi Brian,

> > ... my proposal for a struct for attributes & ranges ...
>
> ... Brian raising the question of different attributes coming from different
      places ...

I think the individual bridges should be able to map <b> to "bold" to ... as
needed.  And I really like the extensibility of asking for specific tags and
then getting those back (or really a set of tags).  

The idea I put forth was that there would be a "core" set of attributes, and
then the full set would be represented in string form.  But a tag-based approach
makes a lot of sense, so long as we have a way for the requestor to ask for a
set that it's looking for.  I also think returning a string-form of them is also
useful, so that a user can get attribute information that the screen access
product is not aware of (so to speak or Braille the string, for example).


Peter


Brian Cameron wrote:
> 
> 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
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list