gnome keyboard settings panel enforces single iso-level3-shift key
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gnome-control-center (Ubuntu) |
Fix Released
|
Medium
|
Gunnar Hjalmarsson |
Bug Description
My Unicomp has a right windows key and alt key in swapped positions, so I configured right windows key to act as a second Alt_R (well ISO_Level3_Shift), using gnome-tweaks, leading to:
/org/gnome/
['caps:none', 'lv3:rwin_switch']
Opening the keyboard page in gnome settings resets this to
/org/gnome/
['caps:none', 'lv3:ralt_alt', 'lv3:rwin_switch']
Effectively disabling the Alt Gr (right alt key) from acting as level 3 shift.
Enabling right alt explicitly is not better. That sets
/org/gnome/
['caps:none', 'lv3:ralt_switch', 'lv3:rwin_switch']
and opening the keyboard panel then just deletes the windows key switch:
/org/gnome/
['caps:none', 'lv3:ralt_switch']
Not sure if it's a regression, but it's problematic anyway.
summary: |
- gnome keyboard settings always set lv3:ralt_alt xkb option when - lv3:rwin_switch is set + gnome keyboard settings enforces single iso-level3-shift key |
summary: |
- gnome keyboard settings enforces single iso-level3-shift key + gnome keyboard settings panel enforces single iso-level3-shift key |
When switching to g-c-c 40, the MR
https:/ /gitlab. gnome.org/ GNOME/gnome- control- center/ -/merge_ requests/ 910
was included in Ubuntu as patches to avoid a worse regression. Your example shows that there is room for improvement of that upstream proposal. Apparently it hasn't been considered carefully enough how that new Settings -> Keyboard control plays together with using e.g. Tweaks for setting XKB options.
@Julian: It would be great if you could add your observation to the upstream MR.