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.

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

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.

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

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

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?

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.

(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

wow, there's been a long discussion going on in here.
@Heiko @Thomas, could you please update on the current status?

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.

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.

*** Bug 117555 has been marked as a duplicate of this bug. ***

*** Bug 115361 has been marked as a duplicate of this bug. ***

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,

Changing priority back to 'medium' since the number of duplicates is lower than 5

*** Bug 131316 has been marked as a duplicate of this bug. ***

Hello Heiko & UI team,  this bug #115052 is mentioned in my related issues list but IMHO none of the related issues of any mentioned bugs hits identical  problems than I tried to describe in bug #131316

To follow your KDE link I booted Kubuntu from USB stick and tried the keyboard customization dialog what is obviously a result of GSoC2011. The dialog looks nice but disqualifies for use inside a text editor for several reasons. Most important: It does not support key key sequences described in bug #131316.

Example for key combination (like it is LO now but not all free combinations possible)

cntl + shift + q is to press the 3 keys cntl - shift and q same time. Practically this is already a simple state machine for the reason, a keyboard reports key up/down codes but I consider this as a pure logical combination.

Example for key sequence (as bug #131316 tries to describe)

cntl + q - s what is to press the two keys cntl  and q, then release both (or only one or none) and then press the key s. This requires further states for a state machine implementation. Cntl-Q enters first state, and s enters second state while the s key used without preceding cntl-q is writing a „s“ character to the text or doing something else. #131316 mentioned editors can do this.

Here is a „who is who“ keyboard emulation table for some well known text editors, unfortunable incomplete with many questions marks:

https://en.wikipedia.org/wiki/Comparison_of_text_editors#Key_bindings

Most of them are programmers editors, but some are also multi purpose for office documents and programmers. Almost all of them can be considered as „legacy“ style but some are maintained up on today by its enthusiastic user communities.

To understand the situation, we have to dig a into computer history. Otherwhile bug reports like: In situation xx shorcut yy is not working“ will continiue and any patches will make the patchwork more complicated. The first 2 columns of the link are IBM CUA and MacOS.  Remarkably, this are NO text editors but UI frameworks while the remaining columns are editors. For the same reason, a 
sustainable patch should be implemented equivalent to this columns.

There is no discussion about todays LO default configuration for Macintosh should be MacOS and for Microsoft IBM-CUA but the way to reach this should be different from what LO is doing now. Ideally users expect to be exactly compatible with Word behaviour.

In the time before the MFC (Microsoft Foundation Class) every editor for CPM and later DOS came with its own printer driver, screen driver and of coarse its own keyboard bindings. Starwriter by Marco Börries already supported mouse. Beside being an LOs ancestor it is a prig candidate for that editor category with extensive use of key sequences why I mentioned him in my bug report #131316. That time faded out with Apple, Microsoft SDK/GDI and later the MFC. Writing a text editor suddenly becomes easy. Framworks like Qt allow system independend development. Derive your application from the correct class and it will do what users expect becouse it behaves like everything else. This is a great benefit as application developers dont have to write a single line for displays or printers and things like graphical print-preview or PDF output are simply working. Same time the users dont have to learn how to print a sheet of paper for every application separate.

Unfortunately, this is not a benefit for the keyboard as some power of the legacy system keyboards disappeared thereby. And worse, it is not possible to bring this back by any custom configurations. Further this is not only true for keyboard bindings but also and less known for mouse input. This bug report only covers the keyboard bindings. Any OO class concepts with pre wired keyboard functionality comes to its limits as system wide predefined shortcuts are in conflict with customized user setup wishes in some situations. An example is given for Mozilla below. 

With other words: A sustainable solution for LO  (at least for the writer) should not use any inherited class behaviour for keyboard. A new keyboard input instance needs to go back to very basic keycode inputs. Key codes are numeric values for a physical hardware key. Unless character codes, key codes are not influenced by the system language setup nor any character what is printed on the key button nor by its modifier keys shift, cntrl, alt or other meta modifier keys. 

To get in touch with the key codes you can try one of the many pages like 
https://www.w3.org/2002/09/tests/keys.html 

This page also allows to try the keyboard predicament using Mozilla or any other browser what is also true for LO keyboard setup: Backspace goes to previous URL for a W10 machine, while cntl-Q is going to quit the browser tabs for a Gnome desktop. Both cases, this keys cannot be used for a user assignment. For a web browser or even a spreadsheet calculator this may be acceptable but never for a document text editors input. For this reason users will always complain like: In situation xx shorcut yy is not working“. 

There are only very  few combinations „hard wired“ by OS like cntl-alt-del for Windows and everything else should be allowed. To approximate the many keyboard problems closer, I suggest to split the task as following:

1) writing a real time state machine to process all keyboard inputs including UI setup dialog what includes conflict management

2) modifing all used LO classes to disable any default assignments from keyboard. This should be feasable at least for the Writer. 

