On-the-fly keyboard layout changes? about labwc

[spl237]

Tested - works for me. Many thanks!

[stefonarch]

Take a look at the example file:

labwc/docs/environment

Line 14 in 6cf19d1

## If multiple layouts are used, specify the toggle-keybind using

Any option can be used among the ones listed here:
localectl list-x11-keymap-options | grep grp:

[spl237]

Ah - while that does indeed handle the on-the-fly switching between a predefined set of keymaps, it doesn't solve the actual problem I am having! If the user wants to change keyboard to one not previously defined - say switching from a US to UK keyboard layout because they have plugged in a new keyboard, or as part of an initial setup wizard where the user sets their keyboard layout before setting their password for the first time - it needs to be possible for the keyboard layout to be changed to any other layout on the fly.

[Consolatis]

We do read the environment file on reconfigure and also apply it to the environment so spawing new applications after that point will include the changes.

However, we do currently not re-create the xkb layout (nor the xcursor theme). I think there is an issue for that somewhere. It should be possible to implement, although it might become a bit finicky if combined with layoutScope=window as we only store the "group" modifier index per window. Thus if the new keyboard layout now suddenly changes their meaning (or even the count) things might get a bit quirky.

[spl237]

We do read the environment file on reconfigure and also apply it to the environment so spawing new applications after that point will include the changes.

Just tried that - it doesn't seem to work.
So if I have XKB_DEFAULT_LAYOUT=gb in ~/.config/labwc/environment and hence a GB keyboard layout, if I change that line to XKB_DEFAULT_LAYOUT=us, save the file and then run labwc --reconfigure in a terminal, I still get the GB keyboard layout on newly-opened applications thereafter.

It also doesn't seem to update the environment. If I do the above, close the terminal and re-open it and look at the value of XKB_DEFAULT_LAYOUT, it is unchanged.

[Consolatis]

if I change that line to XKB_DEFAULT_LAYOUT=us, save the file and then run labwc --reconfigure in a terminal, I still get the GB keyboard layout on newly-opened applications thereafter.

Right, because as said above we do not recreate the xkb state on reconfigure. env | grep -i layout should show the updated env var in a new terminal though. But that obviously doesn't help regarding the issue.

[spl237]

Right, because as said above we do not recreate the xkb state on reconfigure. env | grep -i layout should show the updated env var in a new terminal though. But that obviously doesn't help regarding the issue.

See my edited comment above - if I do exactly that, the environment variable hasn't updated for me in the new terminal.

[Consolatis]

Right, because as said above we do not recreate the xkb state on reconfigure. env | grep -i layout should show the updated env var in a new terminal though. But that obviously doesn't help regarding the issue.

See my edited comment above - if I do exactly that, the environment variable hasn't updated for me in the new terminal.

Just tested again with foot in a nested labwc session and for me that works. E.g. in ~/.config/labwc/environment: XKB_DEFAULT_LAYOUT=de,us -> XKB_DEFAULT_LAYOUT=de,nl -> labwc --reconfigure -> env | grep -i layout in the old terminal: de,us > spawning a new terminal: de,nl. Maybe in your case the terminal emulator uses some kind of master process that keeps its environment and uses it when spawning new instances?

[johanmalm]

We ought to support this. It's one of the few things that currently requires a compositor re-start to take effect.

Might be as simple as called keyboard_init() (minus the wlr_keyboard_group_create()) on reconfigure.
I'm not sure how we best handle view->keyboard_layout if indeed XKB_DEFAULT_LAYOUT has changed. Maybe we just set them all to 0?

[spl237]

Right, because as said above we do not recreate the xkb state on reconfigure. env | grep -i layout should show the updated env var in a new terminal though. But that obviously doesn't help regarding the issue.

See my edited comment above - if I do exactly that, the environment variable hasn't updated for me in the new terminal.

Just tested again with foot in a nested labwc session and for me that works. E.g. in ~/.config/labwc/environment: XKB_DEFAULT_LAYOUT=de,us -> XKB_DEFAULT_LAYOUT=de,nl -> labwc --reconfigure -> env | grep -i layout in the old terminal: de,us > spawning a new terminal: de,nl. Maybe in your case the terminal emulator uses some kind of master process that keeps its environment and uses it when spawning new instances?

OK, found what I was doing wrong! I wasn't thinking and was launching the new instance of the terminal from the taskbar, which is running as a different process from labwc itself, so has a different environment. If I launch the terminal from a labwc keyboard shortcut, the environment has updated as expected.

[spl237]

Might be as simple as called keyboard_init() (minus the wlr_keyboard_group_create()) on reconfigure.

Just tried that and it doesn't seem to work, but I could have been doing it wrong!

All I did was to add keyboard_init(g_server->seat) to the end of the reload_config_and_theme function in server.c, and to modify keyboard_init to have an "inited" flag so that wlr_keyboard_group_create was only ever called once.

Edit - digging about, I can see that the keymap generated in keyboard_init has changed to reflect the updated environment variable, so it looks as if using wlr_keyboard_set_keymap is having no effect for some reason.

[spl237]

A bit more fiddling suggests that should have been keyboard_init (&(g_server->seat)), but it still seems to make no difference; I can now see the environment variable changing in the terminal, but the terminal is still using the original keymap.

[spl237]

I've got this working - see above PR.