| Summary: | Kscreenlocker only uses screen locker theme from non-default Global Themes when run in testing mode | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreenlocker | Reporter: | doncbugs |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | major | CC: | kde, kde, nate, niccolo.venerandi |
| Priority: | HI | Keywords: | regression |
| Version First Reported In: | 5.26.1 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
doncbugs
2022-11-27 22:29:17 UTC
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. |