3) connect output from 1 to 2

4) configure a default setup for Windows / Apple to make the keyboard like before.

Improvements according to the many related but reports should be easy now.

(In reply to Janvi from comment #18)
> ... problems than I tried to describe in bug #131316

> cntl + q - s what is to press the two keys cntl  and q, then release both
> (or only one or none) and then press the key s. This requires further states
> for a state machine implementation.

I disagree here. Those key sequences are always rather easter eggs than usable interactions. Maybe some specialized apps work like this but not in general. 

> 1) writing a real time state machine...
> 2) modifing all used LO classes
> 3) connect output from 1 to 2
> 4) configure a default setup

Right now we have something like 

css::awt::Key::A -> "KEY_A" (defined at multiple places)
css::awt::Key::CTRL_LEFT -> "KEY_MOD1"
KEY_MOD1 + KEY_A -> .uno:SelectAll

there is nothing like 

css::awt::Key::Ä defined to use ctrl+Ä (A umlaut). If you describe <any>U+00CA + ctrl as state machine I'm with you. The point with KDE was rather how to get the Ä into the game since we a) do not want to add this key value and every other possible to the program and b) want to respect localized keyboards (yours likely has no Ä key available but you can press ; without need for shift).

Some numbers to show how much effort it is:

git grep KEY_A |wc -l
198
git grep KEY_MOD1 |wc -l
564

(In reply to Heiko Tietze from comment #17)
> *** Bug 131316 has been marked as a duplicate of this bug. ***

The request at bug 131316 seems quite unrelated to this one here (and way more complicated).

(In reply to Thomas Lendo from comment #10)
> 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.

Indeed.

I'll try to explain the problem a bit more thoroughly.

I'd say there are two major issues with current hardcoded list of keys available to be used in shortcuts:
1) non-US letters (like Õ, Ä, Ö, Ü, ß, Æ, Ø, Å, not to mention Greek/Cyrillic/etc. letters) can't be used for shortcuts even if they have their own key on a layout,
2) punctuation/symbol keys' availability directly vs. with Shift (or AltGr) is wildly different between US layouts and others.

For instance, consider the following short (yes, short!) list of examples about available punctuation/symbol keys across some European and Cyrillic layouts:
- dedicated "." key (most layouts) or Shift+semicolon (French layout)?
- dedicated "," key or Shift+period (most Cyrillic layouts)?
- dedicated ":" key (French) or Shift+semicolon (US) or Shift+period (many European) or even Shift+6 (Russian)?
- dedicated ";" key or Shift+comma (many European layouts) or Shift+4 (Russian)?
- dedicated "=" key or Shift+0 (several European layouts) or Shift+7 (Hungarian) or something else?
- dedicated "/" key or Shift+7 (several European layouts) or Shift+colon (French)?
- dedicated "[" and "]" keys or AltGr+8 and AltGr+9 (several European layouts) or something else (e.g. French)?
- are numbers available directly or do they need Shift (French, some Cyrillic layouts)?

So if a symbol that requires pressing Shift on some layouts (like ";" or "/") is used in a default shortcut in LibO *without* Shift (e.g. Ctrl+semicolon), it will either produce unexpected results or not work at all (because LibO detects also the Shift being pressed).

*** Bug 151179 has been marked as a duplicate of this bug. ***

*** Bug 134470 has been marked as a duplicate of this bug. ***

(In reply to Thomas Lendo from comment #10)
> 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.
Symbl.cc recommended the following Alt codes that is suitable for non-English letters.
https://symbl.cc/en/alt-codes/

Some Unix-like systems may have Ctrl+Shift+U keys to convert hex number to Unicode character, it's curiosity whether LibreOffice support both of them.

*** Bug 157645 has been marked as a duplicate of this bug. ***

defined keysyms for use are found in API:

https://api.libreoffice.org/docs/idl/ref/namespacecom_1_1sun_1_1star_1_1awt_1_1Key.html

and found in source:

https://opengrok.libreoffice.org/xref/core/include/vcl/keycodes.hxx

*** Bug 158516 has been marked as a duplicate of this bug. ***

*** Bug 148301 has been marked as a duplicate of this bug. ***