Problems with non-letter characters in hotkeys

Not all keyboard layouts (keymaps) have non-letter characters on the first level of the keyboard (like in QWERTY layout) and when they don’t, hotkeys don’t work.

For example, in Tracker, hotkeys with 1, 2 and 3, or in Pe hotkeys with [ etc.

The solution for such characters in hotkeys is to either not use them at all or make them configurable.

…Clearly, this is probably exclusively a problem for users of languages other than English.

This is an old known problem that tends to pop up on non-US keyboard layouts but can also affect things like Cmd-+ for zooming on a US keyboard (since + is Shift-= on a US keyboard.)

One related Trac ticket: #2499 ([Keymap] shortcuts don't work with some keymaps) – Haiku

The reason for this is shortcuts can include Shift but the system does not consider Cmd-+ and Cmd-Shift-= equivalent (on a US layout) even though it should.

This becomes tricky because it means the shortcut system needs to know the keyboard layout and would need to assign “synonyms” for the shortcuts that need to be shifted. Also this should probably not apply to letters because Cmd-[letter] and Cmd-Shift-[letter] might be useful as separate shortcuts. Also what happens if different actions map to the same “synonym”? Research should be done on other systems to see how they handle it as well.

I think either way the above needs to be fixed but there has also been discussion in the past about making shortcuts configurable. At the moment that would need to be done inside each application, which is painful. Ideally Haiku provides some sort of system for applications to register their “actions” with default shortcuts that could be changed in a system Preference app (in this case obviously it would be the Shortcuts app which would need to be adjusted.) This system would also have a bunch of common default actions already like Cut, Copy, Paste, Open, Save, Undo, Redo, etc.

But adding something like that is a new Haiku feature and would require a developer with interest and also need to be supported enough by other developers to be reviewed and merged. Updating all included Haiku applications to use this new system might also be a lot of work, unless it can be done in a clever way which requires minimal application code changes. Which may be possible but we would not know until someone tried. But it would likely be a very useful change.

3 Likes

Some programs like ephipany web browser have those problema with AltGr+2 that corresponds to @ carácter. This occurs in claws mail as well

those are gtk apps on a wayland compatibility layer that does not properly support Haikus text input.

The question IS… Is there a way to make a solution for that?

Perhaps the same way how the shortcut used to switch the last two workspaces works? It always uses Alt + the key below ESC, so I’m guessing it’s not based on a character