Hide or deemphasize shortcut keys in menus

Bug #493762 reported by Rich Jones
38
This bug affects 5 people
Affects Status Importance Assigned to Milestone
GTK+
Expired
Wishlist
One Hundred Papercuts
Fix Released
Low
Kenneth Wimer
light-themes
Fix Released
Undecided
Unassigned
gtk2-engines-murrine (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

This is a continuation of a discussion from: https://bugs.edge.launchpad.net/hundredpapercuts/+bug/403691

Why not hide the Control+Commands on drop down menus in the same way? That would reduce a hell of a lot of visual noise for something that - let's be honest here - is rarely used.

Example:

Before (boo, noisy!):
http://imgur.com/wpAR4l.png

After (a breath of fresh air!):
http://imgur.com/cOy1nl.jpg

(Sorry about the icons - screenshot was taken on 8.04)

If bug #403691, it would be nice if they could coincide so that pressing alt would uncover all the shortcuts.

The one issue to deal with would be the width - would it get wider as the shortcut appeared, or would it be that width normally, with the accelerator simply becoming visible when the key is pressed. I think I'd prefer the later, but would be interested in what others have to say.

Revision history for this message
David Siegel (djsiegel-deactivatedaccount) wrote : Re: Hide shortcut keys in menus

At first I was like "say what?!" then I saw your mockups and I have to say they are so refreshing! It's so much easier to look for something in the menu when the keyboard shortcuts are not shown.

Clearly, we cannot simply hide keyboard shortcuts all of the time because many people use keyboard shortcuts and enjoy learning new ones. Maybe we can only show the keyboard shortcut for the highlighted menu entry? Would be worth testing.

summary: - Hide Accelertor/Shortcuts in Menus
+ Hide shortcut keys in menus
Revision history for this message
Dilomo (ankere) wrote :

This proposal is not good imo.

I only Igree if we hide the shortcuts we all know of Ctrl+S, Ctrl+P, Ctrl+O, Ctrl+F ans so on but the others should remain becuase if you use an application often you don't bother to open menus at all.

Another possible way would be to have an option that shows them and hides them on demand. maybe the best for both side users.

Revision history for this message
Michael Rooney (mrooney) wrote :

I agree with David, I think in the general case it will be a lot cleaner and easier on the eyes.

As long as the underlines are shown when pressing alt, and the shortcuts are shown when hovering the item, I don't think any discoverability is lost.

Revision history for this message
Rich Jones (richwjones) wrote :

DS - Thanks for looking into this bug! I proposed it upstream, and the main concern was over 'keyboard only users'. Now, I don't know any keyboard-only users, but I suppose they must be considered. I think the idea of only showing them when there is highlighting is a great idea and would love to try that out. What component actually codes for that - is that in GTK?

Dilomo - that is what I was proposing, not that we remove them entirely, simply that we make them discoverable.

Revision history for this message
Vish (vish) wrote :

One issue in Rich Jones' mockup is that gtk currently does not work that way.
If the shortcuts are not displayed the menu will become thinner/narrower. Check out the session menu.

The fix is in no way a simple/easy one.

Changed in hundredpapercuts:
status: New → Invalid
Revision history for this message
Vish (vish) wrote :

The upstream bug report is for this issue , and the suggestion was to make the shortcuts lighter.

Revision history for this message
Dylan McCall (dylanmccall) wrote :

Fun trivia: Maemo (used on Nokia N810, N900, etc) hides shortcut text when the keyboard is closed, shows it when the keyboard is open.
Windows does similar stuff with the mnemonics (which are indicated by underlines): they are only shown when Alt is being pressed, then some newer applications produce more colourful and obvious overlays (indicating all the shortcuts) to make it easier to interact that way.

I don't think we can do all that here, but I have an alternative suggestion: use Pango markup to italicize, grey out or shrink that shortcut text. Gets it out of the way, emphasizes that the shortcuts are _alternatives_, but doesn't harm any existing functionality.

Revision history for this message
Rich Jones (richwjones) wrote :

That's at least a step in the right direction!

From upstream:
http://bugzilla-attachments.gnome.org/attachment.cgi?id=149582

Much nicer, themeable, customizable (haters like me would be able to make them invisible with theming :) )

