GNOME Bugzilla – Bug 647486
Analyze accessible instantiation: factories, AtkGObjectAccessible, base object - accessible relation
Last modified: 2021-06-10 11:26:17 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: FACTORIES: 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. But: * 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. ATKGOBJECTACCESSIBLE: 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: http://bugzilla.clutter-project.org/show_bug.cgi?id=2371 In the same, if we finally conclude that we don't require the factories anymore, AtkGObject would be using deprecated stuff BASE OBJECT - ACCESSIBLE OBJECT RELATION 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 [1] https://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00083.html
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) But * [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.
[Mass-reassigning open atk bug reports for better trackability as requested in https://bugzilla.gnome.org/show_bug.cgi?id=653179 . PLEASE NOTE: 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 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.]
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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a ticket at https://gitlab.gnome.org/GNOME/atk/-/issues/ Thank you for your understanding and your help.