It seems that the minimum version for lxml has recently been set to 4.8.0:
https://github.com/lxml/lxml/blob/master/CHANGES.txt#L246-L256

As xkalamine can be used out of kalamine to generate layout installers, we should make sure this affects only the SVG generation (and possibly just define a minimum version in the pyproject.toml file). Otherwise, we’ll have to investigate.

… like the cool kids do on Cargo.

As discussed on Discord, I am currently trying to package kalamine into Nix.

https://search.nixos.org/packages

I am not far from having finished but while trying to execute tests, I have a question. What is the exact goal of the layouts directory? It contains sample layouts apparently. But is it because kalamine wants to have those layouts built alongside kalamine to provide them to users of kalamine, or is it just for testing purposes while running pytest?

It is just that nix has got different phases in its build process. So I would like to know if the step kalamine layouts/*.toml should be part of the build step or the test step. The main difference is that if it is part of the build, the resulted compiled layouts will be part of the outcome, alongside the binary. And so nix users will have them in the package directory on their system when installing the package.

Going even further, if they are part of the package, we can even add some instructions in the build recipe to copy them over to the correct directory /nix/store/<package_dir_when_installed>/usr/share/X11/xkb. I am talking about Linux here. When using the full NixOS operating system, this could have the effect of having them directly available as default keyboard layouts (because /nix/store/<package_dir>/etc will be more or less merged with /etc, and this allows packages to contribute configurations).

So just to sum up, is this desired to have those layouts contributed as default-to-be-installed layouts, or are they just here for reference and for the tests?

Hope it makes sense even if you are not familiar with the nix ecosystem.
Thanks

xkalamine installs layouts in xkb/symbols/[locale] files for historical reasons, and because let’s face it : writing

setxkbmap fr -variant lafayette

… is the coolest thing ever. ^_^

But that relies on some clunky text delimiters around every layout definition in those files, which is a very debatable design decision to say the least ; and it does not survive to an XKB upgrade, which is a pity.

A much saner approach would be to put all kalamine layouts in an xkb/symbols/kalamine subdirectory and associate those layouts to the proper locale in the xkb/rules/{base,evdev}.xml files. And selecting a layout on XOrg would become :+1:

setxkbmap kalamine/lafayette

And an intermediate approach would be to put all kalamine layouts directy in xkb/symbols buf forbid to overwrite non-kalamine layouts, which implies keeping the clunky text delimiters. We’d still avoid the loss of our layouts on an XKB upgrade, and the layout selection would become :

setxkbmap lafayette
setxkbmap lafayette -variant 101

… which looks pretty darn cool, too. ^_^

I took ergol.toml, modified the name8 to "double-identifier", replaced the "-" on the alpha layer by an unbreakable space and "," by a narrow unbreakable space, and "S" by "A" (so that we have two A key, what are you going to do 😄)

In dist/double-identifier.toml, I get 2 sections with id "x00a0" (unbreakable space), 2 sections with id "202f" (narrow unbreakable space), and two section with id "a" which is incorrect.

I would suggest to use the layer + keycode as action id, like "alpha-0" for "a" in layer alpha, "shift-0" for "S", "altgr-18" for the symbol in altgr in the first key on the number row, "shift-space"…

double-identifier.toml.txt
double-identifier.keylayout.txt

Hi,
I'm not sure if this is a bug in (x)kalamine or ErgoL, i already opened a similar bug on the ErgoL side but to no avail, so opening one here too.

Running sudo xkalamine install ergol.yaml breaks French keyboard layouts, in Fedora 38 with GNOME 44.5 (and Wayland).

Once installed, the layout is properly detected by xkalamine:

sudo xkalamine list
fr/ergol                   French (Ergo-L)

But:

1. It doesn't appear in available layouts and
2. All other French layouts, apart from "fr-azerty (m17n)" disappear from the list of available layouts.

Trying to switch to ErgoL following the advice given by xKalamine, setxkbmap fr -variant ergol, leads to surprising results: for instance Thunderbird or Joplin using ErgoL but Firefox or Element not.

For comparison, after running sudo xkalamine remove fr/ergol :

Lastly, something much more painful happens if you don't remove fr/ergol and reboot, the default layout (fr-bepo in my case) is no longer usable in GDM, making login weirdly broken. It still works in a vTTY. Qwerty still works, but I have no idea if this is because it is setup as the secondary layout or not.

kalamine create expects to find layout templates in a layouts subdirectory that is not published.

pytest stopped working, and I realize our unit tests are broken in many ways:

• they assume all sample layouts have already been built, which is wrong — see #15
• they don’t event test each conversion output, only the macOS one at the moment
• there should be an automated way to ensure tests are run, at least before publishing !!

Some of these tasks are “good first issues” for developers with basic Python / github CI culture — and I’m afraid I’m not reaching the “basic” level right now for these.

I took ergol.toml, modified name8 to "circumflex" and put "*^" on 1typo+shift on the 1typo key [O].

The modification seems to work for Linux, I can find the dead_circumflex at the right place in the xkb file. However it is missing both in the .keylayout and for the live preview (kalamine --watch). 1typo + shift + 1typo + key does the diaeresis version of the key, not the circumflex one.

I also tried with a regular ASCII symbol, and can reproduce the same issue.

circumflex.toml.txt
circumflex.keylayout.txt
circumflex.keylayout.expected.txt

I’m listing here all the issue that i found so far when trying to generate the bmp disposition which seems to be a good stress test !

I’m using kalamine 0.18, from the latest master.

(note: github doesn’t like .yaml and .keylayout files, so I added the suffix .txt, like in the early 00’ :yeah:)

bmp.keylayout.actual.txt
bmp.keylayout.expected.txt
bmp.yaml.txt

By order of apparition of the issue in the file:

(note: I’ve noticed that my expected file, while totally functional as-it (it’s the one I’m using currently) as a few defect, like using "http" instead of "https" in the reference link, or a few unneeded things related to the modifier map index, so kalamine is not expected to generate a bit perfect copy of bmp.keylayout.expected)

• option layer ascii art is empty
• if . (dot) is mapped both in alpha and shift+alpha layer, then kalamine replace its shift+alpha version by : (colon)
• narrow no break space in alpha (u+202f) is replaced by no break space (u+00a0)
• space keycode is written as x0020 instead of space (it’s technically not an issue, they are equivalent but it’s surprising)
• 1dk + altgr is not supported
• all option+shift (shift+altgr) symbols are not correctly generated (instead there is u+0010 which means passthrough)
• 1dk + uppercase letters is sometime not correctly generated (æ instead of Â on [q] for example)

$ kalamine  watch bepo.yaml --angle-mod
Usage: kalamine watch [OPTIONS] FILEPATH
Try 'kalamine watch --help' for help.

Error: No such option: --angle-mod

A -a shorthand would be nice to see, while we’re at it.

The symbol ! is available in [shift-1] and [altgr-M]. On the current layout of ergol, 1typo + [shift-1] == ¡ .

On mac, instead of defining that the altgr layer should directly output a character, it ask for the action corresponding that symbol in another layer. This means that if I use the layer generated by kalamine, 1typo + altgr + [M] == ¡ .

ergol.toml.txt
ergol.keylayout.txt
ergol.keylayout.expected.txt

$ sudo bin/xkalamine install dist/ergol.xkb

File could not be parsed.
Error: Invalid statement (at line 1, column 1).

xkalamine should make clear that a TOML/YAML description file is expected, not an XKB. And maybe point to the online documentation.

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

xkalamine should add en <engine/> entry to /usr/share/ibus/component/simple.xml

Detailed information here : https://geekingfrog.com/blog/post/ibus-multi-layouts

I took ergol.toml, modified the name8 to "modified-spacebar", and the [spacebar] section to have easy to search symbols names.

  [spacebar]
  shift       = "\u9991"
  altgr       = "\u9992"
  altgr_shift = "\u9993"
  1dk         = "\u9994"
  1dk_shift   = "\u9995"

In the output of kalamine build double_identifier.toml:

• dist/modify-spacebar.xkb correctly contains the following output:

     // Space bar
    key <SPCE> {[ space           , U9991           , U9994           , U9994           ],[ U9992           , U9993           ]}; //   馑 馔 馔 馒 馓

• however dist/modify-spacebar.keylayout doesn’t have any modification passed on.

I assume the code just take default hardcoded values instead of the user-specified one. I am not sure which symbols would have been the best to to this test. Apparently 999x is in the Chinese plane! I am not sure if after the fix kalamine will display the hex value of the kenji. The part of the output that must be modified are the one after each <!-- Space bar -->, and the last 3 actions blocks.

(btw it’s not possible to remap the spacebar, we don’t have a alpha = "…" entry in the [spacebar] section, but who would want that !)

modify-spacebar.toml.txt
modify-spacebar.keylayout.txt
modify-spacebar.keylayout.expected.txt

Kalamine v.0.31
beop.txt
Pas d'erreur avec kalamine make et kalamine watch.

❯ wkalamine make beop.toml
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\Scripts\wkalamine.exe\__main__.py", line 7, in <module>
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\click\core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\click\core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\click\core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\click\core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\click\core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\kalamine\cli_msklc.py", line 52, in make
    if msklc_mgr.build_msklc_installer():
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\kalamine\msklc_manager.py", line 87, in build_msklc_installer
    dummy_klc = dummy_layout.klc
                ^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\kalamine\layout.py", line 513, in klc
    out = substitute_lines(out, "LAYOUT", klc_keymap(self))
                                          ^^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\kalamine\template.py", line 313, in klc_keymap
    symbol = hex_ord(symbol)
             ^^^^^^^^^^^^^^^
  File "C:\Users\Olivier\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.11_qbz5n2kfra8p0\LocalCache\local-packages\Python311\site-packages\kalamine\template.py", line 23, in hex_ord
    return hex(ord(char))[2:].zfill(4)
               ^^^^^^^^^
TypeError: ord() expected a character, but string of length 2 found

Currently, the locale field is not used in the generation and hardcoded in the template

It’s now a bit unclear whether dead keys are accepted in the 1dk layer or not.

As a matter of fact, I’ve never put much effort in maintaining this feature because I believe Compose makes much more sense than any double dead key. But I’ve revised my opinion, mostly because of @Ced-C ’s idea of having a dead key in 1dk 1dk instead of Shift+1dk for Bépolar.

Right now it seems to me that :

• the Linux output supports dead keys in the 1dk layer seamlessly
• the macOS output is broken when the 1dk layer has dead keys
• the Windows output should work, but I would expect something tricky for having a dead key in 1dk 1dk

We should either make sure this feature works everywhere or ban it explicitly.

Hi

Is this for ANSI only?

Thanks, Ian

Add an option to keep the hotkeys at their Qwerty location

• Linux
• MacOS
• klc
• C
• ahk

Using xkbcomp after kalamine leaves keys such as MUTE, VOL +, VOL- ineffective.
Is there a way to leave those as-is, forwarded?

Warning:          No symbols defined for <AB11> (keycode 97)
Warning:          No symbols defined for <KATA> (keycode 98)
Warning:          No symbols defined for <HIRA> (keycode 99)
Warning:          No symbols defined for <HENK> (keycode 100)
Warning:          No symbols defined for <HKTG> (keycode 101)
Warning:          No symbols defined for <MUHE> (keycode 102)
Warning:          No symbols defined for <JPCM> (keycode 103)
Warning:          No symbols defined for <LNFD> (keycode 109)
Warning:          No symbols defined for <I120> (keycode 120)
Warning:          No symbols defined for <MUTE> (keycode 121)
Warning:          No symbols defined for <VOL-> (keycode 122)
Warning:          No symbols defined for <VOL+> (keycode 123)
Warning:          No symbols defined for <POWR> (keycode 124)
Warning:          No symbols defined for <I126> (keycode 126)
Warning:          No symbols defined for <I128> (keycode 128)
Warning:          No symbols defined for <HNGL> (keycode 130)
Warning:          No symbols defined for <HJCV> (keycode 131)
Warning:          No symbols defined for <AE13> (keycode 132)
Warning:          No symbols defined for <STOP> (keycode 136)
Warning:          No symbols defined for <AGAI> (keycode 137)
Warning:          No symbols defined for <PROP> (keycode 138)
Warning:          No symbols defined for <UNDO> (keycode 139)
Warning:          No symbols defined for <FRNT> (keycode 140)
Warning:          No symbols defined for <COPY> (keycode 141)
Warning:          No symbols defined for <OPEN> (keycode 142)
Warning:          No symbols defined for <PAST> (keycode 143)
Warning:          No symbols defined for <FIND> (keycode 144)
Warning:          No symbols defined for <CUT> (keycode 145)
Warning:          No symbols defined for <HELP> (keycode 146)

Installing and removing custom keyboard layouts for XOrg is the last use case where xkalamine must be run as sudo, and it must be covered.

It looks like pipx is becoming a nice replacement for pip in this use case {= installing a Python app within a pyenv container). And TIL that apps installed by either pip or pipx can be run as sudo if the PATH is preserved:

sudo env "PATH=$PATH" xkalamine install layout.toml

So let’s make sure it’s in the README, and let’s modify xkalamine so that if run as user on XOrg, it fails and drops the above command to the console so that users can just copy/paste the line and get it working.

Usage

kalamine -in [format]:[file] -out [format]:[file]

Formats

Input

• yaml: YAML

Output

• xkb: XKB for Linux
• keylayout: Keyboard Layouts for Mac
• klc: KLC for Windows

Files

Input

• -: Refers to standard input

Output

• -: Refers to standard output

Examples

Simple

kalamine -in qwerty.yml -out qwerty.xkb
# qwerty.xkb

kalamine -in qwerty.yml -out xkb:
# qwerty.xkb

Multiple outputs

kalamine -in qwerty.yml -out qwerty.{xkb,keylayout,klc}
# qwerty.xkb
# qwerty.keylayout
# qwerty.klc

kalamine -in qwerty.yml -out {xkb,keylayout,klc}:
# qwerty.xkb
# qwerty.keylayout
# qwerty.klc

Multiple inputs and outputs

kalamine \
  -in qwerty.yml -out qwerty.xkb \
  -in azerty.yml -out azerty.xkb
# qwerty.xkb
# azerty.xkb

kalamine \
  -in qwerty.yml -out xkb: \
  -in azerty.yml -out xkb:
# qwerty.xkb
# azerty.xkb

Read and write from and to standard streams

kalamine -in yaml:/dev/stdin -out xkb:/dev/stdout < qwerty.yml
# /dev/stdout

kalamine -in yaml:- -out xkb:- < qwerty.yml
# <stdout>

kalamine -in yaml:- -out xkb: < qwerty.yml
# <stdout>

kalamine make https://github.com/jidhub/thumb-external-keyboard-layouts/blob/e3d0589ed7f980cb1c275e6d388428f2af6e863b/thumbsmodifiersv1.toml

When downloading the above link then running the kalamin make command, I obtain the stacktrace below. Specifying the shift effect as done in first change of jidhub/thumb-external-keyboard-layouts@5676aff fixes that. See french details of how I debugged that on https://discord.com/channels/1046720208171175946/1063061534038822942/1206264367822151710

Traceback (most recent call last):
  File "/data/data/com.termux/files/usr/lib/python3.11/pdb.py", line 1775, in main
    pdb._run(target)
  File "/data/data/com.termux/files/usr/lib/python3.11/pdb.py", line 1643, in _run
    self.run(target.code)
  File "/data/data/com.termux/files/usr/lib/python3.11/bdb.py", line 600, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/data/data/com.termux/files/usr/bin/kalamine", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/kalamine/cli.py", line 122, in make
    make_all(layout, Path("dist"))
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/kalamine/cli.py", line 92, in make_all
    layout.svg.write(svg_path, pretty_print=True, encoding="utf-8")
    ^^^^^^^^^^
  File "/data/data/com.termux/files/usr/lib/python3.11/site-packages/kalamine/layout.py", line 577, in svg
    if level_num == 1 and chars[0] == chars[1].lower():
                                      ~~~~~^^^
IndexError: list index out of range

It should be simple enough, the format is pretty straightforward. Dead keys have limited support though.

Doc: https://source.android.com/devices/input/key-character-map-files
Example of implementation for XKB —> KCM: https://github.com/anisse/bepo-android/blob/master/android.py

Since this project seems abandoned, here is my maintained fork: https://github.com/qwerty-fr/kalamine

This question has been raised a few times on issues and on Discord. I think it is appropriate to create a dedicated issue to follow this topic.

I guess the first step would be to document how to do this, and then potentially modify kalamine to allow the tool to install a layout in userspace.

I haven searched a lot so far. I only know that one could apply a layout using xkbcomp with $DISPLAY. Otherwise I see that setxkbmap has a -config option. Then, there is maybe a userspace equivalent of /usr/share/X11/xkb. Again those are simply hypothesis as I haven't gone into deep researches on the matter.

Any comments is appreciated.

In my disposition, I have nbsp which can be typed using two different keys. And each of those keys have an associated symbol in 1dk, but it’s not the same. When generating .keylayout for mac, the generated file has "action" section to generate the symbol associated with 1dk + key. The id of that section is the same for both of the key with nbsp which is invalid. I manually fixed it by renaming the id of one of the section.

Hello,

I would like to define directional arrow keys in my keymap on the altgr layer.

See the example:

altgr: |
  ╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
  ┆     ┃     │     │     │     │     ┃     │     │     │     │     ┃     ┆     ┆
  ┆     ┃     │     │     │     │     ┃     │     │     │     │     ┃     ┆     ┆
  ╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
  ·     ┃     │     │     │     │     ┃     │     │     │     │     ┃     ┆     ┆
  ·     ┃     │     │   ↑ │     │     ┃     │     │     │     │     ┃     ┆     ┆
  ·     ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
  ·     ┃   ⁽ │     │     │     │   ⁾ ┃     │     │     │     │   ± ┃     ┆     ┆
  ·     ┃   ( │   ← │   ↓ │   → │   ) ┃     │     │     │     │   + ┃     ┆     ┆
  ╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
  ┆     ┃     │     │   ¦ │     │     ┃     │     │     │     │   ≠ ┃           ·
  ┆     ┃   [ │   ] │   | │   { │   } ┃   \ │     │     │     │   = ┃           ·
  ╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·

I tried using the Unicode arrow keys, but they are not transformed by kalamine, so when pressing the key, those characters are literally printed.

However, if I modify the .xkb manually and transform uparrow into Up, it does the trick and it correctly references the arrow key.

Is it a feature that is missing in kalamine? Is there a way to tell that I want the actual directional arrow key from within my yaml file?

Thanks

Trying to load this layout: https://github.com/Nuclear-Squid/ergol/blob/master/layouts/bepo.yaml

$ kalamine  watch bepo.yaml                                                                                                                       [± pr]

Server started: http://localhost:1664
Hit Ctrl-C to stop.
[I 240208 14:43:38 server:335] Serving on http://localhost:5500
[I 240208 14:43:38 handlers:62] Start watching changes
[I 240208 14:43:38 handlers:64] Start detecting changes
127.0.0.1 - - [08/Feb/2024 14:43:38] "GET / HTTP/1.1" 200 -
----------------------------------------
Exception occurred during processing of request from ('127.0.0.1', 46484)
Traceback (most recent call last):
  File "/usr/lib/python3.10/socketserver.py", line 316, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python3.10/socketserver.py", line 347, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python3.10/socketserver.py", line 360, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/kaze/www/kbd/kalamine/kalamine/server.py", line 65, in __init__
    super().__init__(*args, **kwargs)
  File "/usr/lib/python3.10/http/server.py", line 668, in __init__
    super().__init__(*args, **kwargs)
  File "/usr/lib/python3.10/socketserver.py", line 747, in __init__
    self.handle()
  File "/usr/lib/python3.10/http/server.py", line 433, in handle
    self.handle_one_request()
  File "/usr/lib/python3.10/http/server.py", line 421, in handle_one_request
    method()
  File "/home/kaze/www/kbd/kalamine/kalamine/server.py", line 93, in do_GET
    send(main_page(kb_layout), content="text/html")
  File "/home/kaze/www/kbd/kalamine/kalamine/server.py", line 37, in main_page
    <br /> {layout.meta['locale']}/{layout.meta['variant']}
KeyError: 'locale'

As a user, I’d like to generate angle-modded versions of a given TOML layout :

# by default, it would be a [ZXCVB] permutation with the LSGT key (a.k.a. ISO key)
kalamine make layout.toml --angle-mod

# xkalamine support would be neat as well
kalamine apply layout.toml --angle-mod
kalamine install layout.toml --angle-mod

An option to use another key than ISO would be nice to see (e.g. Backspace), especially with ANSI layout descriptors, but #31 has to be fixed first.

On Linux, kalamine layouts only work on a graphical environment. Supporting the TTY console (localectl’s VC) would be nice to have.

These projects could be helpful :

• https://github.com/legionus/kbd
• https://manpages.debian.org/stretch/console-setup/ckbcomp.1.en.html

Would it be possible to modify the terminator of 1dk to be a single character?

diff --git a/0_99_2/ergol.keylayout b/0_99_2/ergol.keylayout
index 3425634..fc4c137 100644
--- a/0_99_2/ergol.keylayout
+++ b/0_99_2/ergol.keylayout
@@ -1356,7 +1356,7 @@
   </actions>

   <terminators>
-    <when state="1dk"        output="*¨" />
+    <when state="1dk"        output="*" />
     <when state="grave"      output="`" />
     <when state="acute"      output="´" />
     <when state="circumflex" output="^" />

ergol.keylayout.txt

On an XOrg setup :

• install a 6-level layout such as Ergo‑L or Qwerty-Lafayette into /usr/share/X11/xkb/symbols/custom
• configure it along with a 4-level layout such as the French Azerty :

setxkbmap "fr,custom" -option grp:shift_caps_toggle

Both layouts work okay for the base and altgr layers, but the custom layout’s 1dk layer (= levels 5 and 6) is ignored.

Reversing the order works around this issue :

setxkbmap "custom,fr" -option grp:shift_caps_toggle

On an XOrg setup :

• install a 6-level layout such as Ergo‑L into /usr/share/X11/xkb/symbols/custom
• configure it along with X-included Bépo or Optimot 1.7.

Now 1dk act as a AltGr layer latch and not a 1dk-typo layer.

Hello!

Is there a user guide for people who want to make layouts?

What's the importance of specifying the geometry? (why does it matter to use ERGO or ANSI or ISO?)

What's the difference between using base + altgr keys vs. using the full key in the toml file? Does it change the signification of each corner in the keys in the layout? How so?

How are working dead keys? Are they always using "Compose" feature and nothing else? Does that mean that *μ always means "greek compose" somehow? I don't know if that exists though. Or should I provide the matching list of dead keys manually ?

Looking forward to playing with this!

When trying to list installed layouts with xkalamine list on Fedora 30, I'm getting the following deprecation warning and no list:

/usr/local/lib/python3.7/site-packages/kalamine/utils.py:45: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
return yaml.load(open_local_file(os.path.join('data', filename)))

Hi! Thanks for this fantastic project, I eventually made my own qwerty-intl variant with this, which is enough for me :)
However I struggled to make it, because I suspect the intl.yaml example is broken: for one thing, I had to change base to full. Fortunately, the prog example was working great, so I could copy that instead :)

Installing kalamine might be too cumbersome for some users, and I think a Python installer would be a better fit for most end-users.

It might be a bit of a hack but I think kalamine could pick some code from xkb_manager.py along with an XKB string to create a standalone installer, like the one used for Qwerty-Lafayette.

With this input file:

name: Alan
name8: alan
locale: fr
variant: alan
description: French (alan)
url: https://github.com/fabi1cazenave/qwerty-lafayette
geometry: ERGO
version: 0.0.0

base: |
  ╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
  ┆ ~   ┃ !   │ @   │ #   │ $   │ %   ┃ ^   │ &   │ *   │ (   │ )   ┃ _   ┆ +   ┆
  ┆ `   ┃ 1   │ 2   │ 3   │ 4   │ 5   ┃ 6   │ 7   │ 8   │ 9   │ 0   ┃ -   ┆ =   ┆
  ╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
  ·     ┃ B  │ M Û │ P Î │ O Ô │ W Œ ┃ Z   │ V   │ D   │ L   │     ┃ {   ┆ }   ┆
  ·     ┃   â │   û │   î │   ô │   œ ┃     │   ŭ │     │     │ *^  ┃ [   ┆ ]   ┆
  ·     ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
  ·     ┃ A À │ U Ù │ I É │ E È │ ; Ê ┃ C Ç │ T   │ S   │ R   │ N Ñ ┃ "   ┆ |   ┆
  ·     ┃   à │   ù │   é │   è │ , ê ┃   ç │   ™ │   ß │   ® │   ñ ┃ '   ┆ \   ┆
  ╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
  ┆     ┃ J   │ Y   │ X   │ : · │ K Æ ┃ ?   │ Q   │ G   │ H   │ F   ┃           ·
  ┆ *µ  ┃     │     │     │ . … │ k æ ┃** ` │   € │     │     │ f / ┃           ·
  ╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·

altgr: |
  ╭╌╌╌╌╌┰─────┬─────┬─────┬─────┬─────┰─────┬─────┬─────┬─────┬─────┰╌╌╌╌╌┬╌╌╌╌╌╮
  ┆     ┃   1 │   2 │   3 │   4 │   5 ┃   6 │   7 │   8 │   9 │   0 ┃     ┆     ┆
  ┆     ┃   1 │   2 │   3 │   4 │   5 ┃   6 │   7 │   8 │   9 │   0 ┃     ┆     ┆
  ╰╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
  ·     ┃   ¬ │   « │   » │   € │   ‰ ┃  *^ │  *¨ │   × │   ≠ │   ° ┃     ┆     ┆
  ·     ┃   ! │   [ │   ] │   $ │   % ┃   ^ │   & │   * │   = │   @ ┃     ┆     ┆
  ·     ┠─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┼╌╌╌╌╌┤
  ·     ┃   1 │   2 │   3 │   4 │   5 ┃   6 │   7 │   8 │   9 │   0 ┃     ┆     ┆
  ·     ┃   { │   ( │   ) │   } │   _ ┃   | │   + │   - │   " │   ' ┃     ┆     ┆
  ╭╌╌╌╌╌╂─────┼─────┼─────┼─────┼─────╂─────┼─────┼─────┼─────┼─────╂╌╌╌╌╌┴╌╌╌╌╌╯
  ┆     ┃   „ │   “ │   ” │   ÷ │     ┃     │   ± │   − │     │     ┃           ·
  ┆     ┃   ~ │   < │   > │   / │   \ ┃   ` │   # │  *µ │   : │   ? ┃           ·
  ╰╌╌╌╌╌┸─────┴─────┴─────┴─────┴─────┸─────┴─────┴─────┴─────┴─────┚ · · · · · ·

spacebar:
  shift:       "\u202f"  # NARROW NO-BREAK SPACE
  altgr:       "\u0020"  # SPACE
  altgr_shift: "\u00a0"  # NO-BREAK SPACE
  1dk:         "\u2019"  # RIGHT SINGLE QUOTATION MARK
  1dk_shift:   "\u2019"  # RIGHT SINGLE QUOTATION MARK

The dead key switch is not generated for the circumflex or greek in the main layer (the key given is simply *). This is the case for both the xkb and the keylayout files.

The readme is not clear on whether Wayland is supported. It says:

To apply a keyboard layout in user-space:

# equivalent to `xkbcomp -w10 layout.xkb $DISPLAY`
xkalamine apply layout.yaml

This has limitations: it doesn’t work on Wayland and the keyboard layout doesn’t show up in the Gnome keyboard manager. Besides, on some distros, media keys might stop working.

Pretty clear so far. But then it says:

The proper way to install a keyboard layout on Linux is to modify directly the files in /usr/share/X11/xkb. This is where xkalamine comes in:

sudo xkalamine install layout.yaml

Does "the proper way" mean it works for Wayland too? At first I thought so, but I found it doesn't work so I'm guessing Wayland is not (yet) supported. In any case, can we reword this section to make it clear?

The ae13/IntlYen and ab11/IntlRo keys still haven’t been identified for Windows (KLC) and macOS (keylayout).

The keylayout output seems to be okay (at least, nobody has complained about that so far…) but the KLC output is unusable by MSKLC because of those duplicates.

The page served by kalamine --watch should include a layout analyzer.

For a first iteration, we could reuse some JS from the Ergo‑L project ; in the longer run, there are some Rust analyzers worth using.

Ideally, Kalamine could download text corpus directly from appropriate sources on the net like the university of Leipzig, store them in ~/.config/kalamine and parse them to extract the common letters, bigrams, trigrams — which, again, has already been developed for the Ergo‑L project.

As mentioned in our KLC page, MSKLC has significant limitations — and many of them are related to the UI, not to the core program (kbdutools.exe). That’s the case for chained dead keys and AltGr+Spacebar combinations, for instance.

As far as I understand, the easiest way to work around this would be to generate a DLL directly with kbdutools and use MSKLC only to create a signed installer package.

It even looks like MSKLC can be automated somehow — kudos to @wismill for this one :

$destination="C:\the\destination\dir"
$klc_file="C:\some\klc\file.klc"
[System.Environment]::SetEnvironmentVariable("USERPROFILE", "$destination")
New-Item -Path "$destination" -ItemType Directory -Name "Documents"
& 'C:\Program Files (x86)\Microsoft Keyboard Layout Creator 1.4\MSKLC.exe' "$klc_file" -build

<x-keyboard> does a good job on most web pages, but an SVG output would be nice to have in order to embed keyboard layout drawings in other documents — PDFs, markdown, etc.

@Ced-C has provided a nice proof of concept here:
https://gist.github.com/Ced-C/6fbc2f1bc47a23dd572b0c65b98b1e53

And I started #46 to work on a kalamine implementation. I think it would be a good way to start hacking on kalamine, so I’m leaving this PR alone for a moment to let time to contributors to pick it up.

I think we only need one output SVG. It should display a good default view (base and shift layers, with AltGr and/or 1dk dimmed), and that SVG document should be fairly easy to tweak thanks to the root classes.