After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 598952 - Document the use of an object attribute to expose toolkit/source
Document the use of an object attribute to expose toolkit/source
Product: atk
Classification: Platform
Component: atk
git master
Other All
: Normal enhancement
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on: 651370
Blocks: 638537
Reported: 2009-10-19 15:57 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2021-06-10 11:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Joanmarie Diggs (IRC: joanie) 2009-10-19 15:57:58 UTC
As discussed in, Assistive Technologies have a need to identify the toolkit (or other source) associated with a given accessible. atk_get_toolkit_name() and atk_get_toolkit_version() can be too restrictive and/or problematic to implement when the elements in a single app come from multiple toolkits/sources.

This problem can be solved by the addition of an object attribute (e.g. 'toolkit:Gecko' or 'source:WebKit'). Adding it to the Atk API should lead to more standard implementation.

Comment 1 Alejandro Piñeiro Iglesias (IRC: infapi00) 2009-10-19 16:34:53 UTC
Well, if AtkUtil were a AtkObject, we could have tried to use:

AFAIK, AtkAttributeSet is oriented to the text related methods:

As there isn't any reason to not use that for more general things.

The missing thing is a general way to add attributes from the app or library side, something like atk_object_add_attribute. So, the attributes of a specific gailobject would be their custom implemention plus the one defined used this method (like ref_state_set, that each gailwidget get the set from their parent, and then add their custom ones).

As AtkUtil is not a AtkObjects, more new methods are required. So a proposal would be something like:
   atk_util_remove_attribute (not really required right now, but why not)

And keep using AtkAttribute type for coherence.

So, on the Webkit case, the solution would be something like:
   static void webkit_accessible_init(AtkObject* object, gpointer data)
   atk_util_add_attribute ("source", "Webkit");
And in orca:
   settings = atk_object_get_attributes (
BTW: as I said on webkit bug, and probably a nitpick, I wouldn't use a "toolkit:Webkit" pair. In that specific case, it is still using Gtk+ (so Gail) as a toolkit, by definition:
"Gets name string for the GUI toolkit implementing ATK for this application."

I would use "source:Webkit" or something similar, but probably a minor detail here ;)
Comment 2 Willie Walker 2009-10-19 17:41:47 UTC
The issue we're dealing with here is that some applications may freely mix toolkits.  A prime example is Firefox mixing Gecko, XUL, and GTK+.  The implementation of some roles (e.g., combobox) can vary enough that an assistive technology can find it useful to know which toolkit an object came from on a per object basis.

As such, looking at the 'toolkit' field of an AccessibleApplication object is not sufficient since it applies to the entire application and not individual objects.

The proposal at hand is to add an object attribute that identifies the toolkit used to create the object.  Since the word 'toolkit' is already in use to identify this kind of thing at the AccessibleApplication level, I would argue that we either add a 'toolkit' field to the Accessible object or just make a 'toolkit' name to be reserved.  This name would be used to obtain an optional attribute from the object's attribute list and would specify the toolkit being used.

The attribute name itself is very important since assistive technologies will want to use just one attribute name (i.e., not 'guithingy' for the Java Swing toolkit, 'flurblekit' for Gecko, 'widgetset' for GTK+, etc.).
Comment 3 Alejandro Piñeiro Iglesias (IRC: infapi00) 2009-10-19 18:01:18 UTC
After think this a little more, and after Willie and Joanmarie explanation about how to use it, you can forget my comments about new methods on AtkUtil, and in fact what Joanmarie wanted, AFAIU, is just use atk_objet_get_attributes, but just opened this bug to conclude which attribute use, and how name it in any toolkit.

In the same way, probably I was just too obstinate with the "toolkit vs source" thing, something paradoxical, as I had the perfect example of why we would require to get the toolkit name per object: in the hypothetical mixed environment of Clutter and Gtk+, we will have objects created with different toolkits (Clutter vs Gtk+, Cally vs GAIL).

Anyway, in the case of Webkit, I would try to keep this Gail or Gtk somewhere. If finally the (KDE,Qt) world starts to use at-spi and atk things, there are a possiblity that Webkit would require to create a different Atk wrapper for the Qt thing (anyway, just guessing, I don't know anything about the Qt backend in Webkit).

So perhaps something like attribute="toolkit", value="Gail:Webkit" or value="Qt:Webkit" is another (and random, quick-thought) proposal.

If we finally go for this way... what will happen with the atk_util_get_toolkit_name? Would be used only to know which implementation (or toolkit or whatever) is providing the root object?
Comment 4 Joanmarie Diggs (IRC: joanie) 2011-01-07 00:45:35 UTC
(In reply to comment #3)

> If we finally go for this way... 

It works splendidly for WebKitGtk and is coming in quite handy for both Yelp 3 and Epiphany. I hope everyone else sees fit to follow. :-)

> what will happen with the atk_util_get_toolkit_name? 

To be honest, that method at the moment is at best a crapshoot due to its inherent assumption that there is only a single toolkit being used in any given app. More and more that is an erroneous assumption. If we could get every toolkit to expose to us where its widgets came from, we'd have reliable information that we could act on, thus:

> Would be used only to know which implementation (or
> toolkit or whatever) is providing the root object?

At most. More likely it would no longer be used at all. ;-) Because if everyone were to do as is proposed here, the root accessible non-application object would expose that information just like any other AtkObject. And what the application object itself claims to use as its toolkit would become irrelevant.
Comment 5 Joanmarie Diggs (IRC: joanie) 2011-01-08 21:27:45 UTC
Follow-up thought: We will also need a way to get the toolkit version in at least some cases. We do get that now via atk_get_toolkit_version. It of course shares the same issues as getting the toolkit name. Guess I have more RFEs to file....
Comment 6 Joanmarie Diggs (IRC: joanie) 2011-05-12 10:57:07 UTC
ATK Hackfest Conclusions:

1. There should be a cleaner/less-hackish means to provide this information. (To be discussed later this week towards ATK2.)

2. Because this is needed currently, providing this information as an object attribute is acceptable to the group.

3. There are no objections to also providing the toolkit version as an object attribute for ATK1.

4. The object attributes should be documented as 'best practice' for now, until the ATK2 solution is defined and implemented.
Comment 7 André Klapper 2011-06-23 22:06:54 UTC
[Mass-reassigning open atk bug reports for better trackability as requested in .
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 atk-maint@gnome.bugs to your watchlist at the bottom of 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.]
Comment 8 André Klapper 2021-06-10 11:27:51 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
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.