Define layout label for XKB (Linux) in metadata

[ariasuni]

Fctix5 (maybe others?) uses (it’s the only option for this feature) the <shortDescription> field in the evdev.xml as the label for the layout in the systray (usually it’s the ISO 3166-1 alpha-2 code for the language the layout is associated with, that is fr in the case of Ergo-L for example).

See fcitx/fcitx5#1555 (comment)

I would like this feature to be documented but I don’t know how or where I should do that so I would like some guidance on that matter.

[fabi1cazenave]

Hi, thanks for the patch and the background information.

If I understand your message correctly, the <shortDescription> field could be filled with the current locale metadata, is that right?

My concern here is that I feel like we already have a lot of almost identical metadata to describe the same thing, and this looks like one of such cases.

If there’s a good reason for this <shortDescription> field to not be the current locale field, it will be (more than) time to think of platform-specific data — but we could land your PR as is and work on that in another one.

[ariasuni]

If there’s a good reason for this field to not be the current locale field, it will be (more than) time to think of platform-specific data […]

Well, as I explain in the linked issue, I have three keyboard layouts for which I used different (systray & OSD notifications) labels when I used KDE directly because there’s a UI for that, but Fcitx5 uses this field instead.

I am in no rush to merge this, and it would make a lot of sense to have platform-specific-data (it can just be something like layout.metadata.platform.xkb.short_description for example, right?).

[fabi1cazenave]

it can just be something like layout.metadata.platform.xkb.short_description for example, right?

Exactly.

If you’re willing to work on it in a separate PR, that would be very appreciated, otherwise I’ll do my best to do it in the next week. Right now, most of the non-trivial layout.metadata.* fields are platform-specific and poorly named, this would be a good opportunity to clean that up and make a fresh release.

[fabi1cazenave]

I would like this feature to be documented but I don’t know how or where I should do that so I would like some guidance on that matter.

Right now, the documentation is mostly in the generated file:

uv run kalamine new test.toml

# kalamine keyboard layout descriptor
name        = "qwerty-custom"  # full layout name, displayed in the keyboard settings
name8       = "custom"         # short Windows filename: no spaces, no special chars
locale      = "us"             # locale/language id
variant     = "custom"         # layout variant id
author      = "nobody"         # author name
description = "custom QWERTY layout"
url         = "https://OneDeadKey.github.com/kalamine"
version     = "0.0.1"
geometry    = "ISO"

This TOML header is defined in kalamine/help.py.

[ariasuni]

If there’s a good reason for this field to not be the current locale field, it will be (more than) time to think of platform-specific data […]

Well, as I explain in the linked issue, I have three keyboard layouts for which I used different (systray & OSD notifications) labels when it was KDE that handled my layouts directly because there’s a UI for that, but Fcitx5 uses this field instead (and Fcitx5 – or IBus – is kind of required to use custom dead keys for Electron apps under Wayland).

I will be busy in the next few days, and it would make a lot of sense to have platform-specific-data first (then), and then I would rework this PR to add support for this particular option.