https://bugs.kde.org/show_bug.cgi?id=476763
Pedro V <voidpointertonull+bugskde...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |voidpointertonull+bugskdeor
| |g...@gmail.com
--- Comment #2 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
Wasn't even sure what's the problem here first as I tried to reproduce it,
closing the lid causing sleeping, opening it returning to the lock screen, the
logging back in resulting in getting the whole session back including the
logout screen as expected, but then I realized that the point is the idea of
the logout screen being a sleep inhibitor.
I can see the following problems with that:
- I don't think even power management inhibitors get to stop the lid closing
power management event, so it's a context independent action which although
doesn't promise security features, I would be rather upset if my laptop stayed
unlocked for any reason after closing it.
- If the problem is merely the possibility of logout having a timeout which
isn't reached when closing the lid, then that's already covered by a setting:
System Settings -> Startup and Shutdown -> Desktop Session -> Logout Screen ->
Show
While I personally don't feel like it's a significant problem, thinking more
about it, it's really unexpected behavior though as the user initiates logout
which then never finishes with the default settings.
I still maintain that I wouldn't block sleeping, but it would be sensible to
deal with the logout screen (without waiting for the timeout) first before
sleeping. Finishing the user initiated action could be sensible (although
behavior changing compared to the current state) in most cases, but then for
example restart would be rather awkward that way as it would lead to the device
not going to sleep, so there's no obvious solution for all cases.
--
You are receiving this mail because:
You are watching all bug changes.
