GNOME Bugzilla – Bug 651370
Come up with the proper way to expose object toolkit name and object toolkit version for ATK2
Last modified: 2021-06-10 11:25:30 UTC
Currently certain toolkits are exposing the toolkit name for an accessible object as an object attribute. This was a (much appreciated) quick-fix so that ATs can properly handle widgets from one toolkit embedded in an application from another toolkit. (See bug 598952)
However, this solution is a hack. We need a proper way to expose the toolkit name, along with the toolkit version for any given AtkObject.
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 .
If you have watched the previous assignee of this bug report as a workaround for actually getting notified of changes in atk bugs, you yourself will now have to add email@example.com to your watchlist at the bottom of https://bugzilla.gnome.org/userprefs.cgi?tab=email to keep watching atk bug reports in GNOME Bugzilla.
Sorry for the noise: Feel free to filter for this comment in order to mass-delete the triggered bugmail.]
This applies to libraries (e.g. embedded evince documents) as well.
After a IRC chatting:
* In general exposing the toolkit is not enough. For example, on webkitgtk, the toolkit is gtk, but the ATK implementation of the html objects came from webkitgtk implementation. This is the reason webkitgtk is being exposed as "toolkit"
* An application can be using different libraries (like Joanmarie comments on comment 2), and it could be useful to expose the library that is implementing ATK.
In that sense, one option could be an API like this:
That would deprecate their equivalents on atkutil, and the need of an attribute on atkobject.
Anyway, not sure about the API naming.
Those names seem fine to me.
I was taking a look to this bug, because the wayland situation pointed again to the need of properly support more than one toolkit.
There are a technical problem with the API propoesed at comment 3. Right now AtkObject only have one extra pad to add a new virtual method, so adding two new methods is impossible.
One option could be collapse those methods in one call. One flexible solution would be keep the idea of the AttributeSet:
atk_object_get_implementation_data (AtkObject *obj);
So a loose documentation would be something like this:
* obj: an AtkObject
* Returns: an attributeset with exactly two attributes, 'implementation' and 'implementation-version' which are <insert_documentation_here>
The advantage of this definition is that is flexible and easy to implement. The only drawback that I see is that it doesn't force implementors how to fill the AttributeSet, as you can put it whatever you want. Anyway, not sure if that is a problem as far as it gets properly documented.
PS: again, adding this new method would mean deprecate atk_get_toolkit_name and atk_get_toolkit_version, and ask implementors to stop expose toolkit as an attribute.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).
If you can still reproduce the situation described in this ticket in a recent
and supported software version of atk, then please follow
and create a ticket at
Thank you for your understanding and your help.