Bug Hunting Session
Bug 115052 - Allow other keys than from US keyboard as shortcut keys
Summary: Allow other keys than from US keyboard as shortcut keys
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.4.2 release
Hardware: All All
: high enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 115361 117555 (view as bug list)
Depends on:
Blocks: Shortcuts-Locale
  Show dependency treegraph
 
Reported: 2018-01-16 20:01 UTC by Thomas Lendo
Modified: 2019-03-04 09:38 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Keyboard assignment on LXQt (51.74 KB, image/png)
2018-01-17 08:38 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Lendo 2018-01-16 20:01:57 UTC
Allow other keys than from US keyboard so that they are available in the Customize dialog for other languages.

To not confuse other users, specific keys should be only visible for specific LibO UI languages. 

For example I would prefer Ctrl+# as German shortcut keys instead of Ctrl+' because the apostrophe (') is only available when using Shift+# which makes all English shortcuts with ' useless with a German keyboard. Other languages have similar problems. Because the shortcut key list is limited to English keys, the keyboard of other languages couldn't take advantage of their specific keys. This minimizes the variety of possible shortcut keys.

(This bug was thought up in bug 82117.)
Comment 1 Yousuf Philips (jay) (retired) 2018-01-16 20:40:54 UTC
The correct solution in my view is to fix the shortcuts per locale so that it works best for their keyboards and not hide keys in different locales as they are less likely to be used but still accessible with the locale keyboard, as that just complicates things more.

For example, we list complicated shortcuts that begin with Ctrl + Alt and Ctrl + Shift + Alt, with pretty much all of them being unassigned, but hiding them from users as they arent likely going to use them is bad as some users may like to assign them.

