Forgot to point out that I based this on #7930, which is not yet in master. I belief this should not cause any problems though.

@michaelDCurran commented on 16 feb. 2018 11:25 CET:

In the long-term, is the eventual goal that the disable add-ons not
tested with this version option be on by default?

I think we should be very reluctant to do this, at least not at all before we have auto updating of add-ons. Also, if we enforce this, it might be good to do a compatibility check before updating. This shouldn't be very difficult actually.

make sure to update the devGuide before this merges.

Has the idea of using build number rather than release version been considered?

The problem is that one will never know what a build number will be of a release version before it comes out. For example, when version 2018.2 is in development, add-on authors might want to declare their add-ons to be compatible before the actual release comes out.

I forgot about this PR, do re-request review if it seems like this happens.

add-on authors might want to declare their add-ons to be compatible before the actual release comes out.

Yes, good point. However, this is only really necessary for the last tested NVDA version. If we were strict, we would say that you can not test have tested against NVDA release x until release x is built and the build number is known. Being pragmatic about this, what we gain by using the release version is ease for the addon-developers to prepare for an upcoming release and for them to be able to guarantee that the addon will be available from day one of the new version. What we lose is the granularity, and ease of comparison.

I think we should stick with the release version.

is there a way we could make it be disabled for next/master then? We need a way to make sure devs don't have their addon disabled unnecessarily.

@michaelDCurran

This includes the launcher's install/update dialog where the 'run NvDA on the windows logon screen" checkbox would normally be focused by default.

I'm a little uncertain about this. It might make it harder to discover these checkboxes? Would it be better for these dialogs to have a new checkbox similar to the addon installation warning ("I understand that this add-on has not been tested with my version of NVDA") and disable the "install" / "continue" button until it is checked?

@feerrenrut I think a new checkbox would be okay. But the wording would need to be clear. In your example you said "this add-on". In most cases the user is updating NvDA, so it would be more like "Existing add-ons are not compatible with this version of NVDA".

@michaelDCurran Indeed, the line endings have changed, however, regardless of what I do with line endings, the only way I can get git diff to display a sensible diff is with either -w or with --ignore-space-at-eol. Perhaps the diff on GitHub would be better if I reverted the line endings and pushed.

Correct me if I'm wrong, but I believe most of the files are checked in with windows (CRLF) endings, so I expect that changing the line endings is preferable anyway?

regarding line endings, see my comment on #6275

@josephsl Sorry, I couldn't find a relevant comment?

I probably could have been more explicit, the line endings used to be LF (unix style) now they are CRLF (windows style).

Woops, I intended to have another run over the code, but turns out I didn't make that clear enough. I also think it is clear that it is pretty difficult to test code that is involved in the update process. Note that this is not a request to revert this, but there might be some things to polish.

1. One major disadvantage of the current state is that untested add-ons are disabled by default. While this makes sense, it can result into behavior one might not expect. For example:

   1. Install NVDA 2018.4
   2. Use the Vocalizer (Expressive) add-on along with a desired voice
   3. Whenever 2019.1 is out, perform an update.
   4. As soon as the update process starts, NVDA switches to espeak, even on Windows 10, where a switch to one core might me more desirable.
   5. One might be unable to understand espeak, in which case one is stuck.

   Also consider the impact this might have for braille display add-ons used by deaf blind users.

2. First letter navigation does not work in the incompatible add-ons list. That might be because the check mark is the first item in the list, however I do not recall this behavior from the time I tested the AutoWidthCheckableListCtrl.

@leonardder commented on 6 Dec 2018, 13:01 CET:

First letter navigation does not work in the incompatible add-ons list. That might be because the check mark is the first item in the list, however I do not recall this behavior from the time I tested the AutoWidthCheckableListCtrl.

Ugh, and the list control exposes the relevant columns using accDescription. This basically means that disabling object descriptions in NVDA's object presentation settings will only announce the check box, nothing else. Hopefully #8858 can help with this.

This pr is causing alpha snapshots to no longer update.
After downloading and before installing there is the following traceback:

ERROR - unhandled exception (09:21:14.213): 
Traceback (most recent call last): 
  File "gui\__init__.pyc", line 985, in Notify 
  File "updateCheck.pyc", line 578, in _guiExecNotify 
  File "updateCheck.pyc", line 669, in _downloadSuccess 
  File "updateCheck.pyc", line 442, in __init__ 
  File "versionInfo.pyc", line 46, in getNVDAVersionTupleFromString 
ValueError: alpha-16387,0a5c7678 

This pr assumes that the version string coming from the update server is numeric, however it is not in the case of snapshots.
I'm not sure if the server actually gives back a numeric version as well or not.
Should we revert this pr for now, based on this and other discussions going on in parallel to improve this feature?

Some options:

• We don't bother checking against snapshots. I.e. we just allow non-numeric versions to accept all add-ons.
• We prepend snapshot version strings with the version year.major like betas and rcs so we can then grab this for checking.
• We some how find out the numeric version from scons or the generated launcher file, and send this to the server when publishing snapshots, and have the numeric version be given to clients along with the friendly version string. Then the numeric version can be checked by the client.

The first option is the easiest and perhaps should be the way to go for now, but we still could go with one of the other options at any point.

Note: right now I have disabled further alphas from being picked up by update clients.

Some options:

* We some how find out the numeric version from scons or the generated launcher file, and send this to the server when publishing snapshots, and have the numeric version be  given to clients along with the friendly version string. Then the numeric version can be checked by the client.

I almost have a patch ready that somehow does this. It calculates the version tuple based on the fileVersion info in the executable. This was actually what I intended to do from the start, but it somehow got forgotten in the process of Reef picking this up, for which I'm probably the one to blame.

See #9026