KLC outputs need work

[fabi1cazenave]

The *.klc files, intended for MS Keyboard Layout Creatof (MSKLC) and KbdEdit, raise a few issues :

• KbdEdit fails to parse the 1dk section (DEADKEY 2019) because of the empty lines and comment lines
• with MSKLC, the 1dk key (U+2019) outputs ’’ when pressed — this started with Windows 10, it seems dead keys cannot be a non-ASCII character any more
• with MSKLC, some apps (e.g. Notepad++, VSCode) seem to use the physical key instead of the generated char to compute keyboard shortcuts — e.g. with Ergo-L, Ctrl-N is taken as a Ctrl-F

[fabi1cazenave]

As mentioned in #55, we might need two different KLC outputs :

• one for MSKLC, in which there are two major limitations for 1dk :
  • 1dk [Space] has to output an ASCII character (since Windows 10)
  • 1dk 1dk probably has to output an ASCII character, too (to be checked)
  • the 1dk layer cannot contain any dead key
• one for KbdEdit, which does not have these limitations, but can be poorly supported by a few apps (which ones ?)

There might be other features that require specific KbdEdit, e.g. keyboard shortcuts.

Instead of generating two KLC outputs, we could also put these KbdEdit-specific features behind a flag :

• without this flag (default), Kalamine exits with a error if trying to build a KLC file with features requiring KbdEdit (1dk)
• with this flag set, a KLC output will be generated in any case, but with a warning if the compatibility is limited to KbdEdit

https://bepo.fr/wiki/Windows#Probl%C3%A8mes_avec_certains_logiciels

[fabi1cazenave]

Related resources :

• https://archives.miloush.net/michkap/archive/2011/04/16/10154700.html
• https://github.com/lelegard/winkbdlayouts
• https://bepo.fr/wiki/Pilote_Windows
• https://msklc-guide.github.io

[fabi1cazenave]

Here’s a keyboard layout that has non-ASCII dead key terminators and chained dead keys. Still unsure whether this is supposed to be usable with MSKLC or not…

https://kbdlayout.info/kbdgre1/download/klc

[fabi1cazenave]

with MSKLC, some apps (e.g. Notepad++, VSCode) seem to use the physical key instead of the generated char to compute keyboard shortcuts — e.g. with Ergo-L, Ctrl-N is taken as a Ctrl-F

This is not related to MSKLC. KLC layout descriptions start with two columns:

• SC (scan codes), which is the physical key signal
• VK (virtual keys), which is the QWERTY-ANSI key to send when Ctrl is pressed

Unfortunately, Kalamine does not change the VK column content, which means all KLC layouts it produces use QWERTY shortcuts at the moment.

A quick solution could be to let Kalamine “guess” what VK should be sent for each key / character. This couldn’t tackle all corner cases but should get the job done by default.

A finer solution would be to add support for a ctrl layer in Kalamine, which would be used to define the behavior of each key when Ctrl or Cmd is pressed : before #33, keylayout outputs used to have QWERTY shortcuts for Cmd / Cmd-Option actions, and maybe we want to get this feature back.

[Geobert]

What’s left in this one with https://github.com/OneDeadKey/kalamine/pull/114 landed?