https://bugs.kde.org/show_bug.cgi?id=524904
Bug ID: 524904
Summary: Add support for standalone, user-installable
KScreenLocker theme packages
Classification: Plasma
Product: plasmashell
Version First master
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: Screen locking
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: 1.0
KScreenLocker currently loads its QML user interface from the active
Plasma/Shell package:
contents/lockscreen/LockScreen.qml
This makes it impossible to install and select a custom lock-screen interface
independently from the Plasma desktop shell.
I would like to propose a dedicated KPackage type for standalone KScreenLocker
themes, for example:
KScreenLocker/Theme
Current behavior
KScreenLocker loads a Plasma/Shell package and resolves its lock-screen entry
point through:
package.fileUrl("lockscreenmainscript");
The lockscreenmainscript key is defined by the Plasma/Shell package structure
and maps to:
contents/lockscreen/LockScreen.qml
The --shell command-line option can select another shell package, but only in
testing mode.
For normal use, selecting a partial shell package also changes the shell used
by the entire Plasma session. This can prevent desktop views, panels,
wallpapers, widget configuration, and other shell components from loading.
As a result, distributing a custom lock screen currently requires one of the
following unsafe or inconvenient approaches:
- replacing the complete Plasma shell;
- overwriting files from org.kde.plasma.desktop;
- maintaining a user-level overlay of the default shell;
- patching distribution-owned files under /usr/share/plasma/shells/.
Proposed solution
Introduce a dedicated KPackage structure owned by KScreenLocker:
KScreenLocker/Theme
A theme package would have the following minimal structure:
example-theme/
├── metadata.json
└── contents/
└── lockscreen/
├── LockScreen.qml
└── additional QML and assets
Example metadata:
{
"KPackageStructure": "KScreenLocker/Theme",
"KPlugin": {
"Id": "org.example.lockscreen",
"Name": "Example Lock Screen",
"Description": "An example KScreenLocker theme",
"Version": "1.0.0",
"License": "GPL-2.0-or-later"
},
"X-KScreenLocker-APIVersion": "1"
}
The package structure could map:
mainscript -> contents/lockscreen/LockScreen.qml
Packages could then be installed independently:
kpackagetool6 \
--type KScreenLocker/Theme \
--install ./example-theme
Theme selection
A new setting could be added to the Greeter group in kscreenlockerrc:
[Greeter]
Theme=org.example.lockscreen
An empty value would continue to use the standard Plasma lock screen.
The Screen Locking KCM could list installed packages and allow the user to:
- select a lock-screen theme;
- inspect its name, author, version, and preview;
- test it safely in a window;
- restore the default Plasma lock screen.
A later change could add KNewStuff integration through a “Get New Lock Screen
Themes…” button.
Backward compatibility and fallback
The current Plasma lock screen should remain the default.
The proposed loading order could be:
1. Load the selected KScreenLocker/Theme package.
2. If it is missing, invalid, or incompatible, load the lock screen from
org.kde.plasma.desktop.
3. If that also fails, use KScreenLocker’s embedded fallback theme.
The existing --shell testing option could remain temporarily available for
backward compatibility. A dedicated option could be introduced:
kscreenlocker_greet \
--testing \
--theme org.example.lockscreen
Security considerations
The authentication process must remain entirely controlled by KScreenLocker.
A theme should only provide the visual interface and interact with a documented
host API. It must not be able to report authentication success or unlock the
session by itself.
The implementation should preserve the following guarantees:
- PAM authentication remains managed by KScreenLocker;
- an invalid or crashing theme always activates a safe fallback;
- terminating or crashing the theme never unlocks the session;
- network access remains disabled in the greeter;
- password, fingerprint and smart-card authentication continue to work;
- multi-screen, suspend, hibernate and user-switching behavior remain
supported.
A versioned KScreenLocker QML API would be preferable to exposing or
standardizing SDDM-specific objects.
Motivation and use case
Projects already exist that provide matching login and lock-screen interfaces.
SDDM themes can be installed independently, but equivalent KScreenLocker
interfaces cannot.
We created a proof of concept that adapts an SDDM-oriented QML theme to
KScreenLocker through a compatibility shim. It works when launched with:
kscreenlocker_greet \
--testing \
--shell io.github.darkkal44.qylock
However, activating the package permanently requires selecting it as the
complete Plasma shell, which can cause the desktop, panels, and wallpaper to
disappear.
A standalone package type would allow custom lock screens without modifying or
replacing the rest of Plasma.
Suggested implementation scope
A first implementation could include only:
- the KScreenLocker/Theme package structure;
- a configurable theme identifier;
- loading the selected package in the greeter;
- compatibility and API-version validation;
- fallback to the standard Plasma lock screen;
- a --testing --theme command-line option;
- automated tests for invalid and missing packages.
The graphical selector and KNewStuff integration could be implemented
separately.
Expected result
Users should be able to install a package containing only its metadata and
contents/lockscreen/, test it safely, and select it as their lock-screen
interface without changing the Plasma desktop shell or affecting their panels
and wallpaper.
--
You are receiving this mail because:
You are watching all bug changes.
