When the user right-clicks a cell in Calc, a context menu appears.
Please add text to this menu to show the applicable keyboard shortcuts (e.g., "Ctrl+C" for Copy in an English locale), just as in the submenus of the main menubar.
I'm using LibreOffice 184.108.40.206 on Ubuntu 13.04.
thanks for using LibreOffice and trying to get the most out of it!
For me in (almost?) any case, Shft+F10 does give the context menu.
Anyway on Ubuntu & LibreOffice.
Thanks for looking at this bug. My request isn't about how to open the context menu, but about what text is displayed on the context menu.
If there is already a keyboard shortcut available for a certain function / feature, and such function / feature is seen in the cell's context menu in Calc, then what would be the reason to have such specific function / feature in the context menu in the first place?
Ady, I'm not sure I understand your comment. For instance:
There is a keyboard shortcut (Ctrl+C) available for a certain function (Copy [to Clipboard]). Such function (Copy) is seen in the cell's context menu in Calc. Your question in this instance would then be, "What would be the reason to have Copy in the context menu in the first place?"
Copy is an established entry in the context menu, so you clearly aren't proposing that there is no reason to have Copy in the context menu.
Is your question a rhetorical one, saying that the reason to have the function in the context menu is for quick access to that function, and the context menu satisfies this reason completely, so that there's no need for a keyboard shortcut to be shown also?
I would be glad if you could clarify this.
KeePassX, simple-scan, system-config-printer, Inkscape, FreeCAD, Scribus, BlueGriffon show keyboard shortcuts in context menus. Thunderbird shows a few (in the Tag submenu when the user right-clicks a message in the message list).
Many applications explicitly expose their keyboard shortcuts to “everything”, including in their context menus. Such exposure helps users in their learning curve.
A spreadsheet application has many features / functions; so many, that the decision to add a certain function (and not to add another one in its place) to the context menu (or an icon to the default bar) is not so trivial.
With so many functions needed for such variety of usage/users, I would tend to think that when one method of “easy-access” is already available for one specific function, it would be desirable to let *other* functions take advantage of other kinds of “easy-access” (as opposed to repeat the same function again and again in each and every alternative method of “easy-access”).
More importantly, for every enhancement there is also a “price” (or more than one).
In this case, for every time the context menu is used, the relevant functions are brought up. How much additional resources (time, CPU cycles, RAM, screen space...) would be needed if the keyboard shortcuts would be also displayed?
Additionally, is this request so much important than others, that it deserves the valuable time of LO developers? This is an important “price” to be evaluated, specially having bug reports waiting for so much time to be resolved.
The fact that the (many) keyboard shortcuts are already available to the user by other means (in menus, help file, guides, wiki), is relevant so to decide whether the request is worth its development “price”.
In this case, I just posted my perspective, so the developers can consider it. I have not changed the status of this report in any way, and I leave the evaluation to the developers.
(In reply to comment #5)
> Many applications explicitly expose their keyboard shortcuts to
> “everything”, including in their context menus. Such exposure helps users in
> their learning curve.
Helping users in their learning curve is valuable to the LibreOffice project, which has limited ability to train users individually and has to make complex software usable by people who are minimally computer-literate.
People who have difficulty using the mouse (I've seen such people who are generally not "disabled" or "impaired" except that they normally use a laptop and have trouble with its touchpad) will tend to use the right-click context menu a lot more than going to the main menu and choosing "Edit." These people would benefit from having keyboard shortcuts brought to their attention in the context menu.
> is this request so much [more] important than others, that it
> deserves the valuable time of LO developers?
I submitted a number of enhancement requests without realizing that I should set the severity to "enhancement." This has been fixed with this bug, and the updated severity should take care of Ady's concern here.
still a valid (..) request
Thanks for updating this bug jphilipz. This is of course not limited to calc and a valid request for writer etc as well.
That's a one-line fix thanks to the work made in Bug 93837 (since now main menus and context menus share the same code). I disabled it intentionally, because I was under impression that it was by design to not show shortcuts in context menus.
@Maxim: From what i can see, the showing of keyboard shortcuts in context menus is OS and application specific.
On Windows and Linux KDE, LO's find toolbar field and the about dialog have context menus with shortcuts, while on Linux Gnome and OS X these controls dont.
When it comes to cross-platform browsers, Firefox doesnt show shortcuts on Windows or Linux, while Chrome/Chromium show shortcuts on Windows and Linux.
When it comes to office apps on Windows, MS Word, WordPerfect, and Excel dont show shortcuts, while Calligra Words, WPS/Kingsoft Writer and Quattro Pro show shortcuts.
So this functionality should be turned on (Windows) or off (Linux and Mac) automatically based on the OS default and the user should have the ability to overwrite this automatic behaviour, similar to Tools > Options > View > Menu > Icons in menus.
Well, Word on OS X has keyboard shortcuts when using the menubar. That's also the case for the right-click menu.
(In reply to Yousuf (Jay) Philips from comment #10)
> On Windows and Linux KDE, LO's find toolbar field and the about dialog have
> context menus with shortcuts, while on Linux Gnome and OS X these controls
Good finding. Turns out that we already have internal setting in vcl for that, which is set to true for Windows/KDE/generic and false for OS X/gtk2-3. So we need to honor it for other context menus too.
> So this functionality should be turned on (Windows) or off (Linux and Mac)
> automatically based on the OS default
For OS X it's clear that we shouldn't show shortcuts by default, as that's what Apple recommends in its HIG  - although some apps ignore it - like Qt Creator or Word.
But for Linux there are many apps that show shortcuts - see comment 4 (and I can add Qt Creator and Nautilus 3.20 to that list, so I'm not sure what should be the default there.
Created attachment 123968 [details]
iTunes screenshot, menubar has shortbuts all over
iTunes screenshot, menubar has shortbuts all over
Maxim, are you sure? Adding a screenshot from the iTunes menubar. It has shortcuts listed all over the place as does the right-click menu. So is Apple violating it's on HIG?
(In reply to steve -_- from comment #15)
> Maxim, are you sure?
Well, you don't have to trust me. I gave the link, and you can read yourself.
> Adding a screenshot from the iTunes menubar. It has shortcuts listed all over
> the place
Right. Apple's HIG is talking _only_ about right click menus.
> as does the right-click menu.
That's odd. iTunes under OS X indeed shows _some_ shortcuts - like for "New Playlist from Selection", but doesn't show other shortcuts e.g. "Copy".
> So is Apple violating it's on HIG?
Why is this so surprising?
Regarding gtk3: I tested some other apps - Gnote, EOG, Evince, Epiphany, System Monitor, and they all have shortcuts in context menus, so Nautilus isn't alone. On the other hand Gedit, FileRoller and Evolution don't. Still it seems that having shortcuts is more common nowadays in gtk3.
Right, basically Apple doing whatever they wanna do. I am not sure if we should waste too many brain cycles on which policy to follow, since obviously, there is no clear direction.
It would be interesting to learn, which OSX shortcuts they use and which they don't use. I would assume that copy, paste, delete are so basic, that they decided, showing the shortcuts would just be cluttering the view and I agree. So we'd have to discuss, which shortcuts to include for OS X right click menu in a design meetup, no? Having some would sure be useful.
Not to muddy the water, but by short-cut are we referring just to keyboard shortcuts--or also including keyboard accelerators?
To my mind, shortcuts show as the additional key'd options established in vcl on menus, e.g. Ctrl+O, Ctrl+S, Ctrl+P on the File menu--whereas accelerators are the underlined single letter "mnemonic" to reach the menu entry.
As OP requests, shortcuts are not rendered onto the context menu, but accelerators are (as controlled by OS, i.e. with <Alt> key press on Linux).
Personally I'd prefer to always display the shortcuts in addition to the accelerators on the context menus.
But, we need to be mindful of the requirements for Assistive Technology support where both the accelerator and the shortcut need to be exposed. If that means linkage of the toggle to Tools -> Accessibility: Miscellaneous Options checkbox "Support assistive technology tools (program restart required)" to always enable them, we should.
a brief look at finder or mail.app (osx only - itunes is win also) show no keyboard shortcuts for the context menu.
no accelerators on OSX (just FYI)
(In reply to Maxim Monastirsky from comment #12)
> But for Linux there are many apps that show shortcuts - see comment 4 (and I
> can add Qt Creator and Nautilus 3.20 to that list, so I'm not sure what
> should be the default there.
As Qt Creator is a Qt/KDE app, i would expect it to have shortcut keys, as i had mentioned previously that Linux KDE showed shortcuts in the find toolbar field. The KDE HIG states, "Assign shortcut keys to the most frequently used menu items (Ctrl+<Key>)".
When it comes to Gtk/Gnome apps, the majority of apps that i've tried dont have shortcuts - file managers (files [unity], nemo [cinammon], thunar [xfce], caja [mate], pcmanfm [lxde]), text editors (gedit, pluma, mousepad, leafpad), office apps (abiword, gnumeric), image viewers (gThumb, EoG 3.10 [non-CSD version], Eye of Mate), others (calculator, galculator, xpad, atril). The ones i found with shortcuts are CSD (client-side decoration) apps like gpicview, gnome-mplayer, EoG 3.18, evince, rhythmbox, and archive manager.
We should ideally mimic the behaviour found in the find toolbar field, as i assume the context menu generated there is from the OS-level and not from the app-level. But similar to other cross-platfrom apps (Word, iTunes, Chrome), we can unilaterally decide that we want shortcuts to appear in the context menu and that is also fine (ideally with the option to change this in the options dialog).
(In reply to V Stuart Foote from comment #19)
> Not to muddy the water, but by short-cut are we referring just to keyboard
> shortcuts--or also including keyboard accelerators?
Yes this bug is only talking about the keyboard shortcuts and not the accelerators.
(In reply to Yousuf (Jay) Philips from comment #22)
> As Qt Creator is a Qt/KDE app, i would expect it to have shortcut keys,
Yes, you right (although pure-Qt apps as Qt Creator don't necessarily follow KDE HIG).
> When it comes to Gtk/Gnome apps, the majority of apps that i've tried dont
> have shortcuts
We should be very careful here, as we shouldn't compare gtk2 with gtk3 apps - esp. GNOME official apps, and esp. their latest versions (3.18-3.20). In LO we have separate gtk2/gtk3 backends, and we can take different routes for each one. For gtk3 I believe we should follow the latest upstream UI trends, even if some other apps still don't follow them.
> - file managers (files [unity]
Indeed. Ubuntu stuck with an ancient (and probably heavily patched) version of it.
> We should ideally mimic the behaviour found in the find toolbar field, as i
> assume the context menu generated there is from the OS-level and not from
> the app-level.
That's not the case, as I mentioned already in comment 12. That's our own menu, and *we* take the decision there based on the platform.
> But similar to other cross-platfrom apps (Word, iTunes,
> Chrome), we can unilaterally decide that we want shortcuts to appear in the
> context menu and that is also fine (ideally with the option to change this
> in the options dialog).
Note that Chrome under OS X doesn't show shortcuts. So it's a cross-platform app, but still following the UI of each platform.
An attempt to implement this is here:
Maxim Monastirsky committed a patch related to this issue.
It has been pushed to "master":
tdf#74377 Keyboard shortcuts for context menus
It will be available in 5.3.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
nice new feature. thanks Maxim