GNOME Bugzilla – Bug 611507
AtkUtil problems with loading multiple Atk implementations.
Last modified: 2021-06-10 11:25:11 UTC
A while back API asked on the gnome accessibility lists about issues with loading multiple modules. The thread can be found here: http://mail.gnome.org/archives/gnome-accessibility-list/2009-August/msg00019.html I replied that I believed there were major issues with the AtkUtil API, in that each module implemented this API itself and as such loading of multiple modules became difficult. There is a need to have a 'master' module which is loaded last and deals with the root object and handling Atk events. My feeling is that AtkUtil needs to be implemented by Atk itself and that it should provide methods for setting the root object and forwarding events. With new toolkits coming along very soon, such as MX, this could be very important for applications with mixed toolkits, where MX or clutter canvases are used within a Gtk application. Hacks are currently present in firefox / moonlight / ca11y to fix the order of a11y module loading.
Perhaps there should be a function something like atk_register_toolkit() that would take a struct (probably a GInterface, since this might help with GObject introspection) with callbacks for registering and unregistering event listeners. How should key event listeners be handled? Should all toolkits be notified when a key event listener is registered, or should there be just one toolkit handling them? Do we even need a callback like we have now for registering a global event listener? Ie, gail's code winds up calling g_signal_add_emission_hook, except for window events so, if window events are handled by atk (bug 638924), then could atk_add_global_event_listener simply call g_signal_add_emission_hook directly? This would mean that there would be no need for an atk_register_toolkit as I described, if key event listeners are handled per-application rather than per-toolkit; the callbacks and the need to modify AtkUtilClass could go away, and there would be functions in atk itself to set the root accessible and callbacks to register and unregister key listeners.
(In reply to comment #1) > Perhaps there should be a function something like atk_register_toolkit() > that would take a struct (probably a GInterface, since this might help > with GObject introspection) with callbacks for registering and > unregistering event listeners. Yes that would be a good idea, probably it is makes sense soomethink like and AtkToolkit interface, and move get_toolkit_name and get_toolkit_version to that object. In the same way, each AtkObject would require to know his own toolkit. This is related to discussions on bug 598952. The next thing would know which is the toolkit providing the root object. Right now most of the mixed environments works having a "root toolkit" and an "embedded toolkit" like firefox. The problem here is that I don't know if in some cases you can create a "tree on embedded toolkits". Ie, in the case of a clutter-gtk mixed environment I don't know if you can have something like this: Root object (A) => gtk object A child (B) => clutter object B child (C) => gtk object > How should key event listeners be handled? Should all toolkits be notified > when a key event listener is registered, or should there be just one toolkit > handling them? This is a good question, but I guess that this would depend on how it is implemented the support for mixed toolkits on the application. Probably it is a per-case solution (requires further investigation). > Do we even need a callback like we have now for registering a global event > listener? Ie, gail's code winds up calling g_signal_add_emission_hook, > except for window events so, if window events are handled by atk (bug 638924), > then could atk_add_global_event_listener simply call g_signal_add_emission_hook > directly? Good point, I just added a comment on that bug. > This would mean that there would be no need for an > atk_register_toolkit as I described, if key event listeners are handled > per-application rather than per-toolkit; the callbacks and the need to modify > AtkUtilClass could go away, and there would be functions in atk itself to set > the root accessible and callbacks to register and unregister key listeners. Hmmm, well this root should be stored somewhere, so I guess that we still would require an object with a specific class storing it. But not sure anyway, probably you are right and AtkUtil could go away.
ATK 2011 Hackfest (partial) conclusion: * It seems to make sense an atk_set_root method * It also makes sense to have an AtkToolkit object. Then any object would be able to return it (toolkit_name and toolkit_version can be moved there) * And also makes sense to move the global_event listener registration to atk * But it seems that would be difficult to remove the problem of the keyevent. * Probably something like allowing keyeventdevices (that emit events) would solve that. * Although the "right thing" solution should be emit all those signals from at-spi2 (that requires xeve) * The main issue is that it needs to be started to be developed in order to find all the issues. * gtk-clutter seems a good testing environment.
[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.