fix(helper-ui): make the copy button copy, and say the display was slept - #151
Merged
Conversation
… arms Arming runs `pmset displaysleepnow` through `PmsetDisplaySleeper.forceSleep()`, so the screen goes black the instant the button is pressed. That is required behaviour, recorded in docs/coffee-bar-HANDOFF.md as "Force display off ... Required alongside disablesleep", but no user-facing text said so and the maintainer read the blanking as a crash on first live use of the shipped button. The armed sentence now names the display and says the lid can be closed. It states what coffee-bar DID rather than what the display now IS: LidClosedSession treats a nil from DisplayStateProbe as not-awake, so an .armed reply proves `pmset displaysleepnow` returned nought, not that the panel is dark. Closes #143 Signed-off-by: Carlos Eduardo Arango Gutierrez <eduardoa@nvidia.com>
An unsigned or ad-hoc bundle takes the .unavailable branch of PrivilegedHelperClient.decide(), which titles the one control "Copy the command instead". The view then disabled it on the same term, so the control named an action and refused to perform it. The Homebrew bundle is ad-hoc signed, always takes that branch, and the greyed button was the only route it offered to lid-closed mode: the command was recoverable only by selecting the sentence beside it by hand. The press now writes ServingModel.lidClosedCommand to the pasteboard and the window says so. The decision is a value, HelperAvailability.buttonAction, rather than a switch in the closure, because design 5.4 forbids asserting on rendered AppKit text and a branch written in a View is a branch no check reads. The safety property is unchanged. The copy branch ends at the pasteboard, and arm(seconds:) opens with register(), which re-reads availability(), so a build that cannot register still never reaches the OS with an arm request. Closes #142 Signed-off-by: Carlos Eduardo Arango Gutierrez <eduardoa@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #142. Closes #143.
Two defects on the lid-closed control, both found by using the shipped v0.3.0 build.
#142 — the button offering to copy could not be clicked
There is one button whose title flips with the bundle's signature:
Arm lid-closed modeon a signed build,Copy the command insteadon an unsigned or Homebrew one. Its.disabledclause carried|| helperAvailability == .unavailable, which is exactly the case where the title says "copy". So the control named an action and refused it, and on a Homebrew install that title is the only route the user gets to the command.The press is now decided on the model side and read by the view, matching how every other sentence on this surface is composed. A build that cannot register still never reaches the OS with an arm request.
#143 — arming blanks the screen and nothing said so
ArmServiceis constructed withPmsetDisplaySleeper, whoseforceSleep()runspmset displaysleepnow, so the screen goes black the instant you arm. That is required behaviour, recorded in the engineering notes as "Force display off ... Required alongsidedisablesleep", and it is the whole point: the machine is being made ready for the lid to close.But no user-facing text said it. The maintainer read it as a crash on first live use of the shipped button. The armed sentence now reads:
Not in this PR
#146 remains open. On a signed build whose helper is not registered, the stale-probe advisory still offers only the pre-v0.3.0
sudo installroute rather than mentioning the button. The advisory already consultsavailability()and suppresses itself when a registered helper is active, so the gap is narrower than the issue as filed.Testing done
PreferencesView_test.swiftandPrivilegedHelperClient_test.swift.swift testverified independently on a clean scratch path.theLidClosedSummaryIsInThePreferencesWindowAndNotInThePanel, a deliberate negative guard, is unbroken.Breaking changes
None.