description: updated
Changed in gtk+2.0 (Ubuntu):
status: New → Triaged
importance: Undecided → Wishlist
assignee: nobody → Ubuntu Desktop Bugs (desktop-bugs)
Revision history for this message
Dylan McCall (dylanmccall) wrote :

Following upstream's assessment of this (in gnome bug 604315), I am adding human-gtk-theme to the bug report. It is possible to style the GtkAccelLabel to achieve the desired effect. Here is Moblin doing it: http://bugzilla-attachments.gnome.org/attachment.cgi?id=151627

May be worth discussing on the ubuntu-art mailing list. May be worth implementing the adjustment in a non-default theme (in the community-themes package) in order to test the waters and get the ball rolling :)

Revision history for this message
David Siegel (djsiegel-deactivatedaccount) wrote :

Assigning Ken on the paper cut task just so he can take a look.

summary: - Hide shortcut keys in menus
+ Hide or deemphasize shortcut keys in menus
Changed in hundredpapercuts:
status: Invalid → Confirmed
assignee: nobody → Kenneth Wimer (kwwii)
Changed in gtk:
status: Unknown → Invalid
Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is fixed in lucid

Changed in gtk+2.0 (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Vish (vish) wrote :

Actually the fix released was for Bug #403691 , which has been fixed in gtk.

This bug was closed upstream by the reporter since the gtk devs didnt like the idea , instead the idea was implemented in clearlooks and mobilin engines.

Changed in gtk+2.0 (Ubuntu):
status: Fix Released → Invalid
Revision history for this message
Vish (vish) wrote :

This has now been fixed. Not really sure where though! My best guess is in the murrine engine.
If anyone else knows where , re-assign as appropriate.

affects: human-gtk-theme → light-themes
Changed in light-themes:
status: New → Fix Released
Changed in hundredpapercuts:
importance: Undecided → Low
status: Confirmed → Fix Released
Revision history for this message
neuromancer (neuromancer) wrote :

I still see shortcut in all menu (firefox, gedit, nautilus etc.)
Lucid Linx 10.4, ambiance theme (but same with radiance and other themes)
Where I'm wrong??

Revision history for this message
Jacopo Moronato (jmoronat) wrote :

Same as neuromancer here.

Revision history for this message
Vish (vish) wrote :

The screenshot is from running murrine version: 0.90.3+git20100601-0lucid1 .

Revision history for this message
Jacopo Moronato (jmoronat) wrote :

Both Lucid and Maverick have a less recent version of Murrine: https://launchpad.net/ubuntu/+source/gtk2-engines-murrine

Revision history for this message
Vish (vish) wrote :

Hmm , right thats the murrine update!
Just think of it as a sneak peak of the Maverick theme! :D

We need the latest murrine for this fix.

affects: gtk+2.0 (Ubuntu) → gtk2-engines-murrine (Ubuntu)
Changed in gtk2-engines-murrine (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
importance: Wishlist → Low
status: Invalid → Fix Committed
Changed in hundredpapercuts:
status: Fix Released → Fix Committed
Changed in light-themes:
status: Fix Released → Fix Committed
Revision history for this message
Vish (vish) wrote :

This was fixed in maverick :

gtk2-engines-murrine (0.90.3+git20100810-0ubuntu1) maverick; urgency=low

  * New git snapshot

 -- Sebastien Bacher <email address hidden> Tue, 10 Aug 2010 18:24:15 +0200

Changed in gtk2-engines-murrine (Ubuntu):
status: Fix Committed → Fix Released
Changed in light-themes:
status: Fix Committed → Fix Released
Changed in hundredpapercuts:
status: Fix Committed → Fix Released
Changed in gtk:
importance: Unknown → Wishlist
status: Invalid → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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