Manual update check doesn't always respect progress bar output config

[dkager]

gui.IndeterminateProgressDialog.done() doesn't check the configured output method for progress bars.
Also slight ugliness in the hard-coded frequencies and lengths of the beeps. Maybe add functions beepIndeterminate() and beepDone() to the tones module?

[jcsteh]

Would you expect this to say "done"? Note that this often might not be heard due to the foreground window change that often accompanies a completed action. Still, at least you wouldn't hear the beep. The length of the beep is also hard-coded in NVDAObjects.behaviors.ProgressBar. I guess we could put a constant in tones for the progress bar beep length, but this feels weird, since tones is an output module and arguably shouldn't have any behaviour specific code. @feerrenrut, thoughts?

[dkager]

Would you expect this to say "done"?

No, but neither do I expect it to beep when I have disabled that feature. In that case it would be a simple check, either beep or just return.
Arguably the "done" beep doesn't provide much information because the dialog is likely to change at that time anyway.

[feerrenrut]

I'm not familiar enough with all the ways that the tones module is used to be sure we are able to generalise. I can agree that the tones module isn't the place for those constants.

There are a few similarities in how beep is used in progress bars and in the mouse tracking code. In both cases there the beeps are indicating a value along an axis (or two). Perhaps we could abstract that pattern and generalise it, creating an in-between module/class that allows code like beepPosition(minValue, maxValue, actualValue) or similar. It could take the min and max frequency as well as the length as parameters on construction. Those values can either be constants in the class (in the case of IndeterminateProgressBar), or come from config (in the case of mouse tracking).

[feerrenrut]

In terms of prioritising this issue, while it does not look like it would take long to fix the impact is fairly low. Setting to P3

[dkager]

So let's leave adding constants or otherwise refactoring the beeps out of this issue for now. It looks like it needs more thought.
But do we agree that the "done" state should not cause a beep if the output method is set to Speech or None? I can create a PR for this, it seems rather simple.

[jcsteh]

Agree that done shouldn't beep if output should be speech only. However, please leave the beep as is when output is beeps or both.

[fisher729]

I got confused with the wording of this change in the What's New. Of course, I know what it does, however. Essentially, when reporting progress bars is not set to include beeps, NVDA won't beep for the update checker dialog and other dialogs I've seen.