Re: A few outstanding issues with ATK API



Peter Korn <peter korn sun com> writes:

> > There are a few issues, some along the lines of "do we really need
> > this", that Owen raised to do with ATK.
> > 
> > (1)
> > 
> > atk_editable_text_set_attributes(AtkText *text,
> >                                  gint start,
> >                                  gint end,
> >                                  PangoAttrList *attributes);
> > 
> > OK, Java AccessibleText has this feature.  We know PangoAttrList is
> > not supported by all the widgets that implement AtkEditableTextIface,
> > so there would have to be some transcoding/adapting of attributes.
> > That's messy but feasible.
> > 
> > Not every editable text widget supports attributes at this time.  No
> > problem, if attributes are not supported there is no case for setting
> > them ;-)
> > 
> > Pango attributes are maybe the wrong choice.  GtkTextBuffer seems to
> > use things called TextTags, if I understand it correctly.
> > 
> > My gut feeling is that this will be implementable on GtkTextView (via
> > the GtkTextBuffer) but Owen asked (in effect) the question "shouldn't
> > this be done via the application UI?".
> > 
> > So:  how do ATs use this feature in Java today (if they do), or
> > how/when do they use similar functionality in other environments?
> 
> I don't believe any AT for the Java platform is using this yet.  The
> main argument for this functionality is for voice control &
> dictation (and other non-traditional input devices; for example a
> sophisticated Braille terminal with keyboard entry via a chording
> Braille display).  The problem of forcing folks to do this through
> the application is that each app potentially does it differently,
> and that makes voice control/Braille/etc. much more cumbersome.
> Since in many cases it's the same widget/few widgets, it'd be nice
> if the programatic interface to them were the same.  This also has
> benefits for scripting interfaces, etc.

OK, that makes it clearer - I was wondering if this interface
was meant to be for the user to set attributes on the text, or
whether it was for use for things like highlighting the current
word/phrase.

I think there is are fundemental problems with trying to abstract
this away from the application user interface:

 - Not all applications using a widget that supports styled text
   may support setting the styles. (Imagine a programming editor
   or plain text editor)

 - Not all applications supporting styles will support all possible
   styles.
 
 - Updating the styles may involve updating internal application
   data structures as well as updating the visual text. For instance,
   a HTML editor will need to update its editor tree.

Regards,
                                        Owen




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