Make PLM dynamically change appearance configuration based on selected user

Hey everyone,

Now that Plasma Login Manager is officially out in the wild as of 6.6, I’ve been thinking about how we can move past the limitations we had with SDDM. Specifically, I’d love to see the login screen dynamically reflect the selected user’s desktop environment before they even log in.

The Idea

Right now, the login screen is a bit of a “neutral” zone. It’s functional, but it feels disconnected from the actual Plasma desktop if you have any custom themes configured. I’m proposing that when a user selects their name from the list, PLM instantly switches its “aesthetic stack” (wallpaper plugin, color scheme, cursors, icons, etc. etc.) to match that specific user’s configuration. It would provide immediate, unmistakable visual confirmation of who is logging in before they type their password and make the transition into the session feel much more seamless.

Addressing the Technical Hurdles

I know the two biggest roadblocks for this kind of thing have always been encrypted home directories and UI performance. To get around those, I’m envisioning a staged approach through the KCM:

  • The Bridge: We could add a toggle in the Login Manager settings module for users to opt in that “exports” a copy of their aesthetic assets to a system-accessible, read-only cache (e.g., /var/lib/plasma-login-manager/user-previews/).

  • Security: This avoids the need for the login manager to try reading from an encrypted /home folder.

  • Performance: Because these assets are cached in a system directory, PLM can swap them instantly without any disk-polling lag when you click a username.

Why now?

Since the team is no longer keeping SDDM on life support and has full control over the PLM codebase, this feels like the right time to talk about “First Impressions.” It turns the login process into a personalized portal rather than just a gatekeeper.

I’ve already submit a feature request for this (517320), but I wanted to bring it here to see what everyone else thinks. Does this feel like a natural evolution for Plasma? Are there some edge cases I’m overlooking?

Let’s discuss.

2 Likes

Could also be interesting to have the user’s keyboard layout and locale settings.

How would the “export” work if the location is read-only?

You’d probably still not want to load all assets of all users at start time, so the location does not matter a lot.

The more important aspect is not needing access to the user’s home directory

Fair point, I definitely phrased that poorly. When I said “read-only,” I meant it from the perspective of the user’s session.

My thought was that the KCM would use a KAuth helper (running with root/system privileges) to perform the export to /var/lib/plasma-login-manager/.

So, while the directory would be ‘read-only’ for the standard user (preventing unauthorized changes to other users’ configurations), it would be writable by the system service during that specific ‘Apply’ action in the settings. This keeps the assets safe, system-accessible, and—most importantly—outside the encrypted home.