Re: [g-a-devel] GTK and ATK
- From: Brian Cameron <brian cameron oracle com>
- To: Matthias Clasen <matthias clasen gmail com>
- Cc: gnome-accessibility-devel gnome org, gtk-devel-list <gtk-devel-list gnome org>, Benjamin Otte <otte gnome org>
- Subject: Re: [g-a-devel] GTK and ATK
- Date: Fri, 13 May 2011 12:30:37 -0500
Matthias:
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.
I agree that providing more general text interfaces in the GTK+ layer
directly would be best. The ATK layer would become much more thin
and simple if this were done.
Note that I had been just using AtkText as an example. It is a good
example since it is a more complicated ATK interface. There are
other ATK interfaces (AtkAction for all widgets that provide actions,
AtkRelations to clarify widget relationships, AtkSelection for things
that can be selected, etc). So there are other opportunities aside
from text to improve GTK+ to provide information needed by AT programs
in common ways.
Above I say AtkText is particularly complicated. Note that the
libgailutil.so library exists so that different text widgets can use
common functions to do common things with text, such as getting text
details from pango. So, people who write "n adaptors for widget-
with-text to atktext" really do not have to reinvent the wheel each
time.
Some of the AtkText interfaces are not really used today, I should
highlight. The braille displays that exist today do not support
showing raised information at a resolution that would allow the user to
feel how the screen looks. Instead most braille displays just show the
text ASCII information in raised braille letters. However, the ATK was
written to support more sophisticated devices in the future like ones
that could present users with details they could feel like whether the
text is bold, in italics, centered, size, whether letters have serifs,
etc.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]