Some might have already read about it: we are currently working on a new screen locker. The old implementation is mostly a hack around X. There is the lock window which tries really hard to be the top most window. Obviously this does not often work, especially as the whole framework is way older than Compositing.
Too often I have come back to my system or resumed from suspend and seeing my windows shine through. Or seeing some notifications on top of the screen locker. We decided to change that and solve it once and for all in a proper way by putting security first and moving the screen locker into the Compositor.
The Compositor controls the rendering, so it can ensure that nothing gets above the screen locker. When we have the compositor being responsible for the screen locking we also get nice fading from and back to the desktop for free.
My initial idea was to just move the screen locker to KWin but not changing the unlock dialog. But now I started to play around with QML and need your help:
The new way unfortunately conflicts with the existing screen savers. They are almost 20 years old and we have problems to keep support for them. At the moment we decided that if you have a screen saver configured the old implementation will be used with all the security issues. But we are not yet sure what to do in 4.9. As we use QML it would be possible to write new screensavers in QML. This would allow us to keep the improved security and to only need one code path. But we are unsure how our users will react on removing the X Screen Savers. To find that out we set up a poll on forum.kde.org and I would like to ask you to participate. This will help us to define our next steps.
The new screen locker will also be used by the first version of Plasma Active, which will be released in a few days. There we use the same architecture but ship a different QML file which does the unlocking without needing a password (we only want to protect for unwanted touch events). This shows that it is possible to exchange the QML files for custom screen savers.
Moving the screen locker into KWin has also more security advantages in addition to the protected screen content. Of course KWin is very crash resistant. So if the screen locker crashes KWin will just restart and lock the screen again. Even if KWin would completely fail it is more secure than before as without a window manager you can hardly do anything with the system. Also we have finally a real solution for the most often reported KWin crash of all time: the Intel driver crashes KWin when the screen saver is used due to unredirecting the fullscreen saver window. With the locker being a KWin effect it is impossible to trigger this driver crash.
Some users might wonder what that means if they don’t use KWin. Well as the screen locker has been moved to KWin you can no longer lock the screen if not using KWin (the same way you could not lock the screen if not using KRunner before). If you want to lock your screen in Plasma 4.8 but don’t want to use KWin you should get in contact with your Window Manager vendor. Sam from Compiz wanted to add support for it in Compiz. For anything else I don’t know. So why did we do it: we think that the security of most of our users is more important than the need of some users to use a different window manager. Also we had added many integration features to Plasma in the past and if you were not using KWin you lost these features. With the screen locker it is now exactly the same: you lose the integration feature when not using KWin. I also want to remember everybody who wants to complain in the comment section that the KDE Plasma Workspaces are an integrated product consisting of the Plasma Desktop Shell, KWin, KDM, Systemsettings and a few other applications. We develop this as one product, so if you want to remove a part, well that’s your decision, but we have to compromise and we clearly see that other vendors are integrating their window manager even further into the desktop shell than we do.