Re: [g-a-devel] GTK and ATK

[Piñeiro <apinheiro igalia com>]

On 05/13/2011 04:32 PM, Matthias Clasen wrote:
> On Wed, May 11, 2011 at 11:09 AM, Brian Cameron
> <brian cameron oracle com>  wrote:
>
> > Another example is that the ATK abstracts common characteristics of
> > widgets in a way that is useful to AT programs.  All widgets that deal
> > with text (labels, entry fields, combo boxes, etc.) all implement the
> > same AtkText interfaces, providing AT programs a common way to provide
> > alternative UI's for the end user.  While not trivial, adding ATK code
> > for a custom widget is a more reasonable approach to making a custom
> > widget accessible than having to update every AT program like orca to
> > support it.  If we did not have the ATK, the AT program suddenly needs
> > to know how to interact with each stock and custom widgets directly
> > and separately.  This adds a lot of code to the AT program, you see.
> I would argue that if all the widgets dealing with text really have
> the same needs, they should really support the same interface in GTK+,
> and there should be no need to write n adaptors for widget-with-text
> to atktext, but instead just one for text-widget-interface to atktext.
> And ideally, text-widget-interface and atktext would be so close to
> each other that that would be trivial.

In general the main difference of what an accessibility oriented
text interface (AtkText and AtkEditableText) required and what
and UI toolkit text interface provides are more accurate ways
to get the text based on the current position, and general on a
more high level point of view that just a text between some
offsets, as usually you want full words. ie: AtkTextBoundary
defines 7 different boundaries when you ask for the word.

In fact, current gail-text-util is mostly an utility library to
make a conversion between them.

[1] http://developer.gnome.org/atk/stable/AtkText.html#AtkTextBoundary

--
API