RMLVO: support for applying option on specific layout index

[wismill]

See the corresponding xkeyboard-config issue.

The idea would be to be able to have a suffix per option, such as it applies only to some layout indexes.

Some preliminary ideas:

• , cannot be used as a suffix delimeter, as it is the option separator.
• : should not be used as a suffix delimeter, e.g. eurosign:e:2, because it is ambiguous.
• @ seems an interesting candidate; it clashes with nothing currently. E.g.: eurosign:e@2
• We should embrace Modern rules #362 and introduce @all, @first, etc. as well.
• We need DE devs to be implied, if we want a proper UI to be developed.
• There should be none or only very limited breakage, as it is the “compiled” keymap that is shared by the compositor with the apps, not the RMLVO values.

[whot]

Or make this a proper builder API so we don't have to worry about magic syntax. Something like:

rmlvo = xkb_rmlvo_new();

layout = xkb_rmlvo_layout_new("us");
xkb_rmlvo_layout_set_variant(layout, "dvorak");
xkb_rmlvo_layout_add_option("banana");
xkb_rmlvo_layout_add_option("orange");
xkb_rmlvo_add_layout(layout);

// repeat for layout 2 if need be

keymap = xkb_keymamp_new_from_rmlvo(context, rmlvo, flags);

or, for those who really like varargs:

layout = xkb_rmlvo_layout_new("us",
        XBK_RMLVO_VARIANT, "dvorak",
        XKB_RMLVO_OPTION, "banana",
        XKB_RMLVO_OPTION, "banana",
        XKB_RMLVO_END);

sd-bus uses the latter extensively but in your case I think the first approach is better.

No backwards compat issue either since it's a new API :)

[wismill]

I like this idea (without varargs)! But the new suffix syntax would still be useful for CLI, wouldn't it?

We need to figure out how to handle this in xkeyboard-config. The standard way is to duplicate for each layout index. #362 may come handy. Or we may implement an expection in rules resolving for the new API.

[whot]

I like this idea (without varargs)! But the new suffix syntax would still be useful for CLI, wouldn't it?

Might be better to dream up a new syntax. after all the xkbcommon cli isn't quite as wide-spread through config files everywhere as e.g. setxkbmap's.

A rather lame but easyn enough approach would be:

xkbcli compile-keymap --layout-1 us --variant-1 dvorak --option-1=banana --option-1=orange

Since we only have 4 groups that's not impossible to implement.

[wismill]

We really need to add short CLI arguments 😅.

And we need to keep #37 in mind.

[whot]

We really need to add short CLI arguments 😅.

heh, sort-of but I usually get angry when I see scripts using short args, forcing me to decypher what -xDRtdg means in that context... that's why I'm quite a fan of adding long args only, these days Ctrl+R should get you 80% of the way there anyway :)

And even if we want more than 4 groups/layouts, well, we're not going to run out of numbers, so --layout-256 for the truly bonkers can be added on demand ;)

[wismill]

And even if we want more than 4 groups/layouts, well, we're not going to run out of numbers, so --layout-256 for the truly bonkers can be added on demand ;)

Then we would need to change the args-parsing function or use a macro, because this will not scale.

Maybe add only a --index arg that overload the next arg, e.g.:

[…] --layout us,de --index 3 --layout es --option … --index 2 --option …

[whot]

what I don't like about --index arguments is that instead of each argument meaning exactly one thing, it's now a state machine that you need to remember and/or script correctly.

I'd have to look it up but there's a way you can expand a macro into more things so we can have a #define opt("--layout", 256) which then expands into the right getopt lines. Though unless we really want to support a ridiculous number of layouts it's easier to just type this out once and be done with it forever.

[wismill]

I think that supporting this feature properly would require to add support in rules files for option component with a layout index, e.g. option[2] = symbols.

However, since layout matches a single layout and layout[1] matches the first layout in a 2+ layouts config, we would not be able to maintain backward compatibility or consistency. So I would skip the digits indexes and implement #362 indexes directly:

• single, e.g. option[single]
• first
• later
• any
• a new value, auto, that implements the current behavior, e.g. option would be the same as option[auto].

But wait, it does not make sense for some options to be applied on specific layout indexes (e.g. types, compat, option that modify modifiers mappings). So we would also need to communicate this via the XML registry file.