Review Request 108417: screenlocker make [escape] "conditionally" turn off the screen

[Oliver Henshaw]

> On Jan. 16, 2013, 4:07 p.m., Oliver Henshaw wrote:
> > I'm not sure about this. I do think that control of when to trigger e.g. dpms and dimming should shift from powerdevil to screenlocker (leaving the mechanism in powerdevil) but this seems a strange place to start.
> > 
> > If this is a companion to https://git.reviewboard.kde.org/r/108375/ (but for the simple locker) then what about just dismissing the unlock dialog on Escape? This is what the old screensaver did if I read correctly. In fact, is that an approach that works for all varieties of locker?
> 
> Thomas Lübking wrote:
>     The unlock dialog cannot be dismissed, it's what protects the screen against content exposure - it /is/ the screenlocker by the new architecture and afaiu.
>     The "screensaver" is just fancy stuff on top of it for whoever wants that, but it's not relevant in the locking mechanism.
>     
>     I don't think dimming belongs into the locker at all (why?) and Aaron preferred to keep the ability to dpms in one place and not link Xdpms from the locker/greeter.
>     
>     As pointed out, i believe that in the long run dpms (and pot. dimming if it's not) should be abstracted in solid, but for now it has to be done on the workspace layer and (only) powerdevil already has it.
>     
>     I frankly don't know what the "simple locker" configures as screensaver (no screensaver, no screensaver kcm, not gonna happen ;-) but if it disables m_showScreenSaver in the locker app, then yes - this is gonna just turn off your screen when you press escape from the locker instead of showing some fancy animation.
>     
>     Notice that i'm a foreigner in this context - i've no idea who's in charge of screenlocking / saving and just hooked on when there was this stir on k-c-d.
>     
>     I'll hold the push back for the next 3 hours (20:30 CET) to resolve pending questions.

I've some familiarity with powerdevil but not much insight into the architecture of the greeter part of the screenlocker.

If the screenlocker DESIGN document is still valid, then it's the fullscreen window provided by the LockScreen class that obscures the desktop. The greeter goes over it. The simple locker is a qml thing managed by greeterapp, the same thing that launches the legacy screensaver windows - I think the simple locker is what is revealed when the screenlocker is hidden. I think the Simple Locker and the plasma based Desktop Widgets use the same qml password dialog. So it's this password dialog that should be dismissable/hideable, leaving whatever is in the background intact.

I believe the dialog needs to be hideable on: the Desktop Widgets locker, since once you bring it up with "Leave Screen" it stays there indefinitely; the Simple Locker, since it's always present and obscures the wallpaper background. If my understanding in the paragraph above is correct, hiding it in the legacy screensaver means hiding the whole simple locker, which is what you have done in the other review.


- Oliver


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108417/#review25663
-----------------------------------------------------------


On Jan. 14, 2013, 9:12 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108417/
> -----------------------------------------------------------
> 
> (Updated Jan. 14, 2013, 9:12 p.m.)
> 
> 
> Review request for Plasma and Dario Freddi.
> 
> 
> Description
> -------
> 
> Requires https://git.reviewboard.kde.org/r/108416/
> This calls powerdevil to turn off the display when the user presses escape, or rather every second time s/he does so.
> 
> Afaics the powerdevil infrastructure does not allow us to query this value from the DPMS Action (different from the stuff that is implemented in backend) so to check whether the screen is currently active (and i actually believe, this is gonna fail as well, because the state is likely reset on wakeup before we receive the event, esp. for a dbus call) we'd either have to link DPMS in the locker ... or invoke a cheap trick, ie. "s/conditionally/every other time/g"
> 
> Another way i could think off would be to add a message on the QML (like the caps lock) that the screen is gonna be turned off in 10 seconds and skip that when the user starts to interact (any mouse or key events)
> That's probably the more fair way to say that we cannot otherwise reasonably handle screenstate toggling - i just worry nobody actually reads such messages *shrug*
> 
> 
> Diffs
> -----
> 
>   ksmserver/screenlocker/greeter/greeterapp.h f332bfc 
>   ksmserver/screenlocker/greeter/greeterapp.cpp c8e95bd 
> 
> Diff: http://git.reviewboard.kde.org/r/108417/diff/
> 
> 
> Testing
> -------
> 
> Yes, reliably toggles the screen even after press-holding the escape key (then wait for the actual screen state and then controlled toggling it)
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130116/3e0657ca/attachment-0001.html>