Repository navigation
Replies: 3 comments 1 reply
|
@HemalR This is a well-designed proposal, and the design is the part I like: no second shortcut, no new preference, the same key doing more when pressed again. That is the right instinct for a menu bar app. My hesitation is the two-second armed window. A timing-dependent mode with nothing on screen is hard to learn and easy to trigger by accident, and the failure case is the unpleasant direction: you meant to switch keep awake off, you were slightly quicker than you thought, and the Mac now stays awake for four hours without you knowing. Since the shortcut is identical in both scenarios, the keyboard gives you no way to tell which state you ended in. The version I would be comfortable with keeps your cycling idea but makes the window visible rather than counted: the first press turns it on and shows the current duration, and further presses cycle while that indicator is on screen. More work, but it removes the guessing, and it degrades correctly if you walk away mid-cycle. Leaving this open rather than closing it. It is a Mole Mac change and worth doing properly. |
|
Nice one 👍 Agree on the visual feedback to limit/eliminate any confusion |
|
@HemalR Closing this as not planned, and the reason is a decision already written into the code rather than a fresh judgement. The global shortcut has one deliberate contract: press starts Keep Screen On open-ended, press again releases it. It ignores the menu's last duration and does not write one back, so the bounded-versus-indefinite choice stays entirely the menu's. Durations live there because that is the surface that can show what you picked. Two things worth being precise about, since you were: there is no duration setting in Settings either, only the behavior choice of what stays awake, so the menu really is the only place to pick a time. And the armed-window design you proposed is sound in isolation; what stopped it is that the failure case runs the wrong way, where a slightly slow second press leaves the machine awake when you meant to release it. If bounded sessions from the keyboard turn out to be what people actually want, the version worth building is the one you and I converged on, with visible feedback rather than a silent timer. That is a different proposal from this one, and it should start from the feedback rather than from the timing. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Keep awake is a super useful feature, and being able to trigger this with the keyboard shortcut streamlines its use 👍
Current inefficiency:
The keyboard shortcut only toggles keep awake on or off - infinite time duration only, without the ability to choose the time. For that we need to go to the menu bar application and do it all via the GUI.
Proposed solution:
Idea is to have it so that we aren't complicating the UI by having more keyboard shortcuts. So, instead of the keyboard shortcut simply toggling the feature on or off, I propose that when it is used to toggle it 'on' - that action 'arms' the application so that hitting it again within a predefined period of time, ends up cycling the available durations.
For example:
Standard scenario (for those who don't care for specific durations) - basically unchanged workflow to what it is now:
1 - KB shortcut to toggle on
2- Wait for however long the keep awake is required
3 - KB shortcut to toggle feature off
Enhanced scenario - when a set duration is wanted
1 - KB shortcut to toggle on -> defaults to toggling the feature on infinitely
2 - Within 2 seconds of 1, press the KB shortcut again (and again, and again) to cycle through the different duration options - 1hr, 2hr, 4hr etc
3 - After the 2 seconds have passed, the 'arming' is disengaged and the shortcut defaults to its toggling off behaviour
Note - The keyboard shortcut should be the same in both scenarios
All reactions