I have realized that I forgot to include gtk-devel@list in my
answer. C&P my answer here, just in case someone is interested.
Please, if you want to answer this mail, also include gnome-accessibility-devel gnome org
===
On 05/10/2011 08:38 PM, Federico Mena Quintero wrote:
In general your mail is a good summary (IMHO). Some brief comments.
Instead, you
want a central abstraction so that you only have to write
(N+M) implementations.
at-spi is the central abstraction. It lets you "navigate" a user
interface in very abstract terms, "read" what its various parts
say, and
"write" to user-modifiable parts. "What controls do you have?
Oh, is
that control a table? Does that cell support an editable text
interface? You say that there's an image there but the user can't
see -
do you have a textual description for it?" Stuff like that.
at-spi is that set of abstract interfaces described in D-Bus
parlance.
In general accessibility abstract interfaces. After all AT-SPI
stands for "Accessibility Technology Service Provider". An provider
for accessibility services. at-spi (CORBA) and at-spi2 (DBUS) are
just specific implementations of that service.
Right now, the
at-spi2-core module is a C binding to those D-Bus
interfaces. In C you call atspi_selection_get_selected_child()
and it
does a D-Bus call for you. That module also has a "registry",
whose
purpose I don't fully understand, but I think it's so that things
on the
left side of the diagram above can find things on the right, and
vice-versa. Or something like that.
In summary, yes this is the reason. ATs require to know which apps
they need to take care and check events. FWIW, we are discussing if
makes sense to make a registration in the other side of the diagram:
https://mail.gnome.org/archives/gnome-accessibility-devel/2011-February/msg00037.html
Applications
with custom widgetry, like Evolution, usually implement the
ATK interfaces directly in their code - they don't have a separate
module like GAIL.
FWIW, there is right now a plan to move GAIL code to Gtk. In the
same way, most of the current ATK support of ST (sadly, not too much
right now) is also integrated on ST code.
Various other
software has seen that ATK is a convenient place to plug
in, and instead of providing its own DBus<->toolkit layer,
it instead
implements ATK interfaces in terms of calling its own toolkit, and
calls
it a day. This is not a problem in itself, but it makes ATK even
more
of a point of failure. (FIXME: is this accurate?
http://accessibility.kde.org/developer/atk.php
suggests that this is
what Mozilla does.)
Not sure if this is a real question (due the FIXME). What it is your
doubt about the information on that (old) link?
One problem may
be that at-spi sometimes wants to be tightly-bound to
things that are far away from it, and that's bad design.
For example, consider the use of numerical indices in the
Selection
interface. When the innermost layer (GTK+ or any other toolkit,
or a
custom widget) changes something in its UI, the numerical indices
that
you got from at-spi may no longer be valid. This means that you
have to
write code to keep things in sync, and it gets messy real fast.
Maybe
you should get opaque, unchanging IDs for objects, so that if one
of
them is deleted, the other references you have are still valid.
About this specific case:
https://bugzilla.gnome.org/show_bug.cgi?id=644508
Maybe at-spi
needs to be more stateless. I don't know exactly how that
would work, but maybe it's about letting you reconstruct your
"view" of
an accessible application easily, in a couple of D-Bus calls,
instead of
doing a million calls just to re-sync everything. Take a widget
hierarchy and its available accessible interfaces, and push the
entire
thing as a JSON blob? Use paths to refer to widgets (or
accessible
objects), like SomeApp/MainToolbar/SaveButton instead of querying
each
sub-hierarchy by hand just to get a volatile object reference? I
don't
know.
I'm not sure if Im understanding that paragraph.
Maybe the D-Bus
stuff on the client side should be maintained directly
inside GTK+? (Does anyone *call*
ATK directly to implement an
accessibility dongle, or do they always go through D-Bus? Why
does ATK
need a public API - can't it just be basically the "structs" for
the
GTypeInterfaces and as little boilerplate as needed to make those
interfaces implementable?)
So if in the future we change D-Bus for "MyAwesomeIPC" that would be
totally broken. On the current state, gail code, cally code and in
general any ATK implementation didn't require to be modified at all
due those abstraction layers. Those works on both at-spi and
at-spi2.
D-Bus is just an IPC technology, I wouldn't add a direct D-Bus
dependency on Gtk+.
Anyway, this is
just an overview of the problem. I hope it's useful to
see what to do.
In general terms it is a good summary, and expose some good
suggestions.
Thanks for taking care.
Best regards.
--
API
|
