forked from Qortal/Brooklyn
62 lines
3.5 KiB
Plaintext
62 lines
3.5 KiB
Plaintext
Plasma and the Screensaver
|
|
==========================
|
|
|
|
There are three main pieces to the screensaver picture, two of which involve plasma.
|
|
first is lockprocess, which manages the other two. second is the [k|x]screensaver binaries which just draw
|
|
pretty pictures. third is plasma-overlay, which does the plasma stuff.
|
|
|
|
lockprocess
|
|
-----------
|
|
This process manages plasma and the screensaver binaries, and ensures that once the screen is locked
|
|
it *stays* locked until proper authentication is provided. It provides the unlock dialog too.
|
|
If a screensaver or plasma-overlay
|
|
crashes or becomes unresponsive, lockprocess will keep going, ensuring that a locked screen stays locked and can
|
|
still be unlocked by the user. It's as small as possible to keep the chances of it itself crashing very small.
|
|
The screensaver binaries are brought in via XEmbed, while communication with plasma-overlay happens
|
|
over dbus.
|
|
lockprocess also filters all keyboard and mouse events, passing them on to plasma-overlay as
|
|
necessary. if it suspects that plasma-overlay is dead (ie. dbus failure), it won't pass on events,
|
|
ensuring that the user never ends up with an unresponsive screensaver.
|
|
|
|
plasma-overlay
|
|
--------------
|
|
This process is a plasma shell; it has a corona and a simple view, and loads its own containment.
|
|
The containment used by plasma-overlay is very basic; just a customcontainment with a cashew
|
|
and applet handles.
|
|
|
|
the user can add applets, but not containments. there's configuration for transparency if you have
|
|
compositing, or wallpaper if not (random wallpaper slideshow is my poor-man's-screensaver). all
|
|
configuration and applet add/remove are disabled when the screen is locked.
|
|
|
|
it communicates with lockprocess over dbus. lockprocess will send it into an idle mode after a while
|
|
(where any events trigger the unlock dialog, and plasma-overlay uses a different transparency
|
|
setting), and tell it to go into active mode when there's activity again. when an unlock action in
|
|
plasma is activated, plasma-overlay asks lockprocess for permission, and lockprocess will ask the
|
|
user for their password (or whatever other authentication method).
|
|
|
|
when the screen is locked, plasma-overlay offers two actions to the user: leave screensaver and
|
|
configure widgets. the first is what you'd expect; you enter your password and all of lockprocess goes
|
|
away, letting you back into your desktop. the second is more like unlocking widgets in
|
|
plasma-desktop: it brings you into configuration mode where you can add, remove and configure
|
|
widgets. this config mode can also be reached from the screensaver kcm module. from config mode you
|
|
can exit at any time without entering a password; you can also re-lock the screen, of course.
|
|
|
|
if lockprocess vanishes from dbus, plasma-overlay will assume that it missed a signal to quit and
|
|
will commit suicide. :) this is intentional; I got sick of dbus race conditions leaving me with a
|
|
plasma-overlay hanging around if I moved the mouse just after the screensaver began to run.
|
|
|
|
security
|
|
---------
|
|
|
|
Plasmoids on the screensaver obviously present a security risk. this is being minimized as described
|
|
in the security document.
|
|
what makes it interesting is that we're less concerned with malicious
|
|
plasmoids and more with malicious (or mischievous) users; a locked screen left unattended should not
|
|
end up with goatse on it, or files deleted.
|
|
|
|
Future Work
|
|
-----------
|
|
* Multi-screen support would be awesome
|
|
* Plasmify the unlock dialog (either by using plasma theming or by having plasma-overlay run it)
|
|
|