> On Oct. 14, 2014, 9:02 a.m., Martin Klapetek wrote: > > Could we possibly get "Suspend" button instead? Suspend stores the session > > state into memory and then restores it without any issues (and we lock > > screen on wakeup anyway); many times I have found my laptop with locked > > screen and I had to unlock, click the suspend button in the panel only to > > get it locked again and suspended. > > Martin Gräßlin wrote: > I expected this question to come :-) - I'm not sure whether it's a valid > use case, at least for laptops. Closing the lid should send it to suspend, > the suspend button should still work (if not, we should fix it). So there are > already quite some decent ways to get the system to suspend when locked. > Especially with lid closing it does what it's supposed to do. > > In fact the functionality should even be available through the Change > Session functionality as that drops you to the login manager where you can > suspend. Sure not as comfortable as directly exposing it. But we don't need > to expose every option which might make sense ;-) > > Kai Uwe Broulik wrote: > Although closing the lid apparently reliably suspends the device, even > when locked, my gut makes me not trust it. :/ > > Martin Gräßlin wrote: > > Although closing the lid apparently reliably suspends the device, even > when locked, my gut makes me not trust it. :/ > > At least my notebook(s) have a visible LED indicating it is in sleep mode. > > Martin Klapetek wrote: > There are still usecases however where either the user does not want/need > to close the lid and/or sets his laptop to not suspend on the lid close > (personally I have that disabled when on charger). Plus there is the whole > non-laptop world. It's not about exposing every option that makes sense, it's > about replacing one senseless with one that makes more sense ;)
> It's not about exposing every option that makes sense, it's about replacing > one senseless with one that makes more sense ;) I don't see it that way. The option got added in a strange way shortly before the 5.0 release with the maintainers of the screenlocker not having a chance to review it (let's say it simple: if I would have reviewed the code, it would not have gone in, in the first place). So I'm comparing to the last state where it was working which is 4.11 and there the screen locker did not expose such an option and I want to go back to that working state. Let's look from there whether it's a valid option to expose the suspend option and not from the broken state. To me it's not a valid use case to expose suspend in the lock screen. To a certain degree it circumvents security. Suspend/Hibernate is allowed on a per-user logged in base. That's implemented by checking whether suspend/hibernate is supported at runtime. By exposing it in the screenlocker it circumvents the check. A not logged in user (or a user who is not allowed to supsend in his session) is able to suspend (multi user system just needs to switch to a logged session which allows suspend). Thus I think from a security perspective the option may not be there in the first place. - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120577/#review68345 ----------------------------------------------------------- On Oct. 14, 2014, 7:41 a.m., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120577/ > ----------------------------------------------------------- > > (Updated Oct. 14, 2014, 7:41 a.m.) > > > Review request for Plasma and Aleix Pol Gonzalez. > > > Repository: plasma-workspace > > > Description > ------- > > Logging out from the locked screen is impossible. Logging out means > interaction with the session due to the session manager. The session > manager asks all applications to quit and applications are allowed to > ask for example saving changes. The session manager stopps the > logout in this case and asks the window manager to focus this window > and the session manager will only continue the logout once the > application resolved the situation. At any time in this process the > user is still able to abort the logout! > > Switching to the application which needs interaction is impossible, > though as the screen is still locked. The result is a seemingly > frozen system as the logout cannot continue and there is no indication > what is going on. > > Of course the lock screen cannot unlock the session for the logout as > that would circumvent the security. If the lock screen would unlock > one would just have to click the button and abort the logout really > fast to have the system unlocked. So this is clearly not an option. > > The result is: we cannot implement this functionality in a working > and secure manner, so it's better to remove it. > > > Diffs > ----- > > lookandfeel/contents/lockscreen/LockScreen.qml > 7d730cf1ebd8241dfe1c00a2bef86ec4a3f0212d > > Diff: https://git.reviewboard.kde.org/r/120577/diff/ > > > Testing > ------- > > run kscreenlocker_greeter --testing and locked the screen - button is gone. > > > Thanks, > > Martin Gräßlin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
