SUMMARY From what I understand, something fairly major happened around Plasma 5.24-5.25 which changed the way the lockscreen (not SDDM) worked, though I'm not clear on what happened or how to fix it. It may have had to do with multi-monitor support. When using older Global themes that include a lockscreen theme, the lockscreen seems to use the default Breeze theme, rather the included one. I assumed that the theme I was using was broken, but when run with the `--testing` flag and manually specifying the theme, it opens. STEPS TO REPRODUCE 1. Install the Willow Desktop [beta] Global Theme through System Settings 2. Apply the theme's Appearance settings 3. Lock the screen 4. Observe the default lockscreen 5. Run kscreenlocker and specify willow's theme (e.g. `/usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --testing --theme org.kde.willow-light.desktop`) 6. Observe Willow appear correctly in a preview window OBSERVED RESULT The default Breeze lockscreen is seen with the Sleep option under the password input field. Willow puts power settings in the bottom right corner of the screen. When run with --testing, Willow appears correctly, but the actual lockscreen does not show the theme. EXPECTED RESULT The Willow lockscreen appears. Or, at least provide some clue of incompatibility when run with kscreenlocker. SOFTWARE/OS VERSIONS Operating System: KDE neon 5.26 KDE Plasma Version: 5.26.1 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 5.15.0-52-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION I have noticed that the updated Nova themes seem to have fixed the problem.
I can confirm this.
It's most likey this https://invent.kde.org/plasma/kscreenlocker/-/blob/master/greeter/greeterapp.cpp#L195 the qml api changed so this was intrdouced
Run it with QT_LOGGING_RULES="kscreenlocker_greet=true" to get debug output if not visible by default.
$ QT_LOGGING_RULES="kscreenlocker_greet=true" /home/nate/kde/ usr/lib64/libexec/kscreenlocker_greet kscreenlocker_greet: Greeter is starting up. kscreenlocker_greet: Lockscreen QML outdated, falling back to default kscreenlocker_greet: [PAM] Starting... file:///home/nate/kde/usr/share/plasma/wallpapers/org.kde.slideshow/contents/ui/main.qml:66: TypeError: Property 'setAction' of object ScreenLocker::WallpaperIntegration(0x5660a0) is not a function kf.kirigami: Failed to find a Kirigami platform plugin kscreenlocker_greet: Start auth Locked at 1669926401 kscreenlocker_greet: "Place your right index finger on the fingerprint reader" kscreenlocker_greet: Auth done RC 0 > kscreenlocker_greet: Lockscreen QML outdated, falling back to default Seems suspicious.
So basically, we broke compatibility with all lock screen themes?
The API was changed to support the finger unlocking IIRC, see https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/29 and https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/59
...So basically, we broke compatibility with all lock screen themes?
Yes.
3rd parties can make the relevant changes and bump their lnf API to v2.
Well that's a shame. It's not ideal to knowingly breaking compatibility before Plasma 6 without any external communication to theme developers or acknowledgement in the UI when a theme is incompatible; this is the kind of thing that we complain about the GNOME people doing. Let's try to do better in the future.
Can I refer you to *your own emails* on plasma-devel Aug 10th.
Assuming you're talking about https://mail.kde.org/pipermail/plasma-devel/2022-August/122758.html, that's a case where intentionally braking compatibility was a calculated risk to un-break KRunner completely in certain cases (there was no fallback if the custom KRunner styling broke, as there is with the lock screen). I'm not aware of any complaints about that change, probably because the ability to theme KRunner was a rather hidden thing and most themes did not make use of it. Whereas the ability to theme the lockscreen is much more commonly used in themes. Too late now though; I can send an email to the general community notifying people that Plasma theme authors need to update their lockscreen code. Do we have any documentation regarding the differences between the V1 and V2 APIs that I can point them to?
No, this one: https://mail.kde.org/pipermail/plasma-devel/2021-August/120564.html >Too late now though; I can send an email to the general community notifying people that Plasma theme authors need to update their lockscreen code. It's been ages since it changed (5.25?) so it seems rather pointless. > Do we have any documentation regarding the differences between the V1 and V2 APIs that I can point them to? We don't have any documentation on any of the LNF paths.
It was indeed ages ago from my goldfish memory brain since I have no memory of that. Thankfully the mailing list history does! Hopefully I did remember to follow up on what I said I'd do and notify theme creators. Oh well, what's done is done now.