Bug 344967

Thanks for the report

What would be the intended use case for 24h limit?

>>What would be the intended use case for 24h limit?<<

Well I like to use 8 hours on some machines. Unlock in the morning and its good all day. 24 hours, I don't know but why limit it.

Well I'm not the maintainer and definitely not the decision maker in this, but if you need 8h timeout, wouldn't it be better to just lock it right away when you're leaving the machine? What's the point of leaving the machine unlocked for 8 hours and then lock it?

As for "why limit it", it's not about limiting as much as it is about providing options to the users that make sense (and somehow locking the computer only after 24h seems...odd).

Sure guys, i'll spell it out. I'm coming and going alot, I dont know how long I will be away from these machines. I may be away for several hours, or 5 minutes. When I know for sure i'm leaving or feel I the need to protect, I do lock the screen.

IMO Entering passwords 20-40 times a day is not good security, and its annoying. I like to cut down on it where possible. KDE4 allowed it, I never heard about any issues with user confusion.

>>or feel I the need to protect<<
oops, meant: "or I feel the need to protect"

I don't see a need for it. The idea is to provide sane and secure settings. If at all it's arguable that the allowed max value is still too high.

If you don't want auto-lock with such a short time out, please just disable this feature and lock the screen explicitly when going away.

In fact the configuration still allows to set higher values, just the GUI doesn't allow to configure it.

(In reply to Martin Gräßlin from comment #6)
> I don't see a need for it. The idea is to provide sane and secure settings.
> If at all it's arguable that the allowed max value is still too high.
> 
> If you don't want auto-lock with such a short time out, please just disable
> this feature and lock the screen explicitly when going away.

Are you for real? What are you from the gnome project? Unless you have a fully EM shielded office, and physical access to your PC is restricted, entering your password all day long is not good security. Screen lock is just a polite barrier that tells your office mates "please dont touch my PC".

Please show me real world evidence that this was a problem in the past, that you need to make this change. Or at least point me at the code, I'll build it myself.

If the physical access to your PC is restricted, then don't lock your screen (and turn autolock off). You're going away and *know* you won't be back soon, lock you screen manually. Simple as that.

If you really really want this, then as Martin pointed in comment #7, you can set it manually in the config file, $YOUR_CONFIG_DIR/kscreenlockerrc

[Daemon]
Timeout=999999999999999999

> Are you for real? What are you from the gnome project? 

Just saying: this is a not-acceptable behavior. The great people from the gnome project are our friends. With that comment you qualified that bug report for "I don't care any more".

Yeah, well you already dismissed my use case. Gnome people are great. But Gnome is known for not allowing users to have options, forcing some default they think is best. KDE used to be the opposite philosophy. 

FYI, regarding your 99 minute maximum: noone set a maximum in kcm.ui. QspinBox defaults to 99.

> FYI, regarding your 99 minute maximum: noone set a maximum in kcm.ui.
> QspinBox defaults to 99.

Given that I designed the UI, I can tell you that I considered it, whether changing the default makes sense or not. I decided against it.

*** Bug 350601 has been marked as a duplicate of this bug. ***

(In reply to John Andrew McInnes from comment #11)
> KDE used to be the opposite philosophy. 

Well, let me tell you what our current philosophy is, in case you haven't heard about it yet: "Simple by default. Powerful when needed." If you can make a case where a lock time of more then 99 minutes is needed (and no, "because it was possible in KDE 4" is not a valid case), then we'll happily change that value.

> What are you from the gnome project?

This comment was golden.  The fact that the dev cannot accept/comprehend that people use software in a various manners is quite alarming.

(In reply to Thomas Pfeiffer from comment #14)
> (In reply to John Andrew McInnes from comment #11)
> > KDE used to be the opposite philosophy. 
> 
> If you can make a case where a lock time of more then 99 minutes is needed ... then we'll happily change that value.

I have long terminal processes that run that sometimes take more than 99 minutes.  I work on another machine and occasionally glance back over.  I have to disable the lock (or edit .config/kscreenlockerrc manually) or remember to move the mouse every 99 minutes.  (Then I have to remember to manually lock my station when I leave, or decide if I'm leaving for a long time each time I leave)

The main complaint non-linux users have about linux is the command line.  And I always say "try KDE, you can do everything from the GUI".  But if the new philosophy is "Simple by default. Powerful when needed." this should continue to apply to the GUI configuration.  That what makes KDE different - you can configure anything the way you want with the built-in GUI.

Not being able to set that number to *anything* is poor design.

Lets say you did set it to 8 hours, you wouldn't get prompted during the day, but you'd still have to lock the screen when you left because otherwise it's unlocked for 8 hours. 

It hasn't saved you from actually having to perform the manual action.
If you do forget you're scarcely in a better state than having autolock completely off with regards to security except in very contrived scenarios.

Maybe I'm missing something, but it sounds like you have a problem isn't in the timeout but in a lack of inhibitors - and we're just working round the problem.

I think many of the other options would be better suited to actually solving it:

 - you can wrap your scripts in a screensaver inhibitor; like a media player would

 - You can run kdeconnect on both PCs and set up "inhibit screensaver when connected" on the script machine so it's synced to your main machine.

And there's other stuff we can explore. Maybe we need a clearer inhibitor applet UI (the battery applet does contain this, but it's not too clear on a desktop).

its 2019... i'll try again:

Screen locking is all about forgetting or being away from the computer. right? It not like you are sitting at your machine "i can't go to lunch yet, I need my screen lock to kick in, then we can go".

So it is a balance between: locking the screen right away for safety -- and not wanting to relog and reenter your password 15+ times a day. Also as others have pointed out, you might want to be watching some application doing something for a long time, much longer than 99 minutes.

For me the balance is 8 hours. Entering my pasword every 99min is an unnecessary security risk. 

Again I ask, WHAT IS THE PROBLEM? it used to be this way. Where is this big problem that was solved by limiting it to 99min?

>>For me the balance is 8 hours. Entering my pasword every 99min is an unnecessary security risk. <<<

.. and more than that, it is a pain in the ass. :/

reopening as I have supplies a use case, as requested by the developer

(In reply to codywohlers from comment #20)
> reopening as I have supplies a use case, as requested by the developer

I have long terminal processes that run that sometimes take more than 99 minutes.  I work on another machine and occasionally glance back over.  I have to disable the lock (or edit .config/kscreenlockerrc manually) or remember to move the mouse every 99 minutes.  (Then I have to remember to manually lock my station when I leave, or decide if I'm leaving for a long time each time I leave)

Please use inhibition from the script.

(In reply to Martin Flöser from comment #22)
> Please use inhibition from the script.

How do I do that?  Where is that setting?

WORKAROUND:

You can edit `$HOME/.config/kscreenlockerrc` and set Timeout=285120

******************************
*********  WARNING  **********
******************************

DO NOT EVER OPEN THE LOCK SCREEN DIALOG OR IT WILL OVERWRITE YOUR SETTINGS AND YOU'LL HAVE TO REMEMBER RE-EDIT THE FILE