startplasmacompositor: If available, query org.freedesktop.locale1 for XKB defaults
ClosedPublic

Authored by fvogt on Dec 26 2017, 9:10 PM.

Details

Summary

kwin_wayland will then use those values to set the default keyboard layout
accordingly.

BUG: 388249

Test Plan

Ran startplasmacompositor, keyboard layout now set correctly and env
shows all XKB_DEFAULT_* variables set.

Diff Detail

Repository
R120 Plasma Workspace
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
fvogt created this revision.Dec 26 2017, 9:10 PM
Restricted Application added a project: Plasma. · View Herald TranscriptDec 26 2017, 9:10 PM
fvogt requested review of this revision.Dec 26 2017, 9:10 PM

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?

fvogt added a comment.Dec 27 2017, 1:03 PM

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.

fvogt added a comment.Dec 27 2017, 2:06 PM

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)

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.

In D9512#183207, @fvogt wrote:

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.

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.

In D9512#183207, @fvogt wrote:

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.

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.

graesslin accepted this revision.Dec 29 2017, 5:31 PM
This revision is now accepted and ready to land.Dec 29 2017, 5:31 PM
This revision was automatically updated to reflect the committed changes.