Re: running beta of nvda



One counterexample, although not that intuitive, is desktop watermark shown on Windows Insider Preview builds; they are early beta quality builds so folks expect stability when considering small details.

As for changing the debug tone, this will involve changes at the source code, code branch, and deployment level:

  1. Source code level: debug tone is heard if NVDA detects that you are using a development build. Actually, scratch that – it is actually controlled by a private constant kept by Python to indicate a debug build.
  2. Code branch: there are at least three active branches used by NV Access and NVDA developers to indicate code quality: master/main (alpha), beta, and rc (release/release candidate). Alpha is almost identical to beta branch. The only difference between beta and rc branches is use of optimizations in RC/stable build compilation, hence debug tone will not be heard if using release candidates.
  3. Deployment: whenever changes are committed to NV Access’ copy of NVDA (which is the authoritative copy), a build is generated with help from a module named Appveyor. Depending on what it is told to do (through a YAML file), Appveyor will check which branch the changes come from, whether or not release optimization flags should be specified (both for C++ and Python code), and build appropriate versions of NVDA.


Another consideration is communicating errors that developers can catch – not only we get reports from users and try our best to reproduce certain issues, folks use tones as means of debugging and locating errors (whenever we hear a debug tone, we developers would open the NVDA log and read recent tracebacks). This is important as it then allows developers to either fix the issue right away or discuss strategies to do so in the future. For people relying on debug tones for debugging issues, it gives us an early warning so major bugs will not slip to stable releases – this is why when contributors file issues and pull request, if a beta cycle is active and a bug was discovered with a beta build, they are directed to send changes based on latest beta branch commit.

At the moment beta branch is in a “suspended animation” – translators are committing localization updates, and unless critical issues are discovered, the next release from beta channel will be 2020.3 release candidate. As for making debug tones optional or suppressing it in beta releases, it should be something that must be taken care of from alpha channel first i.e. let’s ask NV Access via GitHub.




From: <> On Behalf Of Brian Vogel
Sent: Monday, September 28, 2020 11:43 AM
Subject: Re: [nvda] running beta of nvda


On Mon, Sep 28, 2020 at 02:32 PM, Joseph Lee wrote:

This behavior is intentional – beta is not really a stable build yet, so NVDA developers are interested in fixing major errors if possible, hence the debug tone.

But, Joseph, if one is not experiencing major errors, and I am not, and this darned tone is being presented, that, in and of itself, is a bug.

I've had it come up repeatedly when absolutely nothing I can detect is amiss.  I'm glad to hear I'm not the only one, and I'm happy to jump on to the, "this should not be occurring" bandwagon.

You don't intentionally produce spurious indicators, ever.

Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041  

It’s hard waking up and realizing it’s not always black and white.

     ~ Kelley Boorn


Join to automatically receive all group messages.