Description: Certain shortcut key combinations are not contained in the tools -> customize -> keyboard -> shortcut keys-list, e.g.: - [Shift]+[Ctrl]+[+] : well, that is not¹ suprising at a first glance: on the german layout the [+] is a lower-case-character. it shares the same key with the [*] as an upper-case-character on the german layout. therefore it makes sense to not find the character [+] in a key combination that also contains the [Shift]-modifier. so, one might suspect that there is the key combination [Shift]+[Ctrl]+[*] somehwhere in the list. except it is not. - [Shift]+[Ctrl]+[*] : is missing, as stated above. - [Shift]+[Ctrl]+[_] : is missing. [_] is the upper-case character that shares a key with [-] as lower-case on the german layout. - [Shift]+[Ctrl]+[Ä] : is missing. the same applies to [Ö] and [Ü] - [Shift]+[Ctrl]+['] : is missing. it is the upper-case character that shares a key with [#] as lower-case on the german layout. - [Shift]+[Ctrl]+[?] : is missing. [?] is the upper-case character that shares a key with [ß] as lower-case on the german layout. ¹what i don't get is: why are there combinations for - [Shift]+[Ctrl]+[;] AND [Shift]+[Ctrl]+[:] on the other hand ??? [;] and [:] share the same key on the us layout, the first being lower-case, the latter upper-case. how would the program distinguish these two when the key combination contains the [Shift]-modifier? the same problem occurs with ['] and [#] on the german layout. Steps to Reproduce: 1. try to find certain key combinations in the tools -> customize -> keyboard -> shortcut keys-list to assign keyboard shortcuts to (e.g. [Shift]+[Ctrl]+[*]) Actual Results: a lot of shortcut key combinations are missing in the tools -> customize -> keyboard -> shortcut keys-list. Expected Results: shortcut keys list should contain the desired shortcut key combinations. Reproducible: Always User Profile Reset: Yes Additional Info: Please, please implement shortcuts in a totally different way, like any other program does: let the user assign the keyboard shortcut by letting them just type it instead of forcing them to search for a probably nonexistent list entry.
*** This bug has been marked as a duplicate of bug 115052 ***
the problem goes far beyond the shortcut keys list supposedly being based on the us-layout: 1. The shortcut keys list is certainly not based on the US layout, because both of the following list entries are present [Shift]+[Ctrl]+[;] and [Shift]+[Ctrl]+[:] as i stated above, [;] and [:] share the same key in us layout, [;] being lower-case and [:] being upper-case. it therefore does not make any sense to list both of them in combination with the [Shift]-modifier. so let's have a look at what happens when using the us-layout and assigning [Shift]+[Ctrl]+[;] and [Shift]+[Ctrl]+[:] to different shortcuts, e.g.: [Shift]+[Ctrl]+[;] => Italic [Shift]+[Ctrl]+[:] => Bold Hitting [Shift]+[Ctrl]+[;: key] results in the font style being changed to Bold. It can therefore be assumed that even if the [Shift]-modifier is contained in the shortcut key combination, the "main-character" (i.e. the lower-case character] is used to denominate the character key. the combination [Shift]+[Ctrl]+[:] should therefore not be present at all in the list, yet it is. it even works on other layouts, e.g. the german layout, where [;] and [:] do NOT share the same key. therefore the key combinations are NOT based on the us layout. Another example is the combination [Shift]+[Ctrl]+[#]. the "main-character" of [#] on the us-layout is [3], yet [Shift]+[Ctrl]+[3] is present in the list too. 2. even IF it were based on the us layout, there are still important combinations missing: [Shift]+[Ctrl]+[/ or ?] [Shift]+[Ctrl]+[- or _] [Shift]+[Ctrl]+[\ or |] 3. even IF it were based on the us layout, this would not solve the problem that the process of assigning shortcuts via a list is overly complicated and should be replaced by a process that simply let's the user type in the desired combination.
Read the given duplicate issue of bug 115052, you'll see scope of that existing issue is more than just the current set of US keysyms as defined and available for use in VCL. Effectively any key symbol should be available, but that leads to a muddled UX without localization applied to the mapping appropriate to locale keyboard norms. Since you're asking for a different way--guess its just as viable to dupe to bug 115527 *** This bug has been marked as a duplicate of bug 115527 ***
(In reply to V Stuart Foote from comment #3) > (...) but that leads to a muddled > UX without localization applied to the mapping appropriate to locale > keyboard norms. that is already the case, as my examples have demonstrated.