So WontFix for me. @Heiko, Stuart: thoughts.
Comment 2 Thomas Lendo 2018-01-16 21:33:25 UTC
(In reply to Yousuf Philips (jay) from comment #1)
> The correct solution in my view is to fix the shortcuts per locale so that
> it works best for their keyboards ...
The locale shortcut fix is one step but isn't perfectly usable now because of the very limited range of available (US English) keys. Many keys of non-US English keyboard layouts cannot be used today--but these keys would be easier for non-US English locale users to use and would avoid dislocate their fingers to use them ;-).

> and not hide keys in different locales as
> they are less likely to be used but still accessible with the locale
> keyboard, as that just complicates things more.
> 
> For example, we list complicated shortcuts that begin with Ctrl + Alt and
> Ctrl + Shift + Alt, with pretty much all of them being unassigned, but
> hiding them from users as they arent likely going to use them is bad as some
> users may like to assign them.
Haven't said anything about hiding shortcut that are less used. I meant that a shortcut like Ctrl+# is possible with a German keyboard layout but not with an US English keyboard layout - so Ctrl+# shouldn't or need not to be available for US English locale. The same is valid vice versa: Ctrl+; isn't possible with a German keyboard layout (as US English ';' key is 'ö' in German) so this can be hidden there, but must be shown for US English keyboard layout.

Compare https://upload.wikimedia.org/wikipedia/commons/5/51/KB_United_States-NoAltGr.svg and https://upload.wikimedia.org/wikipedia/commons/3/36/KB_Germany.svg for example or use one of the many other keyboard layouts (https://en.wikipedia.org/wiki/Keyboard_layout).
Comment 3 Heiko Tietze 2018-01-17 08:38:00 UTC
Created attachment 139139 [details]
Keyboard assignment on LXQt

Would drop the whole concept of predefined keys and just allow anything what comes from the keyboard. That also means the keyboard tab needs a complete revamp. Something like KDE has or in the attached example from LXQt (after clicking the shortcut button you have 10s to press any key combination).

The shortcut list is populated with values in https://opengrok.libreoffice.org/xref/core/cui/source/customize/acccfg.cxx where KEY_F1, for instance, is defined in https://opengrok.libreoffice.org/xref/core/include/vcl/keycodes.hxx - and those constants are used all over the program. So I doubt that we can clean it up.

Thomas' suggestion may improve the functionality slightly but it's still an ugly implementation and a totally weird UI. Adding Muhammet for his opinion.
Comment 4 Yousuf Philips (jay) (retired) 2018-01-17 20:16:57 UTC
(In reply to Thomas Lendo from comment #2)
> The locale shortcut fix is one step but isn't perfectly usable now because
> of the very limited range of available (US English) keys. Many keys of
> non-US English keyboard layouts cannot be used today--but these keys would
> be easier for non-US English locale users to use and would avoid dislocate
> their fingers to use them ;-).

Then likely an enhancement report should be filed to include non-US characters into the list, though not sure these are possible to detect by the code.

> Haven't said anything about hiding shortcut that are less used. I meant that
> a shortcut like Ctrl+# is possible with a German keyboard layout but not
> with an US English keyboard layout - so Ctrl+# shouldn't or need not to be
> available for US English locale.

Ctrl+# is available on the english locale with Ctrl+Shift+3.

> The same is valid vice versa: Ctrl+; isn't
> possible with a German keyboard layout (as US English ';' key is 'ö' in
> German) so this can be hidden there, but must be shown for US English
> keyboard layout.

I can see ';' in the same ',' key in the german keyboard image you linked to.

(In reply to Heiko Tietze from comment #3)
> Would drop the whole concept of predefined keys and just allow anything what
> comes from the keyboard. That also means the keyboard tab needs a complete
> revamp. Something like KDE has or in the attached example from LXQt (after
> clicking the shortcut button you have 10s to press any key combination).

I've found KDE's keyboard implementation way to complicated.

> Thomas' suggestion may improve the functionality slightly but it's still an
> ugly implementation and a totally weird UI. Adding Muhammet for his opinion.

You forgot to CC him.
Comment 5 Thomas Lendo 2018-01-22 15:56:15 UTC
(In reply to Yousuf Philips (jay) from comment #4)
> (In reply to Thomas Lendo from comment #2)
> > The locale shortcut fix is one step but isn't perfectly usable now because
> > of the very limited range of available (US English) keys. Many keys of
> > non-US English keyboard layouts cannot be used today
> Then likely an enhancement report should be filed to include non-US
> characters into the list
This can be answered in this enhancement request and that's what this bug is for. Pre-defined enhanced shortcut key list or auto-detected by locale or auto-detected by the plugged keyboard or whatever is possible or realistic.

> > a shortcut like Ctrl+# is possible with a German keyboard layout but not
> > with an US English keyboard layout
> Ctrl+# is available on the english locale with Ctrl+Shift+3.
Modifier1+Key (my request) is a completely different shortcut combination than Modifier1+Modifier2+Key (your suggestion). [And of course I know that and where # is available on an US keyboard layout ...]

> > The same is valid vice versa: Ctrl+; isn't
> > possible with a German keyboard layout (as US English ';' key is 'ö' in
> > German) so this can be hidden there, but must be shown for US English
> > keyboard layout.
> I can see ';' in the same ',' key in the german keyboard image you linked to.
As said before: English Ctrl+; (Modifier1+Key) would be available via Ctrl+Shift+, (Modifier1+Modifier2+Key) on an German keyboard but that's no solution for the request of this enhancement request. Ctrl+Shift operations should only be used for seldom used functions--and to expect that non-US users should use complicate shortcuts for things for that US users have a good/easier shortcut is not user friendly.

(In reply to Heiko Tietze from comment #3)
> Created attachment 139139 [details]
> Keyboard assignment on LXQt
> 
> Would drop the whole concept of predefined keys and just allow anything what
> comes from the keyboard. That also means the keyboard tab needs a complete
> revamp. Something like KDE has or in the attached example from LXQt (after
> clicking the shortcut button you have 10s to press any key combination).
Maybe what you show from LXQt can be done as a first step. Sounds like an ugly hack (from UX perspective) but to add an extra possibility to add a key combination--that also allows non-US keyboard keys--would prevent to revamp the whole Customize dialog and hard coded key assignments in the LO code.
Comment 6 Thomas Lendo 2018-02-14 20:13:18 UTC
I don't know the internal restrictions and what's hardcoded, but as a first step maybe it's possible to allow shortcut keys from a non-English keyboard for not restricted/hardcoded things?
Comment 7 Paul Oranje 2018-03-06 14:14:01 UTC
On macOS the Cmd+` (back tick) key code is used as the shortcut to switch between opened documents in a app. Calc in LO6 breaks this and toggles show formulas.

Breaking platform UX is bad even more so when one cannot re-assign the key.
Comment 8 V Stuart Foote 2018-03-06 15:12:26 UTC
(In reply to Paul Oranje from comment #7)
> On macOS the Cmd+` (back tick) key code is used as the shortcut to switch
> between opened documents in a app. Calc in LO6 breaks this and toggles show
> formulas.
> 
> Breaking platform UX is bad even more so when one cannot re-assign the key.

That was addressed in Bug 114858
Comment 9 Xisco Faulí 2018-04-10 16:48:03 UTC
wow, there's been a long discussion going on in here.
@Heiko @Thomas, could you please update on the current status?
Comment 10 Thomas Lendo 2018-04-10 17:10:46 UTC
Nothing new since the discussion between Jay and me. My feeling is that English keyboard users are not aware of the restrictions that non-English users have today regarding possible and user friendly keyboard shortcuts.
Comment 11 Heiko Tietze 2018-04-10 18:58:46 UTC
Thorsten said at some point it's possible to rework the hard-coded key assignments. Was an idea for GSoC (#6 at https://pad.documentfoundation.org/p/UX-GSoC_Ideas) but since no mentor was interested and students apparently looked at the official list only we don't have one yet.

Whether this ticket remains unconfirmed or should become new is up to you. Right now it's a wontfix but from UX POV it's very recommended to change.
Comment 12 Heiko Tietze 2018-05-11 08:45:14 UTC
*** Bug 117555 has been marked as a duplicate of this bug. ***
Comment 13 Xisco Faulí 2018-05-31 14:58:27 UTC
*** Bug 115361 has been marked as a duplicate of this bug. ***
Comment 14 dhina 2019-02-01 13:21:45 UTC
I have the same "Cmd+`" issue with a french Keyboard on Mac 10.12.

It is very annoying when you are used to use this shortcut on all your applications and that it does not work only on LibreOffice.

Also, this bug can be of high importance because when you have a selected sentence (or paragraph or page...), doing "Cmd+`" will delete the text. As the shortcut also change the window, you don't see that the text was deleted and you can lose it.

Same thing on Spreadshit when you have selected a cell. Doing this short cut will delete the cell content while shifting to the previous LibreOffice window and then you don't realize the cell content was deleted.

Best,
Comment 15 Heiko Tietze 2019-02-02 10:55:06 UTC Comment hidden (off-topic)