Sticky Keys and Slow Keys popups ignore notification daemon capabilities

Bug #342567 reported by Dylan McCall on 2009-03-13
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNOME Settings Daemon
Won't Fix
Medium
One Hundred Papercuts
Low
Unassigned
gnome-settings-daemon (Ubuntu)
Low
Unassigned
Lucid
Low
Unassigned

Bug Description

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).

Jaunty's new notify-osd falls back to popping up a dialog box. (One with the distinct aura of not wanting to be there). In any notification system without that kind of fallback, it would be impossible to enable sticky or slow keys 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. Mockups at <https://wiki.ubuntu.com/NotifyOSD#keyboard-accessibility>

I am posting this first to Launchpad instead of upstream, because I think Ubuntu at the moment is more committed to the issue.

Sebastien Bacher (seb128) wrote :

thank you for your bug report, I'm not sure that the design team listed this action use

Changed in gnome-settings-daemon:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Confirmed
Dylan McCall (dylanmccall) wrote :

Two patches for you!

This one is immediately functional. It checks if the notification server supports actions and falls back to its own system in that case. No need for string changes. (Although something tells me this case has not been thoroughly tested: there are no icons on action buttons, the dialog can disappear behind windows really easily and "don't deactivate vs. deactivate is really confusing at a glance. Not a good thing when the functionality engages automatically and expects the user to /deactivate/ it if he doesn't want it).

Dylan McCall (dylanmccall) wrote :

This second patch needs custom strings, documentation, translation work and the like. With some work it could behave quite smoothly.

In this case, actions are simply stripped from the notifications so we still get notification bubbles, but to deactivate (or activate) the functionality the user must press the same keys again. Personally, I find it works better than the dialog since by the time the dialog displays, sticky / slow keys is activated. That can make things quite confusing for a user if he is trying to click the Deactivate button after having pressed, for example, Alt. (Besides, why have a confirmation dialog when it has already happened?).
Right now the title text still reads like a confirmation dialog, which could be a tad confusing. In theory, it could just be stripped and we use the main text as the only text in the notificaiton.

Dylan McCall (dylanmccall) wrote :

Eeek! Sorry about the mess. I left behind another completely different change I was working on in the older patches.

Matthew Paul Thomas (mpt) wrote :

I can reproduce the Slow Keys alert, but not the Sticky Keys one.

Is there any reason for not using a confirmation alert here? I take the point that the change has already happened by the time the alert appears, but the same is true for the confirmation alert you get when changing screen resolution.

Matthew Paul Thomas (mpt) wrote :
Matthew Paul Thomas (mpt) wrote :
Dylan McCall (dylanmccall) wrote :

MANY issues with notify-osd's alert in this case, compared to Slow Keys' own:

* It is hard to read. The window title gnome-settings-daemon does not help the user.
* Cancel and Okay are redundant in this case with Deactivate and Activate. (Are they ever not?!)
* May be just me, but something about the way the keyboard-a11y plugin and notify-osd interacts seems to cause the plugin to love crashing during this operation. (I'm sure it didn't before).

You're right, something is odd about activating sticky keys lately. I'm having trouble doing it, too. But rest assured, it's as ugly as the Slow Keys alert if not uglier. (Note even the little shadow gnome-screenshot threw in saves it :P)

Matthew Paul Thomas (mpt) wrote :

Sure, I didn't mean to say that Notify OSD's fallback alert is okay. What I meant was, is there any reason someone using notification-daemon would prefer a notification bubble with buttons instead of a custom-designed alert box? If not, we don't need to make the code conditional on whether the notification server accepts actions; we can just use an alert box regardless.

Thanks for the screenshots.

Matthew Paul Thomas (mpt) wrote :

Spec updated.

description: updated
Changed in gnome-settings-daemon:
status: Unknown → New
Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Triaged
Dylan McCall (dylanmccall) wrote :

I agree, it would be good to have the libnotify popup absolutely removed for eternity. I filed a bug report for that. It's a slightly different request (a new feature, not so modest a change), but it would permanently fix this so it makes some sense to tie it to this one.

I think we should avoid making a tremendous change downstream, like tearing out the libnotify popup altogether, during feature freeze and all that. It could greatly upset somebody (or some spin-off distro) who for some reason still likes notification-daemon or whose use case we didn't think of in the short time up to release. For the time being, we may as well preserve the existing functionality just in case and touch up usability with the next release :)

Having said that, patching this to remove the libnotify stuff would be fairly quick.

Unfortunately I'm at the wrong computer to create a patch, but...
In gsd-a11y-keyboard-manager.c, for stickykeys look at line 799: if (! ax_stickykeys_warning_post_bubble (manager, enabled)) {
For slowkeys look at line 652: if (! ax_slowkeys_warning_post_bubble (manager, enabled)) {

The solution should be evident :) (Remove the if blocks and any mention of ax_*_warning_post_bubble. Look for #ifdef HAVE_LIBNOTIFY and delete everything in those blocks).

Vish (vish) wrote :

We need to make sure atleast apps in the default install are notify-osd friendly.

Changed in hundredpapercuts:
importance: Undecided → Low
milestone: none → lucid-round-10
status: New → Triaged
Vish (vish) wrote :

Dylan , why aernt the sponsors subscribed? Does the patch need an update?

Dylan McCall (dylanmccall) wrote :

Filed a new upstream bug report on this particular issue (instead of a related one :/). I'm changing the remote watch to fit.

Changed in gnome-settings-daemon:
status: New → Unknown
Dylan McCall (dylanmccall) wrote :

As per MPT's comments, this was also discussed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=575905
Came to the conclusion that the alert dialog is, in fact, an intentional change for a good reason (although, personally, I think it would be better if Metacity was patched or new infrastructure introduced instead of introducing a workaround and letting the problem stagnate).

Patch #1 should be good to go, though :)
Subscribing main sponsors.

Changed in hundredpapercuts:
milestone: lucid-round-10 → none
Luca Ferretti (elle.uca) wrote :

Any news about this. Could be really good fix it for Lucid, at least remove OK/Cancel buttons.

An additional note. I'm not sure, but sometimes it seems to me that the confirmation dialog opens unfocused, I've to click it in order to interact. This seems bad to me, 'cause probably people that needs Sticky/Slow/* Keys feature couldn't use the mouse. Can someone confirm this?

Sebastien Bacher (seb128) wrote :

upstream had some concerns about the code changes which have not been addressed yet, but otherwise would be good to have for lucid indeed

Sebastien Bacher (seb128) wrote :

Travis, could you have a look to this issue too?

Changed in gnome-settings-daemon (Ubuntu Lucid):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → Travis B. Hartwell (nafai)
Dylan McCall (dylanmccall) wrote :

Eek! That jogged my memory :)

The fallback patch was discussed in upstream Bugzilla, at https://bugzilla.gnome.org/show_bug.cgi?id=607155 . Jens pointed out that it needs some tidying, then I managed to forget all about it.

As was also discussed, the dialog box is slightly tricky (and terrifying) to navigate to revert the change if one isn't used to sticky or slow keys mode. Especially sticky keys, since one may get the Alt key stuck and not understand why he can't press any buttons (or do ANYTHING except drag the window). Some trickery could resolve this, for example cloning the gksu dialog. It performs a mouse grab, most importantly.
Even the old dialog is better than what we get right now, though.

Vish (vish) on 2010-06-11
Changed in hundredpapercuts:
milestone: none → maverick-round-8-potpourri
Benjamin Drung (bdrung) wrote :

no debdiff to sponsor, unsubscribing ubuntu-sponsors

Vish (vish) wrote :

@Dylan McCall , Are you working on updating the patch as per upstream comments?

Changed in gnome-settings-daemon (Ubuntu Lucid):
assignee: Travis B. Hartwell (nafai) → nobody
Changed in gnome-settings-daemon (Ubuntu):
assignee: Travis B. Hartwell (nafai) → nobody
Changed in gnome-settings-daemon:
importance: Unknown → Medium
status: Unknown → New
Vish (vish) on 2010-12-16
Changed in hundredpapercuts:
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Changed in gnome-settings-daemon:
status: New → Won't Fix
Changed in hundredpapercuts:
assignee: Papercuts Ninjas (papercuts-ninja) → nobody
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in gnome-settings-daemon (Ubuntu Lucid):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.