htcfreek
commented
4 years ago Not sure if we should make this a PowerToy. There are many existing applications. For example Don't sleep.
Closed pma9 closed 3 years ago
htcfreek
commented
4 years ago Not sure if we should make this a PowerToy. There are many existing applications. For example Don't sleep.
pma9
commented
4 years ago @htcfreek I also pointed out a few other alternatives, but I thought we could still add it here since there are also a few alternatives for the other features of PowerToys. Also I wasn't able to find a good open source version of this feature that I would feel safe and confident to install on my machine. However, I do understand we wouldn't want to have too many features or bloat in PowerToys. I just thought I would post anyways.
Also if anyone knows the APIs or a best practice on how to do this, I would appreciate any tips or nudges in the right direction so I might be able to implement this for myself. Thanks!
htcfreek
commented
4 years ago @pma9 As far as I know there must be an api to say Windows you need the monitor and that it should not sleep or reboot. This api is used for example by video players.
crutkas
commented
4 years ago question: does the Power management settings not work appropriately?
pma9
commented
4 years ago @crutkas The feature targets more of a quick way to prevent your computer from sleeping. In many cases, it will only be turned on for a specific amount of time. One example is when you are running some program or test and you want to step away from the computer without having to go into your settings to turn off the sleep. Another example is sometimes I'd like to make sure my computer doesn't sleep when we are using the computer to play music and other people would like to control the playlist but I wouldn't want them to have my password.
ajkWare
commented
4 years ago You might try using Insomnia - the source code is provided, if that's Open Source enough - you can see the APIs used there. For me a shortcut to run the program minimized to the notification area is fine. I've never felt the need for a timeout feature, never knowing how long whatever is going on will take. (For me it's often uploading stuff to OneDrive.)
dend
commented
4 years ago There is a clean API in Windows that can be used for this purpose, if you don't want to mess around with power profiles (as mentioned in #7999) - SetThreadExecutionState. With the ES_DISPLAY_REQUIRED flag set, this should do the trick. This API just needs a nice wrapper in PowerToys.
dend
commented
3 years ago So just as a heads-up @crutkas, per discussion, I am picking up this issue and working on a PR. Feel free to flag as in-progress and assign it to me.
enricogior
commented
3 years ago @dend thanks for helping with this. Before opening a PR we need to discuss some implementation details. Let's start with a description of the settings.
dend
commented
3 years ago Here is what I am thinking, based on customer problems I've anecdotally heard about. I am happy to adjust.
Customers have the need to keep the screen awake for certain periods, to reduce friction in logging in and out of the machine if they are at locations where they are not concerned about unauthorized use or tampering. This can be helpful to monitor long-running processes (e.g. "I want to keep an eye on the video encoding process without having to re-login every 15 minutes").
The desired behavior is often temporal in nature, rather than permanent. This is why we need to tackle it through a PowerToys module rather than rely on the OS power settings, which can be cumbersome to manage.
The following options map to identified customer scenarios.
This ensures that customers can set the toggle from the application that signals that their computer needs to be awake indefinitely. Basically, until the customer toggles the setting back, the computer screens will be kept awake.
Set a defined interval, during which the customer will be able to keep the screen awake (e..g. next 4 hours).
Set a defined set of hours during which the screen is kept awake.
The settings UI should give the customers the option to enable or disable the Espresso module (since it keeps the screens awake), and if they enable it, they are able to specify which format of keep-awake they need, the default being the simple toggle. The user can switch to any other option with the setting enabled.
If the user disables the setting, the Espresso functionality ceases to work, regardless of the earlier setting.
enricogior
commented
3 years ago @dend /cc @crutkas @dedavis6797
Will it only prevent the screen to sleep? Or will it provide an option to let the screen go to sleep but not the system? What about UI feedback that the option is on? (beside opening the Settings and check if it's on)
dend
commented
3 years ago Interval - should be hours and minutes. Don't think we need to artificially limit this, unless there is some system limitation in Windows that I am not aware of.
Scheduled - this should be simple, similar to how the "Night Mode" works in Windows. Give the customer the option to say that they want the screen to be awake between certain hours of the day. I am not sure how helpful that is right now and I would maybe even de-scope this for the time being, and get more customer feedback on the toggle + interval functionality.
I would advocate for us to focus on just keeping the screen awake for now. I can see us adding a bit more flexibility over time (akin to the caffeinate tool), but for V0.1keep it very simple, get feedback, and see what customers need.
Lastly, on UI feedback - I suggest we include the option in the PowerToys tray, but also keep it simple there - it's either on or off. Long-term, I would very much like to make this available as a command line option as well (e.g. pt espresso -d) but that's out of scope for the initial feature.
ajkWare
commented
3 years ago I myself have never felt the need to keep the screen from blanking (which I think is what you're saying). I've just wanted the machine not to sleep so that long-running processes that don't organise this for themselves continue.
In fact you're talking about stopping the machine from locking and so avoiding the unlock sequence, rather than sleeping, or indeed blanking. I don't think I've ever heard of the screen 'sleeping' as a term in this area. The system sleeps, or locks, and the screen blanks. (I'm not sure if stopping locking or blanking stops sleeping.)
I think locking behaviour depends on the OS version/installation. This machine runs Pro and doesn't automatically lock, although the screen blanks. (You can use the deprecated (?) screensaver facility to automatically lock it.) Of course the lock facility itself is useful only where there is general access to a machine. The WIN+L key might be better in this situation, or best dynamic lock feature which exploits the proximity of a phone - lock when blutooth conneciton lost.
In terms of interface, for the infrequent use of this would get I'd have thought a straightforward app interface would be appropriate. When the facility is active, a specific notification tray icon should be visible. I thought the Powertoys tray icon was more about configuration/settings than actually activating a tool. In fact, although this appears under the powertoys brand, it's a sensible free-standing app which doesn't benefit from powertoys integration (apart from discovery/delivery etc).
dend
commented
3 years ago That's a fair call-out, @ajkajk - the most common scenario where I've seen this used is to prevent the machine from getting into screensaver mode/locking. But, I can see this also necessary in cases where the user wants to block the machine from going to sleep while in a constrained environment, such as a laptop operating on battery power, where a lock might be OK, but they do not want to have the machine go to sleep.
Interestingly enough, this functionality is kind of available in the Windows Mobility Center (WMC), where you could turn on Presentation Settings.
The challenge with this, however, is the fact that WMC is only available on laptops, and requires some regedit gymnastics to make it run on a desktop machine. It also does not have the flexibility that I am describing above, such as only keep awake until a certain time period elapses.
Looking online (and this is just anecdotal evidence and not a formal user study), there are quite a few folks looking for a solution to the problem of preventing locking:
So based on the context and feedback from @ajkajk, my proposal would be as follows, and I am intentionally scoping this to the Minimum Viable Product (MVP) to see what customers might need in the long-run, and whether there is any use here:
In terms of interface, for the infrequent use of this would get I'd have thought a straightforward app interface would be appropriate. When the facility is active, a specific notification tray icon should be visible. I thought the Powertoys tray icon was more about configuration/settings than actually activating a tool.
You are right - upon closer inspection, it doesn't seem like PowerToys is exposing much in the tray today other than settings. It would make sense for this extension module to actually have its own tray icon from which you can control the activity. @crutkas @enricogior - is there precedent to this? How do you feel about a possible addition like this?
In fact, although this appears under the powertoys brand, it's a sensible free-standing app which doesn't benefit from powertoys integration (apart from discovery/delivery etc).
I disagree - every app within the PowerToys suite would be a good standalone app. Per the PowerToys description, it's a set of tools to "streamline their Windows 10 experience for greater productivity" and I would argue that making your machine chug espresso is one of the productivity enhancements 😃
niels9001
commented
3 years ago Things that come to mind:
Shortcut to turn it on / off would be great. Ideally also a way in the system tray to do it.
Show and indicator on top of the PowerToys systray icon to indicate if Espresso is turned on or off.
davesmits
commented
3 years ago Like said presentation mode is already doing a good job. Try to give that one some tlc instead of reinvest the wheel. Make presentation mode available on windows sku's (it's only on pro available now) and add it to quick action instead of dumping it in system tra.. everyone happy
dend
commented
3 years ago @davesmits - thanks for the feedback! Unfortunately, presentation mode is something that doesn't have nearly the flexibility I am thinking for the feature (e.g. timed awake time). Given that PowerToys is an incubation project, it will be a good opportunity to gauge customer feedback before thinking of larger roll-outs.
dend
commented
3 years ago OK, so just to summarize the proposal, and @crutkas and @enricogior - I'd like to get your thoughts on whether this is a go/no-go.
This will be either on or off. When it's on, the user can set up the type of "caffeination" they want to enable for their machine (see below). When it's off, the machine operates under normal constraints, as defined in the current power management plan.
In this mode, the machine is kept "awake" (preventing lock) indefinitely. The machine does not go to sleep while this functionality is enabled. The user will have to explicitly disable this for the machine to go to operation under its current power management plan.
The user defines a time, in hours and minutes, during which the machine is kept "awake" (preventing sleep). Once the time elapses, the machine resumes operation under its current power management plan
If toggled, the machine will keep the displays on, and the machine will not be locked for the duration of the keep-awake mode. If not toggled, the machine will not go to sleep, but the displays can turn off/switch to screen saver mode, effectively locking the machine.
When, and only when, Espresso is enabled, and is keeping the machine "awake", a tray icon is displayed to let the user know that the machine currently is kept "awake." From the tray icon, the user can:
The tool will offer a command-line interface, allowing the user to call:
espresso -d -t 3600| Argument | Description |
|---|---|
-d |
Keep the display on (prevent lock). |
-t |
Define a time during which the keep-awake mode should be enabled. |
The -t argument will enable timed sleep prevention, in seconds, similar to caffeinate on macOS. Omitting the -t argument will result in an indefinite "awake" state,
Omitting the -d argument will result in the machine not going to sleep, but the screens can turn off and lock the computer.
Settings set in the command line will be reflected in the tray and the PowerToys settings.
In the future, the command-line interface (CLI) can be extended with other assertions.
The goal of this tool is not to mess with that at all. Instead, we would rely on a native Windows API that enables fine-grained control of applications requesting the OS to not sleep. This application is not a replacement for power management policies.
No. The API we are using are the same that are triggered when a media player is playing a video. The alternative to this tool is playing a video on a loop. The Espresso tool will enable control of the process, where the machine can still be locked (the screens are off), but is not asleep.
Out-of-scope for the first release, but it would be nice to add the ability to map the keep-awake to a process (e.g. "wait until Adobe Premiere exits, then you can make my computer go to sleep"), but that requires more extensive research. Another functionality that is worth investigating is conditional keep-awake, i.e. enable this but only if on AC power, or scheduled keep-awake.
crutkas
commented
3 years ago This sounds good.
dend
commented
3 years ago On (2) - potentially. Does not preclude the user from just using it directly from within the folder where Espresso is located. I wouldn't block on this or make it a requirement just yet. On (3) - ack, will make sure that the state is reflected. Thanks @crutkas - working on this ☕️
enricogior
commented
3 years ago @crutkas @dend it seems a less important thing, but let's decide a final name for this module right away. Renaming folder/projects after the initial merge to master has a significant impact on the localization process.
ajkWare
commented
3 years ago You might want to investigate the effect the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\7516b95f-f776-4464-8c53-06167f40cc99\A9CEB8DA-CD46-44FB-A98B-02AF69DE4623 may have on the feature. It claims to control whether to "Allow programs to prevent display from turning off automatically". Presumably that's a policy setting used by someone somewhere which might mean the 'keep display on' feature won't work - probably not a worry generally, but equally they'll probably be a bug report/dissatisfied user some time.
dend
commented
3 years ago That's a great call-out @ajkajk - will include that in the test plan, really appreciate you bringing this up!
@enricogior @crutkas I think Espresso is easy to remember and use, and it alludes to the caffeination process 😃 There is a number of projects on GitHub with this name, but they all serve different purposes. I also think that this is generic enough where it is not 1/offensive, or 2/associated with any particular software or brand.
dend
commented
3 years ago Updating on the progress - I've got some of the core application logic implemented. Fiddling with settings now to see how to connect those 😃
dend
commented
3 years ago @enricogior @crutkas I have the fundamentals in the fork - now the work starts on marrying the application with the settings UI.
The approach I am currently thinking is that there are two pathways for the user:
For (2), I am not sure how valuable it is to actually implement this bi-directional settings binding. That is, as a user, do I care if I start Espresso outside of PowerToys, to see the settings reflected in the PowerToys settings UI? If yes, I can write the settings from Espresso to PowerToys JSON files in %USERAPPDATA% when Espresso is launched.
What do you think of the above?
crutkas
commented
3 years ago All app data is in %localappdata%\Microsoft\PowerToys
Espresso would be in %localappdata%\Microsoft\PowerToys\Espresso
I think the settings pane for Espresso when loaded:
enricogior
commented
3 years ago @dend
User starts the application from the PowerToys settings UI
The Settings apps only reads and writes the json configuration file, it doesn't start/stop the application. The application needs to implement a file watcher and react accordingly.
The user starts the application outside of PowerToys
The application should support to start outside of PowerToys for debug purposes only.
dend
commented
3 years ago @enricogior @crutkas OK, so that leads me to an interesting point - technically PowerToys would be responsible for launching the application, because of its potential temporary nature. Espresso currently doesn't run constantly in the background (but maybe it should).
My initial thought was that through PowerToys, as a user I can "launch" Espresso by enabling it, configuring the right settings in the UI, and once it's done working, the process terminates. It seems like that would be counter to the current PT model, because I see tools like ColorPicker launch and sit in the background when the PT process starts.
So, proposal - we make Espresso run in the background, and it watches the settings file for changes constantly, but only when explicitly enabled. It would map to the behavior of the ColorPicker, as an example, where the process starts when enabled, and shuts down when disabled. Thoughts?
enricogior
commented
3 years ago @dend
So, proposal - we make Espresso run in the background, and it watches the settings file for changes constantly, but only when explicitly enabled.
If the module it's on, it's OK to make it run in the background all the time and monitor the settings file.
The running process name will be PowerToys.Espresso.exe
Btw, we are dropping support for the old settings, so there will be changes coming up for the module interface implementation since the module will not be required anymore to implement get_config and set_config.
dend
commented
3 years ago Cool, thanks @enricogior - working on the changes.
dend
commented
3 years ago Update - got the Espresso tool updated with an option to point to a config file to watch: https://github.com/dend/PowerToys/blob/a0c5f8cc59022cdb9d299ff29ac64ea0c53f9d29/src/modules/espresso/Espresso.Shell/Program.cs
I will be testing and debugging the tool over the next couple of days, but I believe that the functionality is implemented - I just need to properly integrate it with PowerToys and test against edge cases. Basically, I am where I was last week, but with file monitoring functionality done 😎
htcfreek
commented
3 years ago You might want to investigate the effect the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\7516b95f-f776-4464-8c53-06167f40cc99\A9CEB8DA-CD46-44FB-A98B-02AF69DE4623 may have on the feature. It claims to control whether to "Allow programs to prevent display from turning off automatically". Presumably that's a policy setting used by someone somewhere which might mean the 'keep display on' feature won't work - probably not a worry generally, but equally they'll probably be a bug report/dissatisfied user some time.
@dend If this policy has impacted on your module we should about showing a warning in settings ux and maybe have a warning symbol and tootltip message on the tray icon.
htcfreek
commented
3 years ago @dend
In an earlier comment someone mentioned that the state of your module should be visible in settings ux.
If it's enabled and configured to prevent until disabling the module, the state is clear in settings. But what about the configuration for temporary blocking?
I suggest to have an information text between on/off toggle and first settings group like this:
| State | Message |
|---|---|
| Blocking on | State: Preventing sleep. |
| Blocking temp. on | State: Preventing sleep until <time> |
| Blocking temp. on, time elapsed | State: off or time elapsep |
| Blocking off | State: off or time elapsed |
htcfreek
commented
3 years ago Suggestion for Module name:
dend
commented
3 years ago If it's enabled and configured to prevent until disabling the module, the state is clear in settings. But what about the configuration for temporary blocking?
Not following - temporary blocking of what aspect?
Suggestion for Module name:
I believe we landed on Espresso ☕
As a general status update, currently writing the C++ code that is required to launch/stop the Espresso module correctly from the settings UX. Logging works, sleeping and monitoring of settings works (through some Rx magic to prevent duplicate event processing in FileSystemWatcher). My goal is to work through the final requirements this weekend and submit a pull request for review and testing early next week (slight delay from my "this week" assumption).
htcfreek
commented
3 years ago If it's enabled and configured to prevent until disabling the module, the state is clear in settings. But what about the configuration for temporary blocking?
Not following - temporary blocking of what aspect?
If the module is off, then the toggle states this clearly.
If the module is on and sleep is blocked until disabling the module, the ux is clear too.
If the module is on and the sleep is blocked temporary (for a defined time) the ux is maybe not clear. Only because of the time setting, it is not clear if the time is running (and sleep is blocked) or if the time span is ended (and sleep is not blocked).
I hope you now it's clear what I mean.
Suggestion for Module name:
I believe we landed on Espresso ☕
Sory. Then I missed this.
As a general status update, currently writing the C++ code that is required to launch/stop the Espresso module correctly from the settings UX. Logging works, sleeping and monitoring of settings works (through some Rx magic to prevent duplicate event processing in
FileSystemWatcher). My goal is to work through the final requirements this weekend and submit a pull request for review and testing early next week (slight delay from my "this week" assumption).
Would be great if you can add screenshots to your pr description. 👍
dend
commented
3 years ago Another update (see this morning's commit):
Spending next couple of days testing edge cases and the scenario that @ajkajk called out above with the registry key.
niels9001
commented
3 years ago @dend Great, looking forward :)! Can you post a screenshot of the Settings screen - anything there you want me to look at for that?
Aaron-Junker
commented
3 years ago @dend I could help writing the docs, if you don't want to do it yourself.
dend
commented
3 years ago Test panel - posting for reference so I know what scenarios I need to validate.
✅ - Pass 🛑 - Fail 🟨 - Not tested
| Users can... | ✅ | 🛑 | 🟨 |
|---|---|---|---|
| [Standalone mode] Set timed keep-awake with display off | 🟨 | ||
| [Standalone mode] Set timed keep-awake with display off | 🟨 | ||
| [Standalone mode] Set indefinite keep-awake with display on | 🟨 | ||
| [Standalone mode] Set indefinite keep-awake with display off | 🟨 | ||
| [Standalone mode] Set timed keep-awake with display off from settings file | 🟨 | ||
| [Standalone mode] Set timed keep-awake with display off from settings file | 🟨 | ||
| [Standalone mode] Set indefinite keep-awake with display on from settings file | 🟨 | ||
| [Standalone mode] Set indefinite keep-awake with display off from settings file | 🟨 | ||
| [Standalone mode] Abruptly interrupt the execution, return machine to normal state | 🟨 | ||
| [Standalone mode] Mess up settings in the settings file when the app is bound to it | 🟨 | ||
| [Standalone mode] Bind the application to a PID | 🟨 | ||
| [Standalone mode] Set up keep-awake with blocking registry key in place | 🟨 | ||
| [Standalone mode] Delete settings file while Espresso is running and bound to the file | 🟨 | ||
| [Standalone mode] Point the application to a non-existent settings file | 🟨 | ||
| [Standalone mode] Attempt to start a second instance of Espresso | 🟨 | ||
| [Standalone mode] Change execution mode from the tray | 🟨 | ||
| [PT Mode] Set timed keep-awake with display off | 🟨 | ||
| [PT Mode] Set timed keep-awake with display off | 🟨 | ||
| [PT Mode] Set indefinite keep-awake with display on | 🟨 | ||
| [PT Mode] Set indefinite keep-awake with display off | 🟨 | ||
| [PT Mode] Set up keep-awake with blocking registry key in place | 🟨 | ||
| [PT Mode] Change settings manually through file editing | 🟨 | ||
| [PT Mode] Mess up settings file and restart PowerToys to attempt to load the bad settings | 🟨 | ||
| [PT Mode] Delete settings file while PowerToys and Espresso are running | 🟨 | ||
| [PT Mode] Delete settings file while PowerToys and Espresso are running | 🟨 | ||
| [PT Mode] Attempt to start a standalone copy of Espresso outside of PowerToys | 🟨 | ||
| [PT Mode] Change execution mode from the tray | 🟨 | ||
| [PT Mode] Terminate the Espresso process through Task Manager and re-enable it from settings | 🟨 |
dend
commented
3 years ago @niels9001 YES! Was just about to ask that. Here is what settings look like. The one piece I need help with is the pseudo-screenshot on the right side (the image). Another piece I need help with is a tray/app icon, which should be a coffee cup, but I don't have a ready-to-go icon yet other than the glyph I am using in settings.
@Aaron-Junker will have a separate PR that we can collaborate on for the docs. Lots of room to improve! 👍
niels9001
commented
3 years ago @dend Great!
For my understanding:
Keep display on: this will keep the computer awake at all times, but will either keep the screen on or turn it off. This setting is not related to the 2 behavior options ("Keep awake indefinitely" vs. "Keep awake temporarily") correct?
I can make a "Fluent" version of the coffee cup. Is the one you are using now part of Segoe MDL2 Assets? What will the Tasktray icon do exactly? Show that Espresso is turned on? Does anything happen once you click on it?
Yeah good one.. there's not really a UI that we could use as a screenshot for the image, except for the task tray icon right? Let me think of something that would make sense :).
dend
commented
3 years ago this will keep the computer awake at all times, but will either keep the screen on or turn it off. This setting is not related to the 2 behavior options ("Keep awake indefinitely" vs. "Keep awake temporarily") correct?
Yes, that is correct!
I can make a "Fluent" version of the coffee cup. Is the one you are using now part of Segoe MDL2 Assets?
Yep - that's the one. The system tray will allow the user to switch to see that Espresso is running, and switch between indefinite and timed modes. Once you click it, a menu will show up that gives those options.
Yeah good one.. there's not really a UI that we could use as a screenshot for the image, except for the task tray icon right? Let me think of something that would make sense :).
I wonder if this can be something generic, computer being awake. Like a monitor with a coffee cup on it. What do you think about this?
Thank you for all the help with this, @niels9001!
htcfreek
commented
3 years ago @dend Suggestion for the settings window:
niels9001
commented
3 years ago @htcfreek Good suggestions IMO.
@dend Is there a branch on this repo I can PR against making UI changes to the settings?
htcfreek
commented
3 years ago @niels9001, @dend,
State:.
BenConstable9
commented
3 years ago This tool looks great and looking forward to using it. Is it possible to integrate it with PowerToys run e.g. search prevent sleep instead of using a system tray icon?
htcfreek
commented
3 years ago This tool looks great and looking forward to using it. Is it possible to integrate it with PowerToys run e.g. search prevent sleep instead of using a system tray icon?
@dend A second step would be to create a PT Run plugin stat interacts to the espresso process by using it's command line.
Aaron-Junker
commented
3 years ago @Aaron-Junker will have a separate PR that we can collaborate on for the docs. Lots of room to improve! 👍
@dend Tell me when you made it!
htcfreek
commented
3 years ago @dend Suggestion for the settings window:
- State information
- change hierarchy
- text improvements
@niels9001 Do we need an separate issue for text changes and state information or should I reference this comment in your ux issue?
Summary of the new feature/enhancement
This feature would prevent the OS from going to sleep with the options to set a timer for when it can go back to sleep. This functionality is provided by the following two sources for free; however, I choose not to use these since they are not open-source (or I couldn't find the source code). Also the caffeine software uses key strokes which is less than desirable than an API approach that amphetamine takes.
https://zhornsoftware.co.uk/caffeine/ https://www.d7xtech.com/free-software/amphetamine/
Basic implementation details