On Tue, Oct 11, 2011 at 03:55:15PM +0200, Thomas Lübking wrote:
> Am Tue, 11 Oct 2011 15:33:39 +0200 schrieb Torgny Nyblom <nyblom@kde.org>:
> > Does this mean that I will be focred to use a screensaver with
> > password unlock? If so why is that not a vaild usecase? It's what I
> > use at home all the time.
> 
> So you want to do that again why?
> 
"because it's pretty"?
on a more serious note, now do you handle the lock grace time?

On Tue, Oct 11, 2011 at 04:00:17PM +0200, Martin Gräßlin wrote:
> yes if you have a terminal open and if it is the top most of stacking
> order it is possible to start another window manager.
> 
[in fact ... oh, scratch that, thomas already answered]

> I think there is hardly anyone here on the list who is as experienced
> as I am with situations where you don't have a window manager running
> ;-)
>
sorry, but that's an utter nonsense argument from a security pov. you
are basically arguing for security by obscurity.

> KWin has currently one reproducable crash listed in bko.
>
irrelevant. there will always be new crashes, also outside kwin's
control.

> I myself have never run into a situation where KWin did not restart
> [...]
> 
even if it restarts, you still have a non-trivial racing window.
additionally, it probably allows a waiting app (some popup) to grab
input and thus make the subsequent re-lock fail.

the correct architecture, as far as i'm concerned:

1) ideal solution:
- everything wayland
- user switching and consequently desktop locking are handled by kdm,
  which acts as the top-level wayland proxy server. the new process
  structure within kdm is to be determined yet.
- no kwin involvment at all. kwin effect plugins may be used for some
  bling.

2) suboptimal solution (kicks in when no wayland-enabled kdm runs):
- the saver engine (which currently resides in krunner for historical
  reasons) is made stand-alone
- the lock engine is re-integrated into the saver engine, thus removing
  the now obsolete process separation (it was only meant to isolate the
  locker from kdesktop/krunner crashes)
- if an X based compositing kwin is running:
  - kwin is instructed to take the locker window and do something magic
    with it. same for the unlock dialog, plasma, etc.
  - the residence and implementation (qwidget, plasma, qml) of the
    unlocker dialog is orthogonal to kwin integration and can thus stay
    where it is; the general architecture of the plasma overlay can be
    retained and extended as needed
  - if kwin crashes, there is only a short unredirection flash
- if a wayland based kwin is running:
  - input handling is now a native task of the compositor, and a
    crashing compositor takes the whole desktop down anyway, so it is
    reasonable to fully integrate the locker into kwin
  - but for the same reason it may make sense to extract the core
    compositor from the bigger kwin
  - whether code sharing with the X based solution happens via source
    sharing and some #ifdefs, a small shared library with some virtuals,
    or not at all, remains to be seen

> If you want to discuss about the screen saver animations please start
> a new thread and preferable not on kcd but on workspace relevant
> mailing lists such as kwin or plasma-devel.
>
in fact, kcd *is* the relevant list. you can dispute that if you agree
to assume full responsibility for kscreensaver-bugs-null@kde.org.