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 _______________________________________________ gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
