Hi, sorry for the cross-posting, but as this affects the main toolkits
on GNOME, I also would like to have their input.
TL;DR;
AtkUtil and current hacks to avoid it being overrided sucks. In fact, in
some cases, we don't even have hacks, so gnome-shell accessibility under
Wayland is broken. We need a better API.
Long explanation:
*Background*
The idea behind ATK was being an abstraction of UI elements using common
accessibility terms. In that aspect, ideally you only want to have an
object that represent a UI element and some info. Additionally
accessible tools need some extra global functionality, like mouse
tracking or consume keystrokes. But as we already have a global daemon
bringing all the accessible information and functionality, the at-spi2
daemon, ideally2 we would like to get that information from this daemon.
On X, at-spi2 tried to get all the information from there. In short, ATK
being a server-side library, and atspi being a client-side library. But
although that is the ideal situation, the real situation is that some of
the functionality needed to be provided by the toolkit (so from the
application) itself. Specifically global keystroke listening. To make
this worse ATK was designed with the idea of one-toolkit/implementation
for application. All this mixtured in a rush led to the horrible AtkUtil
API, that toolkits needed to implement, but you only can have one
implementation to rule them all. That means that on situations with more
of one toolkit, it was needed to add several hacks to ensure which
implementation do you want, because implementations needs to override
previous defined implementations of AtkUtil (hacks added due Firefox).
Since I become ATK maintainer, AtkUtil has started to be more and more
smaller. Some of his methods were deprecated, and others were
implemented by ATK itself, so toolkits need to implement less and less.
My hope was being able to get rid of it eventually. Especifically, I
hoped that Wayland would provide a way to listen/consume key events
globally, without the need of toolkits providing it, so moving that to
libatspi.
At the same time, knowing from which toolkit each accessibility object
came became relevant. This is because in short, the behaviour under each
environment can be different, and is not possible to hide it just with
an abstraction. For example, dealing with epiphany, for Orca is relevant
to know if an object came from gtk+ (the menus, etc) or from webkit
(from the html content itself). As ATK only provides one point to expose
the toolkit, the hacky solution was ask implementors to expose the
toolkit via an attribute on the atk object [5][6] (attributes are a
general way to expose custom information from an accessible). Something
that is confusing. So as I say on this bug [2][3], I would like to add a
method to AtkObject and deprecate global AtkUtil get_toolkit.
Doing that, there would be only two things that prevents to kill AtkUtil:
* Accessible root object
* Global key event listener
The root could be solved by just adding a method on at-spi2-atk to
specify which is the root object. And, as I said I hoped to be able to
remove the global key event listener too.
*The problem*
1. Getting a solution for the key stroking on X has shown to be more
complex that thought. And more important, it seems that it will be also
the case for Wayland. Taking into account what Matthias Clasen told us
during Montreal summit and on this email [1], on Wayland that will be
the case, at least on medium term. So that functionality would need to
be provided by implementors for a while.
2. Right now on Wayland, gtk AtkUtil implementation is overriding
clutter AtkUtil implementation, so gnome-shell is inaccessible under
wayland [4]. The fact that were working before was merely luck, as
clutter_init was called after gtk_init. It seems that on wayland the
order is the opposite. And of course, there is the possibility of
stopping to work under X.
*Conclusion*
In the end toolkits need to provide some toolkit-side unique
functionality, and as we can be in a multi-toolkit environment, we also
need a way to specify which one we want.
*The proposal*
Initially I thought on this:
* Define a new class, AtkToolkit. Basic functionality, get root object
and global key event listener.
* Add a new method on AtkUtil that allow to register toolkit objects.
* Add a method on AtkUtil to retrieve registered toolkits and specify
which AtkToolkit you want to use.
* get_root and global_key_event_listener on AtkUtil will be
reimplemented, in order to delegate on the active toolkit object
* gtk+ would create their own subclass of AtkToolkit, create one
object and register it. Clutter would do the same. gnome-shell will
specify which one will be the active.
* AtkObject would have some methods to retrieve from which toolkit it
comes [4]
* AtkUtil get_toolkit_name/version will be deprecated.
All that would solve the situation. The problem with this proposal is
that there are "too many toolkits" here. From one side we have one
Toolkit object that provides some specific functionality, and has a kind
of global meaning. From the other side, we have a method for each object
to retrieve the specific toolkit name/version. And that this could leave
to confusion. I guessed if that could be solved by just using a
different terminology. So keeping atk_object_get_toolkit_name, but
rename AtkToolkit to AtkImplementation. Or the opposite (as suggested
here [3]). What I really want to avoid is something called "Util" and
being one of the most important pieces of the library.
In any case, there is a chance that the proposal itself can be improved.
Comments, suggestions, thoughts?
BR
[1]
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011487.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=651370#c3
[3] https://bugzilla.gnome.org/show_bug.cgi?id=651370#c5
[4] https://wiki.gnome.org/Accessibility/Wayland
[5]
https://git.gnome.org/browse/gtk+/tree/gtk/a11y/gtkwidgetaccessible.c#n516
[6]
https://git.gnome.org/browse/clutter/tree/clutter/cally/cally-actor.c#n525
--
----
Alejandro Piñeiro
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
