GNOME Bugzilla – Bug 607155
Sticky Keys and Slow Keys popups ignore notification daemon capabilities
Last modified: 2013-01-28 14:15:06 UTC
When keyboard accessibility features are turned on, gnome-settings-daemon watches for the user pressing Ctrl multiple times or holding down Shift for 8 seconds. When this happens, it presents a notification bubble asking the user if he wishes to activate the corresponding feature (Sticky Keys and Slow Keys). Ubuntu's notify-osd (and potentially other downstream notification daemons) cannot handle actions. (At least, in its case it produces a dialog box with the distinct aura of not wanting to be there). In any notification system without that kind of fallback, it would be impossible to know when sticky or slow keys are enabled since the system blindly relies on an action button being pressed. Specifically, this problem lies in gnome-settings-daemon/plugins/a11y-keyboard, with ax_slowkeys_warning_post and ax_stickykeys_warning_post. The plugin should instead use custom alert boxes in this case.
Created attachment 151546 [details] [review] Falls back to custom dialog box when notification bubble actions are unavailable This was originally filed downstream: https://bugs.edge.launchpad.net/gnome-settings-daemon/+bug/342567 Filing it (verbatim) up here. I created this patch. It's a bit old and not extensively tested, but _should_ do it. At any rate, it'll get things going, hopefully.
Review of attachment 151546 [details] [review]: The patch needs a little tidying. Some style issues (missing spaces, or too many spaces) and the following: ::: plugins/a11y-keyboard/gsd-a11y-keyboard-manager.c @@ +522,3 @@ + gboolean accepts_actions = FALSE; + + if(notify_caps != NULL) { The check for the action capability should be pulled out into a separate function. @@ +523,3 @@ + + if(notify_caps != NULL) { + GList *c = NULL; Unnecessary initialisation @@ +524,3 @@ + if(notify_caps != NULL) { + GList *c = NULL; + for(c = notify_caps; c != NULL; c = c->next) { Better to use g_list_next right away here. We'll have to do so for 3.0, anyway. @@ +536,3 @@ + + if ( accepts_actions == FALSE ) return FALSE; + No variable declarations in the middle of a block.
Comment on attachment 151546 [details] [review] Falls back to custom dialog box when notification bubble actions are unavailable Marking as obsolete as the patch won't apply to master.
The way that I would implement this is: - in libnotify, when the server capabilities are queried, check whether the server supports actions. - if it does not, tell the client that it does anyway, and create a GTK+ dialog for yourself as an implementation detail Or, probably cleaner: - When actions are added on an notification, make notify-osd popup a dialog. Anyway, filed this bug: https://bugs.launchpad.net/notify-osd/+bug/1107919
*** Bug 575905 has been marked as a duplicate of this bug. ***