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

[Piñeiro <apinheiro igalia com>]

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