GNOME Bugzilla – Bug 575905
keyboard-a11y plugin should just use gtk dialog for sticky keys and slow keys
Last modified: 2013-01-28 14:15:06 UTC
The keyboard-a11y plugin is in charge of triggering sticky keys and slow keys following specific keyboard inputs. Today, it presents an "are you sure?" dialog using libnotify, with a custom-made dialog used in the absense of a notification daemon. This is flawed: * Dangerous assumptions are made about how the notification daemon behaves. This component assumes the notifier will accept actions and also that it will present bubbles that behave like shapely dialogues, as in the classic notification-daemon. The component falls apart if applied to Ubuntu's notify-osd, or any futuristic ticker-style notification we may see in the mobile space. In any case, choosing libnotify over the software's Completely Adequate dialog box it uses as a fallback is unnecessary. * Common sense dictates that the notification system is for notifications, and it is not our concern how they get presented. "Are you sure? Yes / No" is not a notification; it is a question. * Because the behaviour of a notification bubble makes it difficult to ensure the user will provide feedback, keyboard-a11y's "are you sure" message is not ACTUALLY a "please confirm" type message, since the feature has already been enabled. This is very confusing since the features profoundly changea the feel of the keyboard (which can hurt mouse input, too), making it difficult to actually cancel. Especially difficult if the dialog is missed, which we have to be prepared for. This latter issue occurs with the dialog as well as notification bubble. I suggest that libnotify is no longer used in this component; instead, just use the "fallback" dialog box over which we have full control. The dialog should behave like a real confirmation, not applying the change until the user presses "activate". If this is impossible, I suggest an alternative would be to maintain libnotify, but making this a quiet (and defensively coded) notification as suggested by the notification system, with strings appropriate to that function. Other information: This bug report springs from one filed on launchpad.net, regarding the one issue of actions being sent for notification bubbles. https://bugs.launchpad.net/bugs/342567
Jon?
Summary of discussion with Jon in #usability: The alert box was changed to a notification bubble because the latter was almost guaranteed to appear frontmost (unless another bubble appeared shortly afterward), whereas an alert box usually would be subject to focus stealing prevention and appear in the background. Using notification bubbles makes it necessary to say that the change had happened, rather than asking if it should happen. But even if using an unfocused-by-default alert box, this might still be desirable: if you press Shift five times to activate Sticky Keys, but you then need to type Alt+Tab to focus the alert so that you can confirm the activation, you're stuck in a catch-22. Using notification bubbles works only with the new GDM, because it's displaying a notification area and using notification-daemon. Ubuntu isn't using the new GDM by default because it has been lacking features our customers need (namely graphical configuration and XDMCP). But even when we do switch, Notify OSD doesn't accept actions in notification bubbles, so it will fall back to an unfocused alert box, leaving us with the same catch-22. So using notification bubbles for this is still inappropriate per the Desktop Notifications spec, but it's an open question what to do instead.
Background: http://blogs.gnome.org/mccann/2008/05/19/ease-of-access/
See bug 303136 for one of the problems that happened when it was a dialog
So I think part of the problem here is once the feature is activated we've made the desktop inaccessible for a class of users. We've already failed and we're just trying to make it easier to clean up the pieces from the failure. While making it easy to pick up the pieces is important (since it so drastically changes the way the user interfaces with the desktop), I don't think it's enough. Maybe we should preemptively let the user know that sticky keys/slow keys are about to be turned on. The user has a few seconds (5? 8? i don't remember) where we could give a warning. If we let the user know what's about to happen, then that may give them enough time to pull their finger off the shift key and prevent things from going wrong in the first place. I'm not sure what the best way to warn would be. Maybe the warning should be a notification. Another thought... Right now when we change volume, screen brightness, or monitor layouts we have an on screen display showing those things changing. Maybe it would make sense to have an on screen display for the accessx stuff too? Just some ideas.
*** Bug 601545 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > > Right now when we change volume, screen brightness, or monitor layouts we have > an on screen display showing those things changing. Maybe it would make sense > to have an on screen display for the accessx stuff too? Yes, please! My duplicate bug #601545 mentions a particularly annoying situation where slow keys gets turned on when you shift-drag something for an extended period of time in a drawing program. From what I wrote in that bug: * The confirmation window for a11y features should not be a normal window, because window managers *will* screw it up. It has to be an override-redirect window, always on top. Now I'm thinking that it shouldn't be a notification, either, because it is easy to not see those. * There has to be an indication somewhere when a11y features are enabled. As you wrote, this should have an OSD window to tell you that something happened. * Could slow-keys be *not* enabled when leaving shift held down, if a mouse button is also being pressed? This would at least fix things for drawing programs that have you press down Shift for long periods of time while you mouse around.
*** This bug has been marked as a duplicate of bug 607155 ***