some thoughts on screensavers in Plasma Workspaces 2

[David Edmundson]

On Sun, Jan 13, 2013 at 7:25 PM, Martin Graesslin <mgraesslin at kde.org> wrote:
> On Sunday 13 January 2013 19:48:48 Aaron J. Seigo wrote:
>> hi ..
>>
>> side note 1: i've taken to refering to "future releases of Plasma Worskpaces
>> that will use Frameworks 5 with libplasma2, Qt 5.1+ and QtQuick2" as Plasma
>> Workspaces 2 (PW2) inside my head. if anyone has a better idea, speak up
>> before it becomes a commonly used term :)
> sounds good to me. In my last mail I referred to it as "Plasma 2".
>> a) drop xscreensaver support altogether.
> +1
>> c) the current implementation of Widgets-on-screensaver is dropped
>> completely. it woudl be replaced with a QML containment that also loads the
>> unlock UI. this could in theory even be provided as a QML component itself
>> so other unlockers could have widgets. this path means lockers will need to
>> advertise whether or not they support widgets (default should probably be
>> "yes" in such a case)
> +1, keep in mind that currently we don't default to the widgets-on-
> screensavers due to long loading and high probability of screen locker loads
> after system comes from suspend to RAM.
>
> I hope that the startup time of a shell get's better with PW2 - especially
> being able to delay loading of elements through a QML LoaderItem and better
> threading should improve the situation. Nevertheless it has to be a design
> goal to have more or less instant locking. If the widgets are not loaded I
> don't care as long as there is at least the background item loaded.
>>
>> something else we'll run into:
>>
>> the unlock greeter needs to be ported to QML properly. right now and
>> GreeterItem and KeyboardItem use QGraphicsProxyWidgets and this will break
>> in QML2 w/scenegraph. that means kxkb needs to provide a proper QML
>> component and the kgreet plugins in libs/kdm/ will need to turned into QML
>> bits. the complication there is that kdm uses them as well ... so maybe
>> some library duplication there, or .. we look at alternatives to kdm.
> Back when I started to work on this I run into this issue. The keyboard item
> should not be that difficult but the kgreet plugin will be a nightmare. The
> complete logic is implemented inside a QWidget. The individual greeters just
> add further widgets to the base widgets. My fear is that we have to start from
> a blank sheet of paper and given that it is security related I must say that I
> don't like it. I'm not sure whether we have any experts on security in the
> workspaces team?
>
> Random thought: we might have a look on whether we can do some re-usage of
> LightDM greeter bits. Maybe that's easier - David might give input on that.
>
I'd love to see some reuse. What you described is very similar to what
I'm doing in my lightdm greeter. Right now the authentication
components are rather hardcoded in the themes, however they're being
moved to being re-usable components between themes in my library
effectively doing what you described you want the lockscreen to have,
and following a very similar system to kgreet to show the correct
component for a given prompt.

However, reuse would still be rather difficult. LightDM does the
authentication itself so we don't use kcheckpass/the kgreet plugins in
our greeter. There are good reasons why it has to be this way.
To share code we would need half the code from kgverify.cpp that does
the PAM talking and tweak it to talk to the UI in the same way that
LightDM talks to my code, then you can copy&paste what I have.

I'll be sure to keep re-usability in mind whilst finishing the
development. (Slightly off-topic, I will be proposing for merging into
kde-workspaces very soon)

The real problem in all this is how terrible PAM is. It was designed
for simple text prompts on a console. All current UIs rely on parsing
text prompts, and matching text to turn into into something computer
understandable to then generate the correct UI.
Robert Ancell (the main LightDM backend guy) and I had once talked
about making a cross-desktop independent library that properly wraps
the PAM->UI process, though this got no further than
blueprints/discussions. It'd be great to revisit this, it's more work
up-front but overall would save everyone a lot of time.

Dave