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 647486 - Analyze accessible instantiation: factories, AtkGObjectAccessible, base object - accessible relation
Analyze accessible instantiation: factories, AtkGObjectAccessible, base objec...
Product: atk
Classification: Platform
Component: atk
Other Linux
: Normal normal
: ---
Assigned To: ATK maintainer(s)
ATK maintainer(s)
Depends on:
Blocks: 638537
Reported: 2011-04-11 18:34 UTC by Alejandro Piñeiro Iglesias (IRC: infapi00)
Modified: 2021-06-10 11:26 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-04-11 18:34:31 UTC
I decided to create just one bug about this because it has a common issue : accessible object creation, but we could split it in the future:


At this moment, the common way to instantiate a accessible object is based on factories.

When a accessible object is required, we ask for the factory on his gtype, and we return it. This factory is required to be registered.

It was really useful when gail was a isolated module (plugin). When gail was loaded all the factory system was initialized, so when you ask a accessible object to the widget, it just use the factory.

  * Recent toolkit developers asks to not use them (ST), at least in the built-in accessibles (see Bug 626658 comment 5)
  * We can't use them, when you expose non-gtyped objects (ie: Java, C++ hierarchies)
  * It is still required? Cally is not anymore a isolated module, and it is planned that Gail will be moved also.

Anyway, I guess that factories would not be removed, as provides a way to implement the object in a specific use case. *But*, it would be good to decide if you should use them as default (as the current wisdom), and if not, decide when to use it, and document it.


In the same way there is a problem with the interface AtkGObjectAccessible, that implements three common tasks:
  * Instantiate the accessible object using factories
  * Create the relation between the base object and the accessible object
  * Provides API (with horrible names IMHO) to get the accessible object from the base object, and the base object from the accessible object

But it supposes the factory to create the object, meaning that if you don't want to use the factories you will not use 1/3 of AtkGObjectAccessible features.

More about this:

In the same, if we finally conclude that we don't require the factories anymore, AtkGObject would be using deprecated stuff


Anyway, I still think that AtkGObjectAccessible is a useful interface, as most of atk implementors are gobject based. Cally is using it, and Matthias Clasen suggested that it could be a good idea to use it on Gtk [1]

But I think that the way it handles the relation between the accessible object and the base object is too opaque. This is because the method "accessible_for_object" it more than just a "return the accessible object", it is a "get or create method". I think that it would be good to have something like:

   * get_accessible_object => it can return NULL if no one exists at the moment
   * set_accessible_object => sets the accessible object
 This two would be mainly used by atk implementors, to make easier the creation of the method.

   * get_or_create_accessible_objec => this is the one that exists right now, it would be used to get a accessible object for a base object. It doesn't care if would be needed to create it or not

Comment 1 Alejandro Piñeiro Iglesias (IRC: infapi00) 2011-06-22 16:38:37 UTC
Conclusions from ATK Hackfest 2011 (sorry somewhat late):

 * It allows to provide the support required when a11y is off (see [1])
 * It is still working
 * Provides a general way to instantiate a glib based object
 * They could be maintained for the moment (as I already stated)


 * [1] we are already working on having the a11y on always. In fact Frederik suggested that an a11y object should be always returned instead of the current AtkNoOpObject. The reasoning here is that if a a11y object is asked, it means that it would be useful, and we should forgot of split when a11y is used or not.
 * Right now people are working to integrate gail on gtk. Eventually they would also remove factories usage. For coherence cally would also do that (as st is not doing that).
 * So what I said on comment 0 still applies:
(In reply to comment #0)

> Anyway, I guess that factories would not be removed, as provides a way to
> implement the object in a specific use case. *But*, it would be good to decide
> if you should use them as default (as the current wisdom), and if not, decide
> when to use it, and document it.
Comment 2 André Klapper 2011-06-23 22:06:48 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 3 André Klapper 2021-06-10 11:26:17 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.