kwin_wayland will then use those values to set the default keyboard layout
accordingly.
BUG: 388249
graesslin |
Plasma |
kwin_wayland will then use those values to set the default keyboard layout
accordingly.
BUG: 388249
Ran startplasmacompositor, keyboard layout now set correctly and env
shows all XKB_DEFAULT_* variables set.
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
In general OK. What I don't like is that it adds five blocking dbus calls in the system startup for a fallback. Any chance to get the queries async?
It's not really a fallback. It'll be used until the user specifies a keyboard layout manually in the configuration.
locale1 is pretty much guaranteed to be available at that point and as the variables have to be set for kwin_wayland, there's not much that can be changed there AFAICT.
This could also be done in kcminit phase 0, it's a bit later and can then be done with slightly more stuff in parallel - also it'd be C++ so you can at least send all 4 DBus requests before blocking on the first.
As long as you update both the DBus environment and the klaunch environment, everything else will then inherit it.
(kcms/input/main.cpp has an example of that)
It'll be used until the user specifies a keyboard layout manually in the configuration.
Given we have the user specified stuff already, what's the downside in just make activate the locale default if the user hasn't set one.
Not kwin_wayland, which is the only process the variables need to be set for.
It would be possible to just ignore those environment variables completely and tell kwin the layout over dbus with org.kde.Keyboard.
However, only KWin knows that the user didn't specify a custom layout, so just relaying the locale1 properties to kwin during autostart won't work.
IMO this is the simplest and cleanest way to achieve this.
Actually it's not only KWin knowing that. KWin just reads a kconfig, we can do the same in the script and thus do the dbus calls only if no config is set.
Sure.
It would then change the behaviour though: The system-wide keyboard configuration is then written into the user's config and system-wide changes won't have any effect afterwards.
With this (or done within kwin), this only happens if the user explicitly configured the layout.