Bug 107244 (Shortcuts-AltGR) - [META] Ctrl+Alt (aka AltGR) keyboard shortcut issues
Summary: [META] Ctrl+Alt (aka AltGR) keyboard shortcut issues
Status: NEW
Alias: Shortcuts-AltGR
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 38891 70633 103399 119676 36377 95635 95761 97768 97908 100622 100908 105925 118269
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2017-04-18 15:01 UTC by Yousuf Philips (jay) (retired)
Modified: 2019-02-20 08:13 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2017-04-18 15:01:45 UTC

    
Comment 1 V Stuart Foote 2018-09-09 17:48:29 UTC
As with all Windows applications behavior of the AltGr key for IME depends on the physical keyboard, the keyboard mapping selected, and only then how LibreOffice handles the generated keycode.

For locales where AltGr is used, os managed keyboard mapings will generate AltGr keycde, and for keyboards that do not have a physical AlgGr, the keyboard mapping Microsoft chose to send <AltGr> is a <Ctrl>+<Alt>.

That mapping is triggered by the os, when for example the us-international rather than the us keyboard mapping is selected by the user. 

Users could force their keyboard selection to *not* generate the AltGr, i.e. change keyboard to US, rather than US-International, and LibreOffice would behave.

Unfortunately that is not realistic... bug 95761 implemented a first attempt at allowing for use of both by splitting function <Left Alt> and <Right Alt> and allowing the <Right Alt>+<Ctrl> to be available as the <AltGr> for keyboard mappings/locales that required <AltGr>. But flolks did not like it--though it was technically sound.

A more nuanced solution for Windows builds would require we:

1. detect os assigned keyboard layout 
2. detect physical keyboard --parsing of GetKeyboardLayout() call?--
3. confirm os assigned locale

Then, test for AltGr physical key. If the <Right Alt>/<AltGr> key is not physically present (physical keysym or os mapping), <Ctrl>+<Alt> keyboard shortcuts will cause problems--remap dynamically? 

Could maybe make use of a MOD3 assignment to <Right Alt>/<AltGr> in shortcuts by locale/keyboard, similar was done for macOS <Cmd> shortcut collisions.

Believe in general the Linux builds are not much affected here, and all reported issues have been Windows os builds. 

But, guess some of the IME & deadkey mappings are impacted by physical keyboard and os mappings of the <AltGr> key.  And then there are issues with some of the stranger physical keyboards and os mappings--the Apple Touchbar keyboard on macOS, bug 105803 as an immediate example. But other locale specific mappings and physical keyboard layouts mean chasing these keyboard mapping issues one at a time is always going to be a partial solution.
Comment 2 Heiko Tietze 2019-02-20 08:13:26 UTC
jmux comment on the topic http://document-foundation-mail-archive.969070.n3.nabble.com/Re-Libreoffice-qa-minutes-of-ESC-call-tc4248679.html

(the issue is not limited to Windows)