Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • Settings Settings
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,015
    • Issues 1,015
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 59
    • Merge requests 59
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOME
  • SettingsSettings
  • Issues
  • #1214
Closed
Open
Created Dec 11, 2020 by Ian Douglas Scott@ids1024Contributor

keyboard: Alternate characters key setting behaves in an unclear way

The behavior of the "Alternate Characters Key" (i.e. level 3 shift) setting seems inconsistent how one would expect it to work based on the UI.

Expected Behavior, based on UI

  • The key selected in the dialog acts as a level 3 shift, and no other key does. If the dialog allows the "alternate characters key" to be set to nothing (which it currently doesn't), no key will act as a level 3 shift.

Current Behavior

  • On a de layout, Right Alt acts as a level 3 shift, regardless of the Alternate Characters Key setting, which sets another key to serve the same purpose.
    • Right Alt can be changes to work as an alt key with XKB option lv3:ralt_alt, but Gnome Control Center doesn't set that.
  • On a layout like en_US, the Alternate Characters Key has no effect, since it doesn't seem any bindings are specified as level 3 with that layout. Setting it just ends up disabling the existing function of the selected key.

Based on this, it seems inaccurate, since one expects the key set here and only that key to act as a level 3 shift. It also isn't clear what the setting is useful for. On de, it's already bound to a reasonable key by default. On en_US, it just ends up reserving a key to do something useless.

What is the intended use case for this setting, where the defaults wouldn't be best? If changing this is fairly niche, it may be best to leave out of Gnome Control Center. Power users can tweak all sorts of crazy XKB options in Gnome Tweaks.

Compose Key

A similar setting for the compose key has been proposed by the design team and is part of !785 (merged). So it's worth seeing how that compares.

  • Looking at /usr/share/X11/xkb/symbols, it like there are a few layouts with a compose key by default: Secwepemctsin, Irish, Atsina, Coeur d'Alene Salish. But it's uncommon.
  • It's quite useful with layouts like en_US that don't have it by default, unlike the layer 3 shift.

So I don't have any question about the intended use case here, but technically it's still inaccurate to suggest the binding specified in Gnome Control Center and only that one will be set as "compose".

Proposed better design

If it's kept (or for compose), this seems like a better design:

  • Allow disabling as in !910, but instead of having a switch to disable it, have a switch saying something like "Use layout default".
  • When something other than right alt is set, also set lv3:ralt_alt so only that binding will act as a level 3 shift.

But it might be better to just remove the "Alternate Characters Key", if the layout's default is almost always best.

Assignee
Assign to
Time tracking