Make a beep once goggles are up and running.

hd-zero / hdzero-goggle

MIT License

258 stars 75 forks source link

Make a beep once goggles are up and running. #395

Open qvasic opened 7 months ago

qvasic commented 7 months ago

HDZero Goggle take around 20 seconds to start up. This PR makes goggles beep once they started up, so user doesn't have to check visually.

new option "Beep on Power" added to Power page;
it controls whether goggle beep once it is booted up;
also whether google beep on changing power to analog bay is also controlled by this option;
minor safety checks added;
launch.json file added to debug goggle emulator from VS Code.

IDV7 commented 7 months ago

Suggestion: make it an option in the gui?

ligenxxxx commented 7 months ago

Suggestion: make it an option in the gui?

Yes, there may be people who don't like beep.

qvasic commented 7 months ago

Suggestion: make it an option in the gui?

Yes, there may be people who don't like beep.

I'll do it once I have some free time.

nerdCopter commented 5 months ago

much desired option.

sanderpuh commented 3 months ago

There's already a beep when my goggles boot up to HDZero thanks to the expansion module. The expansion module is set to automatically switch off if not used, and the goggles beep as soon as the power to the expansion module is toggled.

Could this feature be further improved by having the goggles do a beep when the source is changed? This means it will beep on startup, and when the source is changed, to indicate the switch was succesful. Not sure on which page we could add the option to enable/disable the beep though. Perhaps three options:

beeper off
beeper on startup
beeper on source change (especially with #423)

nerdCopter commented 3 months ago

addition of .vscode/launch.json should not be in this PR.

qvasic commented 2 months ago

addition of .vscode/launch.json should not be in this PR.

@nerdCopter why not? I tested it with WSL, it should work in native Linux as well. Very useful if you need to debug something.

pfeerick commented 1 month ago

why not?

Because PRs are better when they focus on just one thing/area. So while, useful, that change does not relate to the rest of the PR and its overall area of focus. It would probably be better to have that in a in a separate PR, adding just that functionality. Smaller/single focus PRs are easier and quicker to review, and thus more likely to get merged sooner. i.e. that might have been merged a couple of months ago now if it wasn't part of this PR ;)