Neither of your example cases would be addressed by monitoring DBus for these messages. An installer will set some appropriate configuration to indicate the default locale, while the display manager should be setting environment variables to indicate the locale even before labwc launches.

The DBus message is relevant when a user updates the locale settings whole labwc is running, but monitoring DBus seems outside the scope of labwc. Unless there is a Wayland protocol that can be used for this purpose, I think your best bet would be to adapt the KWin or Sway helpers to monitor the bus, then write locale variables to ~/.config/labwc/environment and trigger a labwc reconfigure when locale messages are received.

Installers change the locale live in order to allow input to work as you progress through the install process.

Hi @Conan-Kudo
Thanks for bringing this up. I'm interested in exploring this as getting/setting keyboard layout is something we struggle with in a standardized way.
I don't know much about the topic.
Any idea what other clients use org.freedesktop.locale1 ?
We've probably got some soul-searching between the core devs because we've been clinging on to Wayland/wlr protocols only for IPC - but that's primarily to avoid custom IPC (which this isn't in my mind).

SDDM is another one, as the keyboard layout switching logic for Wayland is intended to use the locale1 interface too. And SDDM can be used with a variety of compositors, such as the default Weston, KWin (from KDE), Sway, and so on.

Fedora's Initial Setup tool is built on top of Anaconda and will also use this interface. I expect we'll see more of this sort of thing over time.

SDDM could also just set the env vars directly before launching the compositor. I get the point about installers and live environments though.

SDDM lets the user change layouts live for a multi-user situation.

Here's a downstream request from @jkonecny12 for us to support this with Fedora LXQt (which is currently planned to use labwc for Wayland LXQt): https://pagure.io/fedora-lxqt/SIG/issue/4

I don't think we want to add dbus support to labwc.

I agree with what @ahesford suggested above, this seems to be the best solution to the issue for me as well:

I think your best bet would be to adapt the KWin or Sway helpers to monitor the bus, then write locale variables to ~/.config/labwc/environment and trigger a labwc reconfigure when locale messages are received.

With labwc >= 0.7.1 that should allow changing the keyboard layout live.
When using labwc 0.7.2 (current master), Instead of using ~/.config/labwc/environment directly you could also use something like ~/.config/labwc/environment.d/keyboard_layout.env to not mess with user configs.

CC @stefonarch @tsujan

Just displaying layouts in use is still hacky though.

And how am I supposed to do these triggers when the layout change is being requested, especially at the display manager level where I don't have anywhere to run anything?

And how am I supposed to do these triggers when the layout change is being requested, especially at the display manager level where I don't have anywhere to run anything?

@Conan-Kudo - Do you have the means and ability to explore doing a script yourself for comment/discussion (like the sway one)? Or are you looking for one of us to write it?

I haven't used SDDM for years and it would take me a little while to get the right setup to experiment, so if you can start it off that would be cool.

I don't know enough about this to answer your question. Do you know what the sequence of events is? Am I right in thinking that SDDM starts the compositor before it sends the dbus message about keyboard-layout? If so, could we run the script from ~/.config/labwc/autostart and just produce some logging in first instance to see what's going on? So, copy locale1-xkb-config modify it to print to stdout rather than doing the sway IPC and then re-direct that to some logfile.

Just displaying layouts in use is still hacky though.

@stefonarch Suggest we try to modifier-broadcasting approach first as that's likely to work and avoids custom IPC.

I'm probably capable of writing a script, what I'm concerned about is figuring out how to make it so the single exec limitation for sddm lets me have a labwc that responds to when the setting changes in locale1. I guess I need some kind of async listener thing wrapping the execution of labwc itself, since labwc can't do it?

I think it should be enough to simply have a dbus client script in ~/.config/labwc/autostart that on startup fetches the current locale and then listens to changes. On startup and each change event it would then update ~/.config/labwc/environment (or with the master branch ~/.config/labwc/environment.d/keyboard.env) and send a SIGHUP to labwc (manually via kill -s SIGHUP $LABWC_PID or via labwc --reconfigure)

but that would take down the environment, wouldn't it?

but that would take down the environment, wouldn't it?

No. It just re-loads rc.xml and environment. When reading the latter is just does some setenv() based on the key/value pairs in the file.
...and it updates the keyboard with the value of XKB_DEFAULT_LAYOUT (which is the variable we need to get the script to set).
There may be some other keyboard related environment variables we want to tweak too, but let's start with layout.

Is it possible to tell labwc to look in a specific directory for configuration instead of $HOME/.config/labwc? I can't exactly use this location for labwc for the sddm greeter as the greeter loads with a user that lacks a home directory at all.

Is it possible to tell labwc to look in a specific directory for configuration instead of $HOME/.config/labwc? I can't exactly use this location for labwc for the sddm greeter as the greeter loads with a user that lacks a home directory at all.

There is a labwc -C option. sddm uses /var/lib/sddm/ as home dir.
#1860