Keybindings flexibility

[victorcrimea]

• Remove support of virtual keys that don't have corresponding KeyCode.
• Add F13-F30 keys support.
• Introduced VirtualKey to represent the logical meaning of a key, to be used in configuration files and settings.

• [not yet ] Added an entry to CHANGELOG.md if this change could be valuable to users

Implementation discussion may be held here. While concept/logic discussion is preferred in the issue #2636

[panekj]

For what reason are F13+ keys added?

[victorcrimea]

@panekj While being relatively rare those keys are completely valid keycodes. You can assign them to any layer/button on QMK keyboards in VIA. There are some (older) keyboards that have them physically.

[melMass]

@victorcrimea Is there an ETA regarding this PR?

[victorcrimea]

@victorcrimea Is there an ETA regarding this PR?

Last time I was working on this problem. I found that it is necessary to get the keyboard layout from the system. And there was no cross-platform way of doing this and I wan't brave enough to dive into os-specfic libraries. I'll try to look around again, maybe something is improved.

[panekj]

@victorcrimea Is there an ETA regarding this PR?

Last time I was working on this problem. I found that it is necessary to get the keyboard layout from the system. And there was no cross-platform way of doing this and I wan't brave enough to dive into os-specfic libraries. I'll try to look around again, maybe something is improved.

No, we're still waiting for rust-windowing/winit#2678

[victorcrimea]

@panekj I just realized that in the meanwhile we can just make it a setting in lapce. Basically a choice between:
Azerty
Qwerty
Qwertz
[maybe other layouts as well]

Not ideal but solves peoples problems

[melMass]

Imo that's a good compromise in the meantime since besides reassigning all the shortcuts to your layout lapse is not usable on other layouts than qwerty

[sorcerersr]

Hi, another idea:

don't use keycodes, physical key locations etc. Just use the Character value from winit:

Character(Str)

A key string that corresponds to the character typed by the user, taking into account the user’s current locale setting, and any system-level keyboard mapping overrides that are in effect.

The keymaping implementation and config then should ignore the Shift-modifier (AltGR is already ignored by winit).
So instead of defining a keybind like this in the config:

Ctrl + SHift + a

it would be

Ctrl + A

as the Shift modifier is implicit (a user have to type Shift+a to get the A)

Another example: A keybind could be defined as

Ctrl + /

in the config.
A user using a ANSI QWERTY layout would just press Ctrl+/. Another user using a ISO-De QWERTZ layout knows that to get the /char has to press Shift+7so the user just presses Ctrl + Shift + 7to execute the command bound to the keybind Ctrl + /.

This way the application does not need to know anything about the layout of the keyboard.

[victorcrimea]

@sorcerersr This makes editor unusable to those who use latin AND non-latin keyboard layouts. Because Lapce will only handle keybinding if it is pressed in latin layout.

P.S. This was the original problem I tried to solve. And at the very end I realized the problem with QWERTY/QWERTZ/AZERTY.

[iltumio]

I'm a DVORAK user, but my physical keyboard is a QWERTY. I'm also affected by the issue since lapce is detecting the physical keys instead of the virtual ones (if I press "." lapce is reading "e" because it's the physical key). I don't know if this help, but before the refactor using Floem, the keyboard was working fine

[victorcrimea]

@iltumio This is just a coincidence. It has nothing to do with Floem/druid

[victorcrimea]

@iltumio BTW, just curious. You as DVORAK user, do you also have QWERTY layout setup in your system?

The reason I'm asking this is because if we make keyboard layout a setting, it is not obvious how to handle scenarios when user has BOTH qwerty and non-qwerty latin layouts.

[sorcerersr]

@victorcrimea have you considered supporting this use case by allowing more than one keybind per command in keymaps.toml?

Hardcoding keyboard layouts or mappings of one layout to another into an application seems to me like reinventing the wheel. On my Linux system there are about 100 Layouts to choose from (not counting variants).

[victorcrimea]

@sorcerersr VSCode does exactly this in browser link

I'm not sure what do they use to extract keyboard layout from the OS. Most likely it is chromium that does the os-specific heavy-lifting to get the keyboard layout.

[iltumio]

@iltumio BTW, just curious. You as DVORAK user, do you also have QWERTY layout setup in your system?

The reason I'm asking this is because if we make keyboard layout a setting, it is not obvious how to handle scenarios when user has BOTH qwerty and non-qwerty latin layouts.

I use DVORAK layout (on querty phisical keyboards) 99% of the time. I still keep the option to switch layout to the Italian Querty one for some very rare use cases that have nothing to do with coding (therefore is not relevant for lapce in my case).

Do you think we can have a look at Tauri implementation? I'm not 100% sure, but they should have addressed the issue somehow

https://github.com/tauri-apps/tao/blob/dev/src/keyboard.rs