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

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
 - 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.


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