Hello! Quite often when I leave the computer, I would like it not to go into sleep mode, or not to go because of the background compilation task, but I don't want to use manual blocking, since I often forget about it. Knowing the time I leave the computer, it would be nice to have an additional slider and buttons to add/subtract the waiting time as an option for manual blocking. Thank you! :)
> I don't want to use manual blocking, since I often forget about it. Is there any reason to expect you would remember the new thing you're proposing, though? Wouldn't it run into the same problem if you needing to remember to use it?
(In reply to Nate Graham from comment #1) > Is there any reason to expect you would remember the new thing you're > proposing, though? Wouldn't it run into the same problem if you needing to > remember to use it? I think the idea is the following: Situation: Time to get away from the computer for a bit, but need some long-running task to continue in the mean time. Current solution: Manually set inhibit. Come back later, computer is still on. Continue working, hopefully remembering to turn the manual block off again. Proposed solution: Manually set "inhitbit for 90 minutes". Come back later, computer is still on (if it's earlier than 90 minutes), or sleeping (if it's later). Resume as needed, no further invention is necessary. In other words, in one case you need to remember two things (setting the block and removing it), while in the other you only need to remember one. And the first one is typically easy to remember, as it's something the user actually wants to do, whereas the other is cleanup after the user has to after what they want to do is complete. It's much easier to remember putting the original on the photocopier if you want to make a copy than remembering to take it with you when you have the copy you wanted. This could be implemented with a timer combo box next to the "Manually Block" button in the applet, similar to the one we have in kcm_powerdevil for choosing the waiting time before sleeping etc. Like [Manually block] [For 90 minutes |v] [Manually block] [until unblocked |v] Seems reasonable to me, and easy enough to understand. (Wording for the indeterminate length case could be tweaked). Though if the user is regularly compiling large projects it probably makes sense to integrate the building with kde-inhibit so it automatically happens, but this is not something we can do for the user, they have to set it up for themselves.
> Situation: Time to get away from the computer for a bit, but need some long-running task to continue in the mean time. I see. So really the problem here is that the task itself didn't inhibit sleep (screen locking is not relevant, as background tasks can continue while the screen is locked) I can the value for some kind of timer like we have for DND mode now. However it's also important to report issues for the developers of the apps that have long-running tasks but aren't inhibiting sleep as expected. That should be happening automatically. If the developer is effectively you because you're compiling your own software in a terminal window, you can actually do this yourself by prepending the terminal command you use for compiling software with `kde-inhibit --power`. That's even better than the proposed timer, since the inhibition will end exactly when the task ends! Is that sufficient for your purposes?
(In reply to Nate Graham from comment #3) > Is that sufficient for your purposes? I'm not sure about what the reporter thinks. For something you regularly do, setting this up probably makes sense, but I could see there being one-off tasks where you wouldn't want to set up something extra. Another situation that has definitely bit me before: copying data between local computers (with sftp/Dolphin). On the local computer, Dolphin should probably inhibit sleep, I'm not sure it does but that would be a bug. But on the remote, sshd doesn't do it automatically, and I don't think there's a really clean way to get it to do so. If I remember in advance, I disable sleep there, because having the transfer interrupted is annoying. But it's easy to forget later and not even notice, as the computer wakes from sleep on mouse input, so there's little difference between the computer waking up and the screen waking up. I've definitely had the computer needlessly run for a week or two before I noticed that it didn't go to sleep.
For me, it happened to me that the computer went to sleep in 2 very annoying and frustrating cases: 1. While I've put a huge folder to be copied or moved to another location. 2. While I've put a long running command in Konsole to do something. I don't remember exactly what it was, maybe an rsync or something else. For me it was very annoying that these two long running and potentially dangerous if interrupted actions were not enough to inhibit by default the sleep. I had to start over the copy or move of the huge folder as I could not be sure anymore that the interruptions with the sleep wouldn't have corrupted something from the transfer. It would be great if copy or move in Dolphin and still running commands in Konsole would ihibit the sleep by default. I too forget to that sleep is one and have to turn it off before long running commands as I don't expect that the computer goes off by default, when I leave it alone as it's unnatural to do something that I have not instructed it to do. I understand the reason with the energy saving and I agree with it for the sake of the environment, but I think Plasma could be just a bit smarter about this as idle while copying / moving things or long running commands in the terminal is normal. We can't just always stay near the computer until everything finishes. I think both Dolphin and Konsole should inform Plasma when they are busy doing something. Screen lock is not a problem as actions can continue without problems, but sleep and hibernate is as we can never be sure if the tasks were paused and resumed correctly without anything being lost. In my opinion only Qbittorrent and other similar clients can do that as you can even verify the files afterwards to make sure everything is still there as it supposed to be. I think there is impossible to have unnoticed missing / incomplete / corrupted folders or files.
(In reply to John from comment #5) > For me, it happened to me that the computer went to sleep in 2 very annoying > and frustrating cases: > 1. While I've put a huge folder to be copied or moved to another location. > 2. While I've put a long running command in Konsole to do something. > I don't remember exactly what it was, maybe an rsync or something else. Assuming the tasks don't involve data leaving the local machine, these are definitely things we can fix to make the initiating apps inhibit sleep until the tasks are complete.
(In reply to Nate Graham from comment #6) > > 2. While I've put a long running command in Konsole to do something. > > I don't remember exactly what it was, maybe an rsync or something else. > Assuming the tasks don't involve data leaving the local machine, these are > definitely things we can fix to make the initiating apps inhibit sleep until > the tasks are complete. A long-running command blocking sleep might not be a good idea - having a terminal with a less or man or even htop open blocking sleep seems very surprising to me.
No, probably not if it's automatic. Maybe that's what should be manual, then: you tell Konsole "Block sleep until this completes". You'd still have to remember to do it, but with the requested feature, you already have to remember to do something; at least with this, the sleep blocking ends exactly what it's no longer relevant, rather than at a time you;re basically just guessing at.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!