I have a keyboard with dual languages french and arabic, in Plasma keyboard settings I added both french and arabic layouts and french is the first one in the list, and I set my session to always start empty, if I select french layout then after rebooting it's reset to arabic.
Can reproduce on X11. Works on Wayland for me.
Medin could you confirm it works on Wayland?
(In reply to Andrey from comment #2) > Medin could you confirm it works on Wayland? I retested both on X11 and Wayland with 5.21.3 and set 3 layouts : fr, ara and alb (in the same order they were added in Plasma keyboard settings); the problem occurs on both X11 and Wayland, but not the same behavior : X11 resets to second layout (ara) while Wayland resets to first layout (fr).
Set your session to "Restore last session", and you should get layout saved at least on Wayland. Behavior your described is intended for Wayland session - layouts are only restored as part of your previous session.
(In reply to Andrey from comment #4) > Set your session to "Restore last session", and you should get layout saved > at least on Wayland. Behavior your described is intended for Wayland session > - layouts are only restored as part of your previous session. With "Restore last session" enabled, it works on Wayland but fails on X11, I don't think selected keyboard layout should only be restored when session is restored, because session state should include only the user's opened apps and not desktop settings.
It was just designed such way for Wayland, to not introduce separate option whether to save layout or not. Logically it's still belong to user's session.
Interesting. I guess it depends on whether you consider the current layout to be state or a setting. State is safe to reset in a clean session (that's the point), but settings are not. This bug report is itself evidence that at least one person considers the current layout to be a setting, not state. I don't personally have an opinion because I don't use the clean session feature so I don't know what users expect from it. Let's use this bug report to track that, and get a new bug report for the X11 use case, which seems to be going through a different code path.
(In reply to Nate Graham from comment #7) > I don't know what users expect from it. As someone who logout and reboots many times my laptop, I'm often (not always) getting serious slowness from "Restore last session" option especially if I have many opened apps, sometimes the splash boot is stuck with loading icon, and when I run coredumpctl I found many crashes of kglobalaccel5, kalarm and akonadi* services. So the only clean solution that solves for me all those bugs is to have always new empty session. Even if sometimes restoring session works I don't see any significant speed difference compared to new empty session (I think due to having HDD).
Okay, so you're using that setting to work around bugs. We should just fix those bugs instead. :)
(In reply to medin from comment #8) > when I run coredumpctl I found many crashes of > kglobalaccel5, kalarm and akonadi* services. Could you file an separate issue for that maybe? So we could sort it out if it's known issues or not. Backtraces from that coredumps could also be needed.
On X11 this MR should fix this behaviour. https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/416 Now, it loads the top most layout defined in kcms in "Empty session" case.
(In reply to Domenico Panella from comment #11) > On X11 this MR should fix this behaviour. > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/416 > > Now, it loads the top most layout defined in kcms in "Empty session" case. Empty session doesn't mean new user settings, so logically last chosen keyboard layout should be restored even for empty session like how desktop (wallpaper, panel layout, tray settings, widgets...) settings, sound & mic levels, brightness level... are kept for empty session
Medin, this is because the current layout was considered state and not a setting. The setting saves in the moment you change it (usually backed by KConfig object internally). The state saves when session saves, so happens only when you exit the session (and set it to be restored) or save it manually.
Medin's point that we don't reset sound and brightness for empty sessions actually points at those needing to be reset too, since those are state and not settings. Should we mark this as RESOLVED INTENTIONAL and re-open Bug 435191?
(In reply to Nate Graham from comment #14) > Medin's point that we don't reset sound and brightness for empty sessions > actually points at those needing to be reset too, since those are state and > not settings. That is what I was replying to. Put it differently: all that is backed by KConfig internally (volume, brightness etc.) - are settings and should save regardless of session management. The current layout is different beast - is doesn't need to be saved on every change (the same way you don't probably save Lock keys on every state change or window position on every resize/move) and logically belong to session. So different behavior of these two are intentional. I can agree the difference is subtle and I might be wrong here but at least it's my point currently :) > Should we mark this as RESOLVED INTENTIONAL and re-open Bug 435191? I think so.
What's classified as settings and what's classified as state can be subtle, but it's not correct to make the distinction according to an invisible technical implementation, because the user has no understanding of the implementation and it will not seem predictable to them. In general, state is safe to discard with minimal user annoyance, whereas settings should always be persistent no matter what. Examples of state: - Open programs - Location of windows - Volume level Examples of state: - User-changed settings - Arrangement of screens - Widgets, wallpaper, etc
I say that the keyboard layout defined in kcms are the settings. If i change the layout via applet/shortcut then it changes from a setting to a state because i am not doing that in kcms.... it's only a temporary operation, as such it has to be saved if we set to save the session otherwise we load the topmost layout defined in kcms. I agree with Andrey thought.
The idea should be that everything we do in kcms is a setting, everything we do via applet/shortcut should be a change of the setting state, as such keeping it or not if we set to save the session or not.
(In reply to Nate Graham from comment #16) > In general, state is safe to discard with minimal user annoyance, whereas > settings should always be persistent no matter what. I would say if the data to be saved is meaningful only in context of particular app instance, then it can be considered state. And all that belongs to a system as a whole - is a settings. > Examples of state: > - Open programs > - Location of windows > - Volume level In this example, Volume level might be considered state if we speak about per-app volumes. For physical amp volume of you sound card, it might be better to treat it as a setting and handle as such.
(In reply to Domenico Panella from comment #17) > I say that the keyboard layout defined in kcms are the settings. > If i change the layout via applet/shortcut then it changes from a setting to > a state because i am not doing that in kcms.... > it's only a temporary operation, as such > it has to be saved if we set to save the session otherwise we load the > topmost layout defined in kcms. > I agree with Andrey thought. Makes sense. The order of layouts would be a setting, so that the first one in the list is the default. But the *current* one would be state.