GNOME Bugzilla – Bug 655828
forcing widgets to build accessibles
Last modified: 2013-08-06 16:18:01 UTC
For bug 655047 (making a non-IM GTK module to track focus), we need to be notified every time the currently-focused widget changes. The initial plan was to use atk_add_focus_tracker(), but this doesn't work, because gtk only creates accessibles for widgets when you explicitly ask for them, so none of the entries end up having AtkObjects, so they don't emit atk signals, so atk focus tracking ends up being a no-op. I'm thinking this must be a bug in the gail merging, since a11y tools can't possibly work right unless all widgets automatically have accessibles associated with them, right? But I can see the argument for not creating them if they're not going to be used. Maybe there could be a global flag saying whether to create accessibles automatically or just on-demand, and the at-spi and caribou plugins could set that flag. [Alternatively / if this isn't a bug, right now as a workaround, we are tracking focus by connecting to the set-focus signal of every toplevel GtkWindow, calling gtk_window_get_toplevels() in a timeout to learn about new windows. If there was some way to find out about new windows without needing to poll, then that would also solve our specific problem, by letting us just use plain gtk APIs with no atk at all.]
Sorry, I missed this bug, some additional comments. (In reply to comment #0) > For bug 655047 (making a non-IM GTK module to track focus), we need to be > notified every time the currently-focused widget changes. > > The initial plan was to use atk_add_focus_tracker(), but this doesn't work, > because gtk only creates accessibles for widgets when you explicitly ask for > them, so none of the entries end up having AtkObjects, so they don't emit atk > signals, so atk focus tracking ends up being a no-op. FWIW, it is planned to deprecate atk_add_focus_tracker, so that wouldn't be a good idea either. Take a look to bug 649575 comment 4. In summary we didn't find it useful, and we need to simplify atk focus management. Any comment against/in favour of that decision are welcome. > I'm thinking this must be a bug in the gail merging, since a11y tools can't > possibly work right unless all widgets automatically have accessibles > associated with them, right? But I can see the argument for not creating them > if they're not going to be used. Maybe there could be a global flag saying > whether to create accessibles automatically or just on-demand, and the at-spi > and caribou plugins could set that flag. In the old times, when accessibility is on, the application hierarchy has his accessibility hierarchy created. Not alway a one-to-one relation, but usually yes, being a problem with widgets like gtktreeview. Anyway, I don't see this as just a hypothetical issue with the gail-gtk merge. I had also some issues on other projects (like Unity) if you have a missing children-changed:add signal. And I noticed that problem with t-spi2 that didn't happen with at-spi. In some cases (due other missing pieces) I was forced to temporarily create by hand the accessible objects (then removed that hack when I got all the signals emitted). Probably at-spi was more active searching for the accessible hierarchy, while at-spi2 is more reactive. In relation with that: bug 663732 and bug 663726 > [Alternatively / if this isn't a bug, right now as a workaround, we are > tracking focus by connecting to the set-focus signal of every toplevel > GtkWindow, calling gtk_window_get_toplevels() in a timeout to learn about new > windows. If there was some way to find out about new windows without needing to > poll, then that would also solve our specific problem, by letting us just use > plain gtk APIs with no atk at all.] Other workaround/hack could be add a emission hook, something like: signal_id = g_signal_lookup ("focus-in-event", GTK_TYPE_WIDGET); g_signal_add_emission_hook (signal_id, ....)
(In reply to comment #1) > FWIW, it is planned to deprecate atk_add_focus_tracker, so that wouldn't be a > good idea either. Take a look to bug 649575 comment 4. In summary we didn't > find it useful, and we need to simplify atk focus management. Any comment > against/in favour of that decision are welcome. Yes, it seems that atk_add_global_event_listener() and the method to be added by bug 651368 could be used instead, but they would still have the same problem; that the atk signals would not actually be getting emitted if the AtkObjects don't get created. > In relation with that: bug 663732 and bug 663726 I think those are basically dups of this. > > [Alternatively / if this isn't a bug, right now as a workaround, we are > > tracking focus by connecting to the set-focus signal of every toplevel > > GtkWindow, calling gtk_window_get_toplevels() in a timeout to learn about new > > windows. Actually we eventually got rid of the timeout by using a gdk event filter to notice when new toplevel windows appeared. But it's still kludgy. > Other workaround/hack could be add a emission hook, something like: > > signal_id = g_signal_lookup ("focus-in-event", GTK_TYPE_WIDGET); > g_signal_add_emission_hook (signal_id, ....) yeah, that would work too... probably simpler than the current code
With the change to accessibility always this bug became obsolete (or should, re-open it if I'm wrong). Somewhat offtopic, but FWIW, as the bug was created in relation with Caribou, we were talking about that at GUADEC 2013. Now if any clients start to listen at-spi events, accessibility objects should be already there, and the events should be properly emitted. So, although in the short term the plan is keeping using the current "non atspi mode", in the long term the idea would be caribou reuse the tracker being implemented for the magnifier tracking feature, and not needed a special gtk module to track focus changes. That would mean that the keyboard would appear for any application/toolkit that supports at-spi.