Multiple keyboard layouts about labwc

[stefonarch]

1. There is a workaround I'm using: https://github.com/stefonarch/LXQt-Wayland-files/blob/main/lxqt-panel.md#keyboard-statelayout-indicator

[Consolatis]

1. Is there a way to tell which keyboard layout is currently in effect?

For a wayland client with keyboard focus: yes (they do have the group index and the keymap which may include multiple layouts, indexed by the group index). For other clients, sadly not. There are workarounds like suggested by @stefonarch with the scroll lock indicator but that likely only works with 2 layouts configured.

There were thoughts about adding a keyboard indicator to the SSD but the issue there is that the name of the layout is not actually stored within the keymap. E.g. It would just say something like "English" or "German" rather than en or de. AFAIR that term could be looked up by parsing some system xkb files and mapped to the short form but that is quite a lot of complexity for a feature like this.

2. If the user has set three or more layouts (seems unlikely, but you never know), is there a way to immediately load a specific one without toggling through them in order?

Labwc allows configuring the keyboard state to be global or per window. So the infrastructure to set a specific layout automatically is already there but we only use it when the user configured the layoutScope to window.

3. Is the current layout retained across a reboot? If so where is it stored?

It isn't. And due to the added Reconfigure support for loading a new keymap we may actually reset the group index as well but it might only happen when the keyboard layout actually changed, I don't quite remember the details.

[tokyo4j]

I almost forgot Fcitx5 as another option for this.

Demo:

demo.mp4

[spl237]

To answer my own question 3), no, it looks as if on a reboot, the first keyboard in the list always loads.

[spl237]

Thanks for that.

It looks as if it should be possible to find the group code from a wayland keyboard event - if you run an application with WAYLAND_DEBUG=1, the group is the last digit in the output from the modifiers on an wl_keyboard event. Just trying to work out how to set up listeners etc so I can find that out when it happens...

[spl237]

Many thanks for that - I'm playing with a few things here to see if I can find something that works nicely.

If necessary, I can just create a plugin which manipulates the current keymap value in the environment; I've already got that working; but it would be nice to be able to use the correct mechanism if I can.

[johanmalm]

@spl237

Using multiple layouts myself, this is indeed something I have pondered and feel a Desktop Environment ought to support (which in this case requires the compositor to help).

I think there are three option:

1. Show the keyboard-layout on the server-side decoration (probably in the titlebar). Not entirely conventional, but it is an option.
2. Broadcast modifiers to unfocused clients (which means all clients would see the "group" from which the keyboard-layout can be deduced).
3. Establish an Wayland protocol (probably best approach but takes a long time, so is not particularly helpful in the short/medium term).

I've played with broadcasting modifiers before (i.e. sending them to all connected clients). IIRC the protocol is no clear on what should be done here. I think most compositors opt for not broadcasting, but we could optionally consider doing this anyway. See wlroots patch below. I think we could probably create the same behaviour on the labwc side (but haven't tried).

https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4496

See test-client below. If you run that in a terminal (with the above wlroots patch), it'll output the keyboard layout every time it changes even when the terminal is not in focus.

https://github.com/johanmalm/keyboard-layout

I'm not given this much consideration or testing, so there may be some unintended consequences like all clients "seeing" every press/release of the alt-key (which for example could activate the menubar in Firefox and similar).

One approach here could be to only broadcast modifiers to clients on an opt-in basis (i.e. we specify in rc.xml which un-focused clients should get it).

It might be possible to only broadcast modifiers when the group has changed. Please read this as a "wild" idea as I've not investigated that at all.

An upstream Wayland ext- protocol is probably the best long term solution for this, but I currently haven't got time to see that through. I'm happy to support something along the lines of what I've described above in the interim. Not discussed with other core devs so there might be angles I'm not considering.

[spl237]

@johanmalm

Thanks for that, Johan - very helpful.

I spent Friday trying to get our panel app to respond to keyboard modifier notifications, but failed miserably. I'm still not sure whether this is because I had messed up the code, or because it won't get said notifications when it doesn't have keyboard focus - but I wasn't getting the notifications even when it definitely did have keyboard focus, so I suspect the former. I'll have a look at your example app and see if I can spot where I have gone wrong.

If, as you say, an app would only get the relevant modifier notifications when it has keyboard focus - which does make sense - do you know why you can see those notifications if you enable WAYLAND_DEBUG for the app? I would have assumed that meant that the app was receiving those notifications, but I don't know if enabling debug just turns on all notifications by default?

One thing that might be useful that someone pointed me at was this - https://github.com/avarvit/wayfire-kbdd-plugin/tree/master - which is a Wayfire plugin that is used to enable a keyboard layout indicator in a wayfire panel - not tried using it myself, but there may be something there which can be integrated with labwc?

I'm still undecided on how to proceed on this. My plugin which just directly manipulates the keyboard settings in the environment file works well, but may cause confusion for users who expect the standard group switching to be doing this. What I shall probably do for now is to modify my mouse and keyboard settings app so it can set up an alternative layout and group toggling, and wait and see what develops in terms of Wayland extensions to better telegraph status back to the user.

[spl237]

I almost forgot Fcitx5 as another option for this.

Demo:

demo.mp4

That's useful - didn't know about that. So if nothing else, there is already a mechanism that can be used by people who urgently need this functionality - thanks!

[spl237]

If, as you say, an app would only get the relevant modifier notifications when it has keyboard focus - which does make sense - do you know why you can see those notifications if you enable WAYLAND_DEBUG for the app? I would have assumed that meant that the app was receiving those notifications, but I don't know if enabling debug just turns on all notifications by default?

Tested this again today, and I was wrong - you do indeed only see those modifier notifications while an app has focus.

[stefonarch]

With recent changes (reading environment on reload) this is a workaround for 2 or more layouts: https://github.com/stefonarch/LXQt-Wayland-files/blob/main/scripts/togglelayout

[ahesford]

Instead of rewriting files with sed, it would probably be cleaner to just keep separate files for each language and disable those not being used with a ".disabled" extension. That was the reason I required that environment files have a particular extension to be processed. 😄

[stefonarch]

Nice idea, will try to use this.
This here was a quick hack and I didn't consider the folder. Should work just having files like

us.env
ru
es

[Consolatis]

Note that this approach will not work with layout-per-window (unless you go really crazy and implement some daemon that listens to the foreign-toplevel-protocol and syncs the keyboard layout + reconfigure on any active window change).

[spl237]

Note that this approach will not work with layout-per-window (unless you go really crazy and implement some daemon that listens to the foreign-toplevel-protocol and syncs the keyboard layout + reconfigure on any active window change).

Just FYI, I believe this is exactly what someone has implemented for Wayfire - https://github.com/AlexJakeGreen/wayfire-kbdd-plugin

Not suggesting it is a good idea, but just in case it is useful!

[stefonarch]

Note that this approach will not work with layout-per-window (unless you go really crazy and implement some daemon that listens to the foreign-toplevel-protocol and syncs the keyboard layout + reconfigure on any active window change).

I know of this limitation, but with this script it's actually possible to have both as it changes just the first 2 letters, so with

XKB_DEFAULT_LAYOUT=it,ch
XKB_DEFAULT_OPTIONS=grp:caps_toggle,grp_led:scroll

when I execute the script I could get:

XKB_DEFAULT_LAYOUT=us,ch
XKB_DEFAULT_OPTIONS=grp:caps_toggle,grp_led:scroll

and still use capslock for having my per-window-layout. Just a side effect.

The point was more to be able to export the current layout to the panel if more than 2 are desired.

Starting to make a script for usingenvironment.dbut the script should also create or remove the files in that directory.