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

Reply via email to