Sticky Keys and Slow Keys popups ignore notification daemon capabilities

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

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

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.

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

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.

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)

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.

Spec updated.

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

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

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

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

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.

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?

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

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

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.

no debdiff to sponsor, unsubscribing ubuntu-sponsors

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

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