Plasma/screenlocker

From KDE Community Wiki
Revision as of 06:56, 21 October 2013 by Mgraesslin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Componentize existing lock screen

Portions of the current default unlock dialog UI needs to encapsulatedinto a QML component so that other QML lockers that wish to provide the same unlock UI but something different in behind it can do so easily. The "simple" unlocker then becomes a wallpaper that uses these components. In particular the unlock dialog and session switching need to be put into this component. Lockers will retain the freedom to not use these components, of course.

Replace Plasmoids on screensaver implementation

The current implementation of Widgets-on-screensaver will be dropped, replaced with a QML containment that also loads the unlock UI components. 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).

Drop xscreensaver support

It will mean one less code path to test in the locker and one less full screen window to deal with. it will also simplify the config UI considerably.

With QML2, we have full openGL so animated screen lockers can be implemented without any serious limit.

Create a few fancy lockers

To help prove the concept and give something back to the users who will be losing built-in xscreensaver support, create 1-2 fancy openGL lockers. This may be a great project for a GSoC or a university class.

Config UI

Lock screens will need to be able to provide an optional config UI. This UI should be done in QML and included in the same package as the lock screen theme itself. We will have desktop components at this point, so there is no barrier to using QML here.

Porting greeter QWidgets to QML

The greeter widgets (keyboard, password input, etc) need to be ported to QML. Right now GreeterItem and KeyboardItem use QGraphicsProxyWidgets, which do not exist in QML2. That means kxkb needs to provide a proper QML component and the kgreet plugins in libs/kdm/ will need to turned into QML bits. A complication is that kdm uses them as well ... so maybe some library duplication there, or we look at alternatives to kdm (e.g. lightdm w/QML)

Bring back useful config options

From the old KCM we need the options of "start automatically" and grace time for not requiring a password. Possible place might be powerdevil KCM as screen locking after some time of not using is power management related.