KScreenlocker Theme API

[Nate Graham]

I think it's okay to break 3rd-party themes if we have a fallback to 
Breeze, or some other known-working fallback theme like SDDM does. That 
would also fix https://bugs.kde.org/show_bug.cgi?id=433054, which seems 
important. It doesn't rub me right to have critical screen unlock 
functionality breakable by 3rd-party themes.

Nate


On 8/10/21 5:37 AM, David Edmundson wrote:
> We have an open MR that wants to break the API of kscreenlocker greet:
> https://invent.kde.org/plasma/kscreenlocker/-/merge_requests/29
> 
> Effectively this would make any LNF package that shipped a custom
> screenlocker to break. Currently the proposal just breaks, but I think
> we can make it fall back to breeze or the in-built fallback.
> 
> The idea behind the MR is sane and something we probably do want to do.
> 
> I also really want to fix up the theme API used by kscreenlocker at
> some point. It was written when we were new at QtQuick and it
> interacts with the main code via random context properties and
> searching for random properties on the root item. It unquestionably
> needs changing at some point.
> 
> My personal feeling is that if we can combine the two tasks it would
> be worth doing now.
> We never actually documented how to write custom lockscreens, so we're
> not really breaking any promises.
> 
> But it's a big enough change that it needs group approval.
> 
> David
>