Date   
Imposible to install last NVDA's alpa version

Ângelo Abrantes
 

Greetings!
I'm trying to install the latest version of NVDA alpa, but I'm not getting any success.
After the program restart, nothing else happens.
The last ".log" information is as follows:
"setting language to pt_PT"
I'm using a version of Windows7, which, so far, has been compatible with all versions of NVDA.
Thanks.


--
Cordiais Cumprimentos
Ângelo Abrantes, Equipa <Portuguesa do NVDA


--
Este e-mail foi verificado em termos de vírus pelo software antivírus Avast.
https://www.avast.com/antivirus

Getting Developer Info on an UIAElement in Console

Karl-Otto Rosenqvist
 

Hi there!
Today I got a bit further in my effort to make a grid accessible with the following lines.

// Get the UIASelectionPattern from the grid
selpat = self._getUIAPattern(UIAHandler.UIA_SelectionPatternId,UIAHandler.IUIAutomationSelectionPattern)

// Get what's selected
cursel = selpat.GetCurrentSelection()

// Loop through the selection parts and speak them
for i in range(cursel.Length):
selement = cursel.GetElement(i)
// Speak the column header
ui.message(selement.CurrentName)
// Now I want to get the value that's selected
valpat = selement._getUIAPattern(UIAHandler.UIA_ValuePatternId,UIAHandler.IUIAutomationValuePattern)

When I try to get hold of the UIAValuePattern from the UIAElement to get the text in the cell the following appears in the log.

Traceback (most recent call last):
File "scriptHandler.pyo", line 192, in executeScript
File "C:\Users\Karl-Otto\AppData\Roaming\nvda\scratchpad\appModules\spcsadm.py", line 54, in script_readGridRow
File "comtypes\__init__.pyo", line 277, in __getattr__
AttributeError: _getUIAPattern


It doesn't seem as the object stored in my variable selement that I get from the GetElement() has that pattern. In C# it works and looks like this:

var s = sourceElement.GetCurrentPattern(SelectionPattern.Pattern) as SelectionPattern;

foreach (var c in s.Current.GetSelection())
var v = c.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern;
System.Console.WriteLine(v.Current.Value);
} // foreach


Is it possible to display the dev info for a variable containing an object as you do with NVDA + F1? If that's possible in Python Console I can execute code to get to a oint where I can inspect that variable to see what's availible.


Best regards

Karl-Otto




--
Karl-Otto Rosenqvist
Mawingu
Orgnr: 750804-3937
0701- 75 98 56
karl-otto@...
https://mawingu.se

Re: Oldschool Highlight Tracking

derek riemer
 

We tried to get this to work in NVDA for dictation bridge. unfortunately, it doesn't work without regressing the performance of NVDA terribly, which is why our displayModel code does not support highlight coloration.

On Fri, Oct 4, 2019 at 11:34 AM Jason Meddaugh <jj@...> wrote:
Yes, it's SAM Broadcaster.

They've used the same interface for at least 10 years.



Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798

On 10/4/2019 5:18 AM, Brian's Mail list account via Groups.Io wrote:
> Might be of interest to anyone who  has some knowledge if you can name
> the program and version. Is it still available?
> Brian
>
> bglists@...
> Sent via blueyonder.
> Please address personal email to:-
> briang1@..., putting 'Brian Gaff'
> in the display name field.
> This message sent from a Windows XP machine!
> ----- Original Message ----- From: "Noelia Ruiz" <nrm1977@...>
> To: <nvda-devel@groups.io>
> Sent: Friday, October 04, 2019 7:18 AM
> Subject: Re: [nvda-devel] Oldschool Highlight Tracking
>
>
> Hi, hope someone completes the answer.
> You my find ideas from the poedit app module, though it tracks bold
> list items:
> https://github.com/nvaccess/nvda/blob/master/source/appModules/poedit.py
>
> Also, you may look at DisplayModelTextInfo class:
> https://github.com/nvaccess/nvda/blob/master/source/displayModel.py
>
> Not sure if this will be useful for you. Just as a suggestion.
>
> Cheers
>
>
> 2019-10-04 7:13 GMT+02:00, Jason Meddaugh <jj@...>:
>> Hello. I have a Windows app which uses highlight tracking to mark the
>> position in a list. SO to NVDA, it sees all of the items in the list as
>> text. The selected item is in a different color than the others.
>>
>>
>> Window-Eyes, for one, had a way to do highlight tracking since this was
>> more common in older apps.
>>
>>
>> Is there a way to take an object and grab the text of a specific color?
>> I am still pretty new to add-ons, but it seems like textinfos may be
>> able to do something similar.
>>
>>
>> Thanks for any ideas.
>>
>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Jason Meddaugh, President,
>> A T Guys
>> http://www.atguys.com
>> (269) 216-4798
>>
>>
>>
>>
>>
>
>
>
>
>
>





--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




Re: UIAutomation performance

francisco del roio
 

El 3/10/2019 a las 12:10, Karl-Otto Rosenqvist escribió:
Hi!
I'm a heavy Visual Studio user, both VS 2017 and 2019.

The main issue I have with Visual Studio and NVDA is that NVDA seems to
get overloaded with events or something when Visual Studio compiles in
the background. NVDA can't speak what's focused sometimes, quite often
sadly. When pressing Ctrl + Alt + L to set focus in the Solution Manager
I can move up and down in the treeview and NVDA is silent. I can press
F2 to get into edit mode for the file names or folder names and then
NVDA wakes up and speaks that text. Sometimes I restart NVDA in order to
get it on track again. Switching app with Alt + Tab and back again
sometimes makes it work.

I've tried to add registry keys to set higher priority for NVDA and
lower for some of the Visual Studio executables like the C# compiler but
that didn't make any difference.

The silence is always encountered when compiling and there are errors.
The error list is focused but NVDA doesn't speak because stuff happens
in the background. Because I lack patience I press Ctrl + C and then
Ctrl + Shift + C which I've mapped to say what's on the clipboard. If I
wait a loong time NVDA will begin speaking in that list too.

I haven't ramped up the logging to see what's causing the delay and I
don't know if there would be the info necessary to hunt down the problem.

One thing I've made to Visual Studio is changed the setting so when I
move around in the Solution Manager and selecting files they don't open
in the editor automatically. That have made the navigation of the
treeview smoother because NVDA got busy during the loading and
enterpretation of the file's contents.

I gladly experiment along with you to find the bottleneck because Visual
Studio is my main tool for developing WinForms and iOS apps.

Kind regards

Karl-Otto
Yes, I have these issues too. I think that NVDA logging doesn't provides
good information regarding this. I proposed a revamp of the logging
subsystem to track problems like this.

See this link:
https://github.com/nvaccess/nvda/issues/9977

Cheers,
--
Cuando tus fuerzas terminan, las de mi Dios comienzan.

phantom'a' spoken in file names

Brian's Mail list account
 

For some versions of nvda, I have noticed that espeak, though it may affect others too, say, as you save the file an a before the chosen file name.
It sounds sort of like if you call your file fred.mp3, then it says afred.m
However the a is much shorter in nature than a real a would be.
Its not serious, but more strange, has anyone else noticed this?
Brianp3

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: Oldschool Highlight Tracking

Jason Meddaugh
 

Yes, it's SAM Broadcaster.

They've used the same interface for at least 10 years.



Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798

On 10/4/2019 5:18 AM, Brian's Mail list account via Groups.Io wrote:
Might be of interest to anyone who  has some knowledge if you can name the program and version. Is it still available?
Brian

bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
This message sent from a Windows XP machine!
----- Original Message ----- From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-devel@groups.io>
Sent: Friday, October 04, 2019 7:18 AM
Subject: Re: [nvda-devel] Oldschool Highlight Tracking


Hi, hope someone completes the answer.
You my find ideas from the poedit app module, though it tracks bold list items:
https://github.com/nvaccess/nvda/blob/master/source/appModules/poedit.py

Also, you may look at DisplayModelTextInfo class:
https://github.com/nvaccess/nvda/blob/master/source/displayModel.py

Not sure if this will be useful for you. Just as a suggestion.

Cheers


2019-10-04 7:13 GMT+02:00, Jason Meddaugh <jj@...>:
Hello. I have a Windows app which uses highlight tracking to mark the
position in a list. SO to NVDA, it sees all of the items in the list as
text. The selected item is in a different color than the others.


Window-Eyes, for one, had a way to do highlight tracking since this was
more common in older apps.


Is there a way to take an object and grab the text of a specific color?
I am still pretty new to add-ons, but it seems like textinfos may be
able to do something similar.


Thanks for any ideas.






--
Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798







Re: Oldschool Highlight Tracking

Brian's Mail list account
 

Might be of interest to anyone who has some knowledge if you can name the program and version. Is it still available?
Brian

bglists@...
Sent via blueyonder.
Please address personal email to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
This message sent from a Windows XP machine!

----- Original Message -----
From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-devel@groups.io>
Sent: Friday, October 04, 2019 7:18 AM
Subject: Re: [nvda-devel] Oldschool Highlight Tracking


Hi, hope someone completes the answer.
You my find ideas from the poedit app module, though it tracks bold list items:
https://github.com/nvaccess/nvda/blob/master/source/appModules/poedit.py

Also, you may look at DisplayModelTextInfo class:
https://github.com/nvaccess/nvda/blob/master/source/displayModel.py

Not sure if this will be useful for you. Just as a suggestion.

Cheers


2019-10-04 7:13 GMT+02:00, Jason Meddaugh <jj@...>:
Hello. I have a Windows app which uses highlight tracking to mark the
position in a list. SO to NVDA, it sees all of the items in the list as
text. The selected item is in a different color than the others.


Window-Eyes, for one, had a way to do highlight tracking since this was
more common in older apps.


Is there a way to take an object and grab the text of a specific color?
I am still pretty new to add-ons, but it seems like textinfos may be
able to do something similar.


Thanks for any ideas.






--
Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798




Re: Oldschool Highlight Tracking

Noelia Ruiz
 

Hi, hope someone completes the answer.
You my find ideas from the poedit app module, though it tracks bold list items:
https://github.com/nvaccess/nvda/blob/master/source/appModules/poedit.py

Also, you may look at DisplayModelTextInfo class:
https://github.com/nvaccess/nvda/blob/master/source/displayModel.py

Not sure if this will be useful for you. Just as a suggestion.

Cheers


2019-10-04 7:13 GMT+02:00, Jason Meddaugh <jj@...>:

Hello. I have a Windows app which uses highlight tracking  to mark the
position in a list. SO to NVDA, it sees all of the items in the list as
text. The selected item is in a different color than the others.


Window-Eyes, for one, had a way to do highlight tracking since this was
more common in older apps.


Is there a way to take an object and grab the text of a specific color?
I am still pretty new to add-ons, but it seems like textinfos may be
able to do something similar.


Thanks for any ideas.






--
Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798




Oldschool Highlight Tracking

Jason Meddaugh
 

Hello. I have a Windows app which uses highlight tracking  to mark the position in a list. SO to NVDA, it sees all of the items in the list as text. The selected item is in a different color than the others.


Window-Eyes, for one, had a way to do highlight tracking since this was more common in older apps.


Is there a way to take an object and grab the text of a specific color? I am still pretty new to add-ons, but it seems like textinfos may be able to do something similar.


Thanks for any ideas.






--
Best regards,
Jason Meddaugh, President,
A T Guys
http://www.atguys.com
(269) 216-4798

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Noelia Ruiz
 

Just to clarify, my confusion was just a mistake, not a fault in NVDA. It was due to this code:

def isAddonTested(addon, backwardsCompatToVersion=addonAPIVersion.BACK_COMPAT_TO):
"""True if this add-on is tested for the given API version.
By default, the current version of NVDA is evaluated.
"""

But this is not the same than the default value for the add-on manifest.

Cheers

El 04/10/2019 a las 04:04, Noelia Ruiz via Groups.Io escribió:
Sorry, mistake: I meant that the last tested version, for development, could be set to the current alpha or beta. According with the developer guide it defaults to 0. Not to current. I will look at the code, since I maybe wrong, but I believe that I read that it defaults to te current versio used. I will look this again.
Enviado desde mi iPhone
El 4 oct 2019, a las 3:53, Noelia Ruiz via Groups.Io <nrm1977=gmail.com@groups.io <mailto:nrm1977=gmail.com@groups.io>> escribió:

You are reflecting interesting arguments. Anyway, I thing that this should be chosen by author in a case basis. Fon example, if they can avoid bugs before releasing an add-on under developmento or know them and dont need that people suffer these bugs, they can do it before. And in other cases, according with your arguments, authors can ommit the last tested version flag in add-ons under development or pre-released to be tested in alpha or beta versions of NVDA. Then, I think that the current flag is correctly designed, since it is not mandatory and, if it is not present, it will not enforze incompatibility and this can help to detect errors.
Very interesting.

Enviado desde mi iPhone

El 3 oct 2019, a las 16:29, derek riemer <driemer.riemer@... <mailto:driemer.riemer@...>> escribió:



On Wed, Oct 2, 2019 at 11:33 PM Noelia Ruiz <nrm1977@... <mailto:nrm1977@...>> wrote:

Hi, really, imo they shouldn't be exempt, since this could break
things
in the system like crashes

If you're signing up to test beta and alpha software, the expectation is that there will be crashes. I'd much rather a developer discover that their addon isn't compatible, or is crashing NVDA, so the flags can be updated, and make the ease of developing their addon maximally easy on developer editions, because these editions are designed to surface errors before they reach the general public. On developer editions, for example, addon authors get error sounds, which allow them to detect problems in the addon. I could be easily persuaded to allow the minimNVDAVersion flag to be honored in developer editions, for sure, but I'd rather not torture developers with untested addons warnings on developer editions of their screen reader. The number of testers of NVDA alpha snapshots is below 2% and eating into that number is extremely likely to lead to more bugs in stable NVDA versions. Every single tester of alpha is important, so we catch bugs before the beta editions and can iterate early in the design. Catching bugs in beta is also important, and the number of beta testters is slightly higher even in beta. If addons break, or are found to break in an alpha or beta version, that often can give the developer of such addons weeks or months of time to fix the addon before it hits the api incompatible version, leading to a better experience for the whole product.

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Noelia Ruiz
 

Sorry, mistake: I meant that the last tested version, for development, could be set to the current alpha or beta. According with the developer guide it defaults to 0. Not to current. I will look at the code, since I maybe wrong, but I believe that I read that it defaults to te current versio used. I will look this again.

Enviado desde mi iPhone

El 4 oct 2019, a las 3:53, Noelia Ruiz via Groups.Io <nrm1977@...> escribió:

You are reflecting interesting arguments. Anyway, I thing that this should be chosen by author in a case basis. Fon example, if they can avoid bugs before releasing an add-on under developmento or know them and dont need that people suffer these bugs, they can do it before. And in other cases, according with your arguments, authors can ommit the last tested version flag in add-ons under development or pre-released to be tested in alpha or beta versions of NVDA. Then, I think that the current flag is correctly designed, since it is not mandatory and, if it is not present, it will not enforze incompatibility and this can help to detect errors.
Very interesting.

Enviado desde mi iPhone

El 3 oct 2019, a las 16:29, derek riemer <driemer.riemer@...> escribió:



On Wed, Oct 2, 2019 at 11:33 PM Noelia Ruiz <nrm1977@...> wrote:
Hi, really, imo they shouldn't be exempt, since this could break things
in the system like crashes
If you're signing up to test beta and alpha software, the expectation is that there will be crashes. I'd much rather a developer discover that their addon isn't compatible, or is crashing NVDA, so the flags can be updated, and make the ease of developing their addon maximally easy on developer editions, because these editions are designed to surface errors before they reach the general public. On developer editions, for example, addon authors get error sounds, which allow them to detect problems in the addon. I could be easily persuaded to allow the minimNVDAVersion flag to be honored in developer editions, for sure, but I'd rather not torture developers with untested addons warnings on developer editions of their screen reader. The number of testers of NVDA alpha snapshots is below 2% and eating into that number is extremely likely to lead to more bugs in stable NVDA versions. Every single tester of alpha is important, so we catch bugs before the beta editions and can iterate early in the design. Catching bugs in beta is also important, and the number of beta testters is slightly higher even in beta. If addons break, or are found to break in an alpha or beta version, that often can give the developer of such addons weeks or months of time to fix the addon before it hits the api incompatible version, leading to a better experience for the whole product.

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Noelia Ruiz
 

You are reflecting interesting arguments. Anyway, I thing that this should be chosen by author in a case basis. Fon example, if they can avoid bugs before releasing an add-on under developmento or know them and dont need that people suffer these bugs, they can do it before. And in other cases, according with your arguments, authors can ommit the last tested version flag in add-ons under development or pre-released to be tested in alpha or beta versions of NVDA. Then, I think that the current flag is correctly designed, since it is not mandatory and, if it is not present, it will not enforze incompatibility and this can help to detect errors.
Very interesting.

Enviado desde mi iPhone

El 3 oct 2019, a las 16:29, derek riemer <driemer.riemer@...> escribió:



On Wed, Oct 2, 2019 at 11:33 PM Noelia Ruiz <nrm1977@...> wrote:
Hi, really, imo they shouldn't be exempt, since this could break things
in the system like crashes
If you're signing up to test beta and alpha software, the expectation is that there will be crashes. I'd much rather a developer discover that their addon isn't compatible, or is crashing NVDA, so the flags can be updated, and make the ease of developing their addon maximally easy on developer editions, because these editions are designed to surface errors before they reach the general public. On developer editions, for example, addon authors get error sounds, which allow them to detect problems in the addon. I could be easily persuaded to allow the minimNVDAVersion flag to be honored in developer editions, for sure, but I'd rather not torture developers with untested addons warnings on developer editions of their screen reader. The number of testers of NVDA alpha snapshots is below 2% and eating into that number is extremely likely to lead to more bugs in stable NVDA versions. Every single tester of alpha is important, so we catch bugs before the beta editions and can iterate early in the design. Catching bugs in beta is also important, and the number of beta testters is slightly higher even in beta. If addons break, or are found to break in an alpha or beta version, that often can give the developer of such addons weeks or months of time to fix the addon before it hits the api incompatible version, leading to a better experience for the whole product.

Re: UIAutomation performance

Karl-Otto Rosenqvist
 

Hi!
I'm a heavy Visual Studio user, both VS 2017 and 2019.

The main issue I have with Visual Studio and NVDA is that NVDA seems to get overloaded with events or something when Visual Studio compiles in the background. NVDA can't speak what's focused sometimes, quite often sadly. When pressing Ctrl + Alt + L to set focus in the Solution Manager I can move up and down in the treeview and NVDA is silent. I can press F2 to get into edit mode for the file names or folder names and then NVDA wakes up and speaks that text. Sometimes I restart NVDA in order to get it on track again. Switching app with Alt + Tab and back again sometimes makes it work.

I've tried to add registry keys to set higher priority for NVDA and lower for some of the Visual Studio executables like the C# compiler but that didn't make any difference.

The silence is always encountered when compiling and there are errors. The error list is focused but NVDA doesn't speak because stuff happens in the background. Because I lack patience I press Ctrl + C and then Ctrl + Shift + C which I've mapped to say what's on the clipboard. If I wait a loong time NVDA will begin speaking in that list too.

I haven't ramped up the logging to see what's causing the delay and I don't know if there would be the info necessary to hunt down the problem.

One thing I've made to Visual Studio is changed the setting so when I move around in the Solution Manager and selecting files they don't open in the editor automatically. That have made the navigation of the treeview smoother because NVDA got busy during the loading and enterpretation of the file's contents.

I gladly experiment along with you to find the bottleneck because Visual Studio is my main tool for developing WinForms and iOS apps.

Kind regards

Karl-Otto


Karl-Otto Rosenqvist
Mawingu
Orgnr: 750804-3937
0701- 75 98 56
karl-otto@...
https://mawingu.se

Den 2019-09-28 kl. 21:59, skrev francisco del roio:

El 28/9/2019 a las 13:16, Brian's Mail list account via Groups.Io escribió:
Not sure its uia related since the lack of a focus to a newly opened
folder in explorer or the first page in a browser seems to have been an
issue for many since I can remember. Its as if it is being missed and
the only way to make it work is to alter and return focus manually by
doing something major like opening a menu and closing it. It seems to be
one of those things that some people see all the time, while others
never do. Just guessing from your description on the alt key as I do not
use the program you mention myself.
Thanks,
Yes, issues like the ones you mentioned.
Visual Studio is UIA in its entirety, except for some parts that NVDA
recognizes as IAccessible/IAccessible2 objects. For example the Cloud
Explorer is an MSHTML document...
I think that Visual Studio is the best accessible IDE, however for some
reason there aren't so much blind developers using it, maybe because it
is focused to windows development with WPF/UWP or ASP.Net Core, and none
of these frameworks are popular in our community.
Back to the discussion, I have some monts trying to figure out where is
the problem.
Cheers,

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

derek riemer
 



On Wed, Oct 2, 2019 at 11:33 PM Noelia Ruiz <nrm1977@...> wrote:
Hi, really, imo they shouldn't be exempt, since this could break things
in the system like crashes
If you're signing up to test beta and alpha software, the expectation is that there will be crashes. I'd much rather a developer discover that their addon isn't compatible, or is crashing NVDA, so the flags can be updated, and make the ease of developing their addon maximally easy on developer editions, because these editions are designed to surface errors before they reach the general public. On developer editions, for example, addon authors get error sounds, which allow them to detect problems in the addon. I could be easily persuaded to allow the minimNVDAVersion flag to be honored in developer editions, for sure, but I'd rather not torture developers with untested addons warnings on developer editions of their screen reader. The number of testers of NVDA alpha snapshots is below 2% and eating into that number is extremely likely to lead to more bugs in stable NVDA versions. Every single tester of alpha is important, so we catch bugs before the beta editions and can iterate early in the design. Catching bugs in beta is also important, and the number of beta testters is slightly higher even in beta. If addons break, or are found to break in an alpha or beta version, that often can give the developer of such addons weeks or months of time to fix the addon before it hits the api incompatible version, leading to a better experience for the whole product.

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Noelia Ruiz
 

Hi, really, imo they shouldn't be exempt, since this could break things in the system like crashes, and I think that the current flags are appropriate, though I read the last developer guide and code, and in fact now I think that this value may be documented in a clearer way addressing the revised approach.

- lastTestedNVDAVersion (string): The last version of NVDA this add-on has been tested with.
- e.g "2019.1.0"
- Must be a three part version string I.E. Year.Major.Minor, or a two part version string of Year.Major. In the second case, Minor defaults to 0.
- Defaults to "0.0.0"
Imo, if this value is not always the maximum version supported, this should be clarified and even, the developer guide, since is updated for each NVDA stable release, could indicate the apiCompatto value, which is the minimum value required of last tested version in order than the current release can be compatible.


An option to clarify things about Andy's proposal could be, when apiCompatTo value is not the same a

El 03/10/2019 a las 04:54, derek riemer escribió:
I think alpha, beta, and RC should automatically exempt themselves from the last tested and minimum flags. That way, developers can battletest addons easily with these versions.
On Mon, Sep 30, 2019 at 7:21 AM Andy B. <sonfire11@... <mailto:sonfire11@...>> wrote:
I think maximum NVDA version should be required because we are
talking about a range of NVDA versions. It makes it clear to
developers and users, if included in add-on manager, that this
add-on supports the stated NVDA versions, even if they are
alpha/beta builds. Now, when stating a nonexistent version of NVDA,
such as alpha, beta, or threshold builds, maximum NVDA version
should indicate an api version such as 2019.3, but also include a
prerelease branch such as threshold, alpha, beta, or rc. After this,
we would have versions stated such as minimumNVDAVersion =
2019.3-alpha, or maximumNVDAVersion = 2019.3-beta1.____
__ __
Andy Borka____
Accessibility Engineer____
__ __
*From:* nvda-devel@groups.io <mailto:nvda-devel@groups.io>
<nvda-devel@groups.io <mailto:nvda-devel@groups.io>> *On Behalf Of
*Noelia Ruiz
*Sent:* Sunday, September 29, 2019 10:58 PM
*To:* nvda-devel@groups.io <mailto:nvda-devel@groups.io>
*Subject:* Re: [nvda-devel] Proposal: enforce minimum and last
tested NVDA version flags for add-on reviews and certification upon
2019.3 release?____
__ __
Regarding to the enforzement and the original question, I wass
missing, until I shared the code here, that for NVDA the last tested
version is always present and not an empty value, since it defaults
to the current NVDA version when the manifest doesnt declare it. So
the important think is that this doesnt break NVDA or system
stability. If an author doesnt want to specify last tested version
and the add-on is fully compatible, we cannot enforze this since
user experience pass. But if alpha versions of NVDA or the last
stable version is incompatible, since the test version is too low
and the add-on will be blocked, or even worse, if the author doesnt
specify a tested version and for this reason NVDA considers that the
add-on is good but in fact it break things, review should fail and
the ad-on shouldnt remain in the stable section of the website.____
Other question would be, as suggested by Andy (not directly),
clarify, in addons manager, the maximum version supported according
to the last tested value, for instance: last test version: 2019.-3
(max suported version: 2019.-4 of course when available). Not sure
if it would be needed.____
Cheers____
__ __
Enviado desde mi iPhone____
El 30 sept 2019, a las 2:40, Joseph Lee <@joslee
<mailto:@joslee>> escribió:____
Hi,____
The plan (which is really a separate thread at this point)
involves sending current NVDA version, along with add-on names,
their versions and update channel metadata. In return the client
will get update info for add-ons deemed compatible based on the
NVDA version sent to the server.____
Cheers,____
Joseph____
____
*From:* nvda-devel@groups.io <mailto:nvda-devel@groups.io>
<nvda-devel@groups.io <mailto:nvda-devel@groups.io>> *On Behalf
Of *derek riemer
*Sent:* Sunday, September 29, 2019 5:34 PM
*To:* nvda-devel@groups.io <mailto:nvda-devel@groups.io>
*Subject:* Re: [nvda-devel] Proposal: enforce minimum and last
tested NVDA version flags for add-on reviews and certification
upon 2019.3 release?____
____
That makes sense, I'm primarily concerned that users will have
to manually update all addons every version, even if they
literally didn't change. I think we should do the lastTested
thing serverSide, or at least offer a mechanism to update that
on the server eventually, so users don't need to download the
exactt same payload with just a different tested version if that
version is already tested..____
____
On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee
<@joslee <mailto:@joslee>>
wrote:____
Hi,____
At least Add-on Updater enforces this check for now unless
the strategy changes.____
Cheers,____
Joseph____
____
*From:* nvda-devel@groups.io <mailto:nvda-devel@groups.io>
<nvda-devel@groups.io <mailto:nvda-devel@groups.io>> *On
Behalf Of *derek riemer
*Sent:* Sunday, September 29, 2019 4:26 PM
*To:* nvda-devel@groups.io <mailto:nvda-devel@groups.io>
*Subject:* Re: [nvda-devel] Proposal: enforce minimum and
last tested NVDA version flags for add-on reviews and
certification upon 2019.3 release?____
____
I really don't think the last tested bit should be enforced
until we have an updator.____
____
On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz
<nrm1977@... <mailto:nrm1977@...>> wrote:____
El 29/09/2019 a las 18:18, Joseph Lee escribió:
> Hi,
> Actually, you do need to change last tested version
once 2019.4 comes out too, because that's how add-ons
manager will check for compatibility
I think this is not right (if I'm wrong I will apologize :)
The add-ons manager (or NVDA doesn't check for
compatibility directly
looking at last tested version, but to the api
containing the last
tested version. This is a way to let authors precissely
not to change
this flag each time NVDA has a new stable release. So,
when NVDA 2019.4
is out, we don't need to change this flag unless NVDA
has important
changes. NVDA 2019.3 is an exception due to Python 3
version and speech
refactor.
But generally this flag, if used, don't need to be changed.
Cheers
El 29/09/2019 a las 18:18, Joseph Lee escribió:
> Hi,
> Actually, you do need to change last tested version
once 2019.4 comes out too, because that's how add-ons
manager will check for compatibility (some folks found
out the hard way when attempting to install an add-on
that wasn't marked for 2019.3). The purpose of that flag
is for add-on authors to communicate that they did test
their add-ons in a specific NVDA release (or a
development snapshot for it), and ideally, source code
should match what the manifest claims. By doing so, it
reminds authors that they do need to keep up with
changes introduced in NVDA Core - the minimum flag won't
change much, but last tested flag will from time to time.
> As for communicating the purpose of that flag to
users: I can see confusion. Calling it "last tested
version" when in fact it specifies maximum compatible
version isn't a good communication to begin with,
because latest compatible and last tested versions are
likely to be different (for my add-ons at least, they
are really the same, although in public documentation I
always specify latest stable version for maximum
compatibility range because things under development can
change rapidly; but then again, for my add-ons, I
release development snapshots for some add-ons to keep
up with alpha changes, or as Eric Raymond once advised,
"release early, release often"). I think what can help
might be to listening to public definition of this flag,
and if they are not in line with the actual purpose of
it, to educate users as to what it actually means; if
there is indeed difference, perhaps come up with a
compromise or think about this flag again in a few months.
> Cheers,
> Joseph
>
> -----Original Message-----
> From: nvda-devel@groups.io
<mailto:nvda-devel@groups.io> <nvda-devel@groups.io
<mailto:nvda-devel@groups.io>> On Behalf Of Noelia Ruiz
> Sent: Sunday, September 29, 2019 8:54 AM
> To: nvda-devel@groups.io <mailto:nvda-devel@groups.io>
> Subject: Re: [nvda-devel] Proposal: enforce minimum
and last tested NVDA version flags for add-on reviews
and certification upon 2019.3 release?
>
> Hi, if you want to build versions for testers you
have to change the last tested version in the case of
NVDA 2019.3 due to deletions in the API, but probably,
when NVDA 2019.4 pre-releases or stable are published,
you will not need to change the last tested version. So,
the purpose of this field in the manifest maybe
clarified in the add-on template, but for me the name is
right since this doesn't mean the maximum version that
the add-on is intended to support, nor the last version
of NVDA beingbuild, nor the last stable.
> Cheers
>
>
> El 29/09/2019 a las 14:02, Andy B. escribió:
>> Well, not really. If I want to release add-on builds
for testers, I have to set the last tested version flag
to the current prerelease of NVDA. This isn't a problem,
but the flag's name is misleading at best. Minimum
version and maximum version as I mentioned before, are
self-documenting flags. There is no confusion that you
have to run at least NVDA 2019.1.1, and nothing later
than 2019.3 for this add-on to work.
>> Keep in mind that prospective add-on authors will
take a look at some of their favorite add-on's manifest
and source if they are interested in trying add-on
development. Doing this makes sense because the user is
already familiar with how the add-on works, so they can
follow along with their experience while looking at the
source. Unless a user is already somewhat buried in NVDA
development, minimum version makes sense, but last
tested version does not. Therefore, last tested version
should be changed to maximum version with a comment in
the manifest that maximum version is either equal to or
greater than minimum version, and that maximum version
may include prerelease versions of NVDA.
>>
>> # The lowest supported version of NVDA.
>> minimumNVDAVersion = 2019.1.1 # DTK does not support
2019.1 because it was initially created during 2019.1.1
release.
>> maximumNVDAVersion = 2019.3 # The current alpha
prelease cycle.
>>
>> I vote to have the flags changed to represent the
above example.
>>
>> Andy Borka
>> Accessibility Engineer
>>
>> -----Original Message-----
>> From: nvda-devel@groups.io
<mailto:nvda-devel@groups.io> <nvda-devel@groups.io
<mailto:nvda-devel@groups.io>> On Behalf Of Noelia
>> Ruiz
>> Sent: Saturday, September 28, 2019 2:06 PM
>> To: nvda-devel@groups.io <mailto:nvda-devel@groups.io>
>> Subject: Re: [nvda-devel] Proposal: enforce minimum
and last tested NVDA version flags for add-on reviews
and certification upon 2019.3 release?
>>
>> Imo the current name is right, since the latest
tested version can be minor of the latest supported
version. For example, you probably will not to update
the tested version in the manifest for developer toolkit
after when NVDA 2019.-4 is released, unless the api o
NVDA has important deletions and NV Access incrennt the
value for the bac compatibility.
>>
>>
>> Enviado desde mi iPhone
>>
>>> El 28 sept 2019, a las 17:53, Andy B.
<sonfire11@... <mailto:sonfire11@...>> escribió:
>>>
>>> Why don't we change lastTestedNVDAVersion to
maximumSupportedNVDABersion to align with the
minimumSupportedNVDAVersion flag? The purpose is much
more clearly stated and is self-documenting. After all,
the last tested NVDA version is nothing more than the
upper limit on what the add-on author is willing to support.
>>>
>>>
>>> Andy Borka
>>> Accessibility Engineer
>>>
>>> -----Original Message-----
>>> From: nvda-devel@groups.io
<mailto:nvda-devel@groups.io> <nvda-devel@groups.io
<mailto:nvda-devel@groups.io>> On Behalf Of Noelia
>>> Ruiz
>>> Sent: Saturday, September 28, 2019 2:39 AM
>>> To: nvda-devel@groups.io <mailto:nvda-devel@groups.io>
>>> Subject: Re: [nvda-devel] Proposal: enforce minimum
and last tested NVDA version flags for add-on reviews
and certification upon 2019.3 release?
>>>
>>> Hi, imo, the expression used (last NVDA version
tested) is right, since this is not speaking about
specific versions of NVDA (nor last stable, nor beta or
last master or future). Instead, this reflects what
version has been tested. This may be a superold version
of NVDA, and in this case, when you update to a version
of NVDA not tested with an installed add-on, the add-on
can be blocked so that it doesn't cause instability in
the system.
>>>
>>> Also, sometimes, for practical reasons, authors say
that an add-on has been tested with the upcoming version
of NVDA and NVDA allows it just for testing add-ons in
development, so that they can be ready when the next
stable version of NVDA is released.
>>> Cheers
>>>
>>>
>>>> El 27/09/2019 a las 20:02, Travis Siegel escribió:
>>>> I'm still curious how the last tested version of a
plugin can be for
>>>> a version that hasn't even been released yet.
>>>>
>>>> I argued during the whole invention of this scheme
that calling it
>>>> last tested version was a bad idea, but
apparently, nobody payed
>>>> attention. I strongly urge that this parameter get
a new name, since
>>>> it's impossible to test a nonexistent version for
compatibility.
>>>> Call it expected compatible, or next release
version or something,
>>>> but not last tested version, since there hasn't
been any testing for
>>>> a release that doesn't exist.  You're only
confusing people.
>>>>
>>>>
>>>>> On 9/26/2019 6:53 PM, Joseph Lee wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Yesterday there was a discussion on NVDA add-ons
list about Python
>>>>> 3 compatibility of add-ons and state of their
manifests. While some
>>>>> add-ons do declare 2019.3 as last tested version
and are indeed
>>>>> Python
>>>>> 3 ready, others such as Classic Selection is
Python 3 ready from
>>>>> source code level but not via the manifest. This
is a point of
>>>>> confusion because when installing such add-ons in
NVDA 2019.3, NVDA
>>>>> will say the add-on in question is incompatible.
>>>>>
>>>>> Thus I would like to propose that when reviewing
add-ons for
>>>>> inclusion in community add-ons website, reviewers
should perform
>>>>> manifest checks. If an add-on does use features
from a given
>>>>> release yet the manifest says otherwise, authors
should be notified
>>>>> and corrections must be made before the add-on is
included. In case
>>>>> of an add-on declaring last tested version as
something yet the
>>>>> source code says something else, it still needs
to be tested in the
>>>>> last tested version (and newer) specified so the
source code and the manifest is in sync.
>>>>> This check also helps authors realize that they
do need to update
>>>>> their manifests from time to time to keep up with
NVDA changes,
>>>>> because ideally, reviewers should not be the ones
telling authors
>>>>> to update their manifests unless it is necessary
to do so.
>>>>>
>>>>> As for when to enforce compatibility range check
(minimum version
>>>>> <= current version <= last tested version), I
propose January 1,
>>>>> 2020 as start date. This allows people to prepare
for both NVDA
>>>>> 2019.3 and this check at the same time. As for
what to do with
>>>>> add-ons that does not include minimum and last
tested version flags
>>>>> in their manifests, I think a notice should be
sent to authors so
>>>>> they can take care of it as soon as possible, or
if the author
>>>>> isn’t willing, NVDA community should do it (for
Classic Selection,
>>>>> it is Tyler Spivey who should be contacted).
>>>>>
>>>>> If this proposal is adopted by the community, I
propose sending out
>>>>> a notice about it several times:
>>>>>
>>>>>    * November 1, 2019: giving authors 60 days to
change their
>>>>> manifests
>>>>>      and do something about Python 3.
>>>>>    * One of the 2019.3 betas if NV Access agrees
with this proposal.
>>>>>    * NVDA 2019.3 RC and stable release: to remind
users about this
>>>>>      change if adopted.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Joseph
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>
____
-- ____
Derek Riemer
Improving the world one byte at a time! ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕
⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.
•    Personal website: https://derekriemer.com
____
-- ____
Derek Riemer
Improving the world one byte at a time! ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞
⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.
•    Personal website: https://derekriemer.com
____
__
--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.
•    Personal website: https://derekriemer.com

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

derek riemer
 

I think alpha, beta, and RC should automatically exempt themselves from the last tested and minimum flags. That way, developers can battletest addons easily with these versions.


On Mon, Sep 30, 2019 at 7:21 AM Andy B. <sonfire11@...> wrote:

I think maximum NVDA version should be required because we are talking about a range of NVDA versions. It makes it clear to developers and users, if included in add-on manager, that this add-on supports the stated NVDA versions, even if they are alpha/beta builds. Now, when stating a nonexistent version of NVDA, such as alpha, beta, or threshold builds, maximum NVDA version should indicate an api version such as 2019.3, but also include a prerelease branch such as threshold, alpha, beta, or rc. After this, we would have versions stated such as minimumNVDAVersion = 2019.3-alpha, or maximumNVDAVersion = 2019.3-beta1.

 

Andy Borka

Accessibility Engineer

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, September 29, 2019 10:58 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

 

Regarding to the enforzement and the original question, I wass missing, until I shared the code here, that for NVDA the last tested version is always present and not an empty value, since it defaults to the current NVDA version when the manifest doesnt declare it. So the important think is that this doesnt break NVDA or system stability. If an author doesnt want to specify last tested version and the add-on is fully compatible, we cannot enforze this since user experience pass. But if alpha versions of NVDA or the last stable version is incompatible, since the test version is too low and the add-on will be blocked, or even worse, if the author doesnt specify a tested version and for this reason NVDA considers that the add-on is good but in fact it break things, review should fail and the ad-on shouldnt remain in the stable section of the website.

Other question would be, as suggested by Andy (not directly), clarify, in addons manager, the maximum version supported according to the last tested value, for instance: last test version: 2019.-3 (max suported version: 2019.-4 of course when available). Not sure if it would be needed.

Cheers

 

Enviado desde mi iPhone


El 30 sept 2019, a las 2:40, Joseph Lee <joseph.lee22590@...> escribió:

Hi,

The plan (which is really a separate thread at this point) involves sending current NVDA version, along with add-on names, their versions and update channel metadata. In return the client will get update info for add-ons deemed compatible based on the NVDA version sent to the server.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 5:34 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

 

That makes sense, I'm primarily concerned that users will have to manually update all addons every version, even if they literally didn't change. I think we should do the lastTested thing serverSide, or at least offer a mechanism to update that on the server eventually, so users don't need to download the exactt same payload with just a different tested version if that version is already tested..

 

On Sun, Sep 29, 2019 at 6:32 PM Joseph Lee <joseph.lee22590@...> wrote:

Hi,

At least Add-on Updater enforces this check for now unless the strategy changes.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of derek riemer
Sent: Sunday, September 29, 2019 4:26 PM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

 

I really don't think the last tested bit should be enforced until we have an updator.

 

On Sun, Sep 29, 2019 at 10:28 AM Noelia Ruiz <nrm1977@...> wrote:

El 29/09/2019 a las 18:18, Joseph Lee escribió:
> Hi,
> Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility


I think this is not right (if I'm wrong I will apologize :)
The add-ons manager (or NVDA doesn't check for compatibility directly
looking at last tested version, but to the api containing the last
tested version. This is a way to let authors precissely not to change
this flag each time NVDA has a new stable release. So, when NVDA 2019.4
is out, we don't need to change this flag unless NVDA has important
changes. NVDA 2019.3 is an exception due to Python 3 version and speech
refactor.
But generally this flag, if used, don't need to be changed.

Cheers



El 29/09/2019 a las 18:18, Joseph Lee escribió:
> Hi,
> Actually, you do need to change last tested version once 2019.4 comes out too, because that's how add-ons manager will check for compatibility (some folks found out the hard way when attempting to install an add-on that wasn't marked for 2019.3). The purpose of that flag is for add-on authors to communicate that they did test their add-ons in a specific NVDA release (or a development snapshot for it), and ideally, source code should match what the manifest claims. By doing so, it reminds authors that they do need to keep up with changes introduced in NVDA Core - the minimum flag won't change much, but last tested flag will from time to time.
> As for communicating the purpose of that flag to users: I can see confusion. Calling it "last tested version" when in fact it specifies maximum compatible version isn't a good communication to begin with, because latest compatible and last tested versions are likely to be different (for my add-ons at least, they are really the same, although in public documentation I always specify latest stable version for maximum compatibility range because things under development can change rapidly; but then again, for my add-ons, I release development snapshots for some add-ons to keep up with alpha changes, or as Eric Raymond once advised, "release early, release often"). I think what can help might be to listening to public definition of this flag, and if they are not in line with the actual purpose of it, to educate users as to what it actually means; if there is indeed difference, perhaps come up with a compromise or think about this flag again in a few months.
> Cheers,
> Joseph
>
> -----Original Message-----
> From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
> Sent: Sunday, September 29, 2019 8:54 AM
> To: nvda-devel@groups.io
> Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
>
> Hi, if you want to build versions for testers you have to change the last tested version in the case of NVDA 2019.3 due to deletions in the API, but probably, when NVDA 2019.4 pre-releases or stable are published, you will not need to change the last tested version. So, the purpose of this field in the manifest maybe clarified in the add-on template, but for me the name is right since this doesn't mean the maximum version that the add-on is intended to support, nor the last version of NVDA beingbuild, nor the last stable.
> Cheers
>
>
> El 29/09/2019 a las 14:02, Andy B. escribió:
>> Well, not really. If I want to release add-on builds for testers, I have to set the last tested version flag to the current prerelease of NVDA. This isn't a problem, but the flag's name is misleading at best. Minimum version and maximum version as I mentioned before, are self-documenting flags. There is no confusion that you have to run at least NVDA 2019.1.1, and nothing later than 2019.3 for this add-on to work.
>> Keep in mind that prospective add-on authors will take a look at some of their favorite add-on's manifest and source if they are interested in trying add-on development. Doing this makes sense because the user is already familiar with how the add-on works, so they can follow along with their experience while looking at the source. Unless a user is already somewhat buried in NVDA development, minimum version makes sense, but last tested version does not. Therefore, last tested version should be changed to maximum version with a comment in the manifest that maximum version is either equal to or greater than minimum version, and that maximum version may include prerelease versions of NVDA.
>>
>> # The lowest supported version of NVDA.
>> minimumNVDAVersion = 2019.1.1 # DTK does not support 2019.1 because it was initially created during 2019.1.1 release.
>> maximumNVDAVersion = 2019.3 # The current alpha prelease cycle.
>>
>> I vote to have the flags changed to represent the above example.
>>
>> Andy Borka
>> Accessibility Engineer
>>
>> -----Original Message-----
>> From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia
>> Ruiz
>> Sent: Saturday, September 28, 2019 2:06 PM
>> To: nvda-devel@groups.io
>> Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
>>
>> Imo the current name is right, since the latest tested version can be minor of the latest supported version. For example, you probably will not to update the tested version in the manifest for developer toolkit after when NVDA 2019.-4 is released, unless the api o NVDA has important deletions and NV Access incrennt the value for the bac compatibility.
>>
>>
>> Enviado desde mi iPhone
>>
>>> El 28 sept 2019, a las 17:53, Andy B. <sonfire11@...> escribió:
>>>
>>> Why don't we change lastTestedNVDAVersion to maximumSupportedNVDABersion to align with the minimumSupportedNVDAVersion flag? The purpose is much more clearly stated and is self-documenting. After all, the last tested NVDA version is nothing more than the upper limit on what the add-on author is willing to support.
>>>
>>>
>>> Andy Borka
>>> Accessibility Engineer
>>>
>>> -----Original Message-----
>>> From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia
>>> Ruiz
>>> Sent: Saturday, September 28, 2019 2:39 AM
>>> To: nvda-devel@groups.io
>>> Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?
>>>
>>> Hi, imo, the expression used (last NVDA version tested) is right, since this is not speaking about specific versions of NVDA (nor last stable, nor beta or last master or future). Instead, this reflects what version has been tested. This may be a superold version of NVDA, and in this case, when you update to a version of NVDA not tested with an installed add-on, the add-on can be blocked so that it doesn't cause instability in the system.
>>>
>>> Also, sometimes, for practical reasons, authors say that an add-on has been tested with the upcoming version of NVDA and NVDA allows it just for testing add-ons in development, so that they can be ready when the next stable version of NVDA is released.
>>> Cheers
>>>
>>>
>>>> El 27/09/2019 a las 20:02, Travis Siegel escribió:
>>>> I'm still curious how the last tested version of a plugin can be for
>>>> a version that hasn't even been released yet.
>>>>
>>>> I argued during the whole invention of this scheme that calling it
>>>> last tested version was a bad idea, but apparently, nobody payed
>>>> attention. I strongly urge that this parameter get a new name, since
>>>> it's impossible to test a nonexistent version for compatibility.
>>>> Call it expected compatible, or next release version or something,
>>>> but not last tested version, since there hasn't been any testing for
>>>> a release that doesn't exist.  You're only confusing people.
>>>>
>>>>
>>>>> On 9/26/2019 6:53 PM, Joseph Lee wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Yesterday there was a discussion on NVDA add-ons list about Python
>>>>> 3 compatibility of add-ons and state of their manifests. While some
>>>>> add-ons do declare 2019.3 as last tested version and are indeed
>>>>> Python
>>>>> 3 ready, others such as Classic Selection is Python 3 ready from
>>>>> source code level but not via the manifest. This is a point of
>>>>> confusion because when installing such add-ons in NVDA 2019.3, NVDA
>>>>> will say the add-on in question is incompatible.
>>>>>
>>>>> Thus I would like to propose that when reviewing add-ons for
>>>>> inclusion in community add-ons website, reviewers should perform
>>>>> manifest checks. If an add-on does use features from a given
>>>>> release yet the manifest says otherwise, authors should be notified
>>>>> and corrections must be made before the add-on is included. In case
>>>>> of an add-on declaring last tested version as something yet the
>>>>> source code says something else, it still needs to be tested in the
>>>>> last tested version (and newer) specified so the source code and the manifest is in sync.
>>>>> This check also helps authors realize that they do need to update
>>>>> their manifests from time to time to keep up with NVDA changes,
>>>>> because ideally, reviewers should not be the ones telling authors
>>>>> to update their manifests unless it is necessary to do so.
>>>>>
>>>>> As for when to enforce compatibility range check (minimum version
>>>>> <= current version <= last tested version), I propose January 1,
>>>>> 2020 as start date. This allows people to prepare for both NVDA
>>>>> 2019.3 and this check at the same time. As for what to do with
>>>>> add-ons that does not include minimum and last tested version flags
>>>>> in their manifests, I think a notice should be sent to authors so
>>>>> they can take care of it as soon as possible, or if the author
>>>>> isn’t willing, NVDA community should do it (for Classic Selection,
>>>>> it is Tyler Spivey who should be contacted).
>>>>>
>>>>> If this proposal is adopted by the community, I propose sending out
>>>>> a notice about it several times:
>>>>>
>>>>>    * November 1, 2019: giving authors 60 days to change their
>>>>> manifests
>>>>>      and do something about Python 3.
>>>>>    * One of the 2019.3 betas if NV Access agrees with this proposal.
>>>>>    * NVDA 2019.3 RC and stable release: to remind users about this
>>>>>      change if adopted.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Joseph
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>




--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com





--

Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com






--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com




Re: Error when trying to update NVDA to 2019.2.1

Noelia Ruiz
 

Mick has asked if it was fixed for us and I closed the issue, since
now it works:

https://github.com/nvaccess/nvda/issues/10311

Thanks.

2019-10-02 11:21 GMT+02:00, Leonard de Ruijter <@leonardder>:

Thanks Noelia. Pretty sure it is an issue on the update server, Mick
will hopefully address this shortly.


Regards,

Leonard




Re: Error when trying to update NVDA to 2019.2.1

Brian's Mail list account
 

Its now working again. I now have three copies of the latest stable and a beta which says there are no updates, plus an alpha snap.
Not sure where the beta fits in yet.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io>
To: <nvda-devel@groups.io>
Sent: Wednesday, October 02, 2019 10:36 AM
Subject: Re: [nvda-devel] Error when trying to update NVDA to 2019.2.1


Yes me too, so I'm not going to do a manual update.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-devel@groups.io>
Sent: Wednesday, October 02, 2019 9:45 AM
Subject: [nvda-devel] Error when trying to update NVDA to 2019.2.1


Hi, thanks for fixing critical bugs in this version. I get this error:

ERROR - unhandled exception (10:35:03.559):
Traceback (most recent call last):
File "updateCheck.pyo", line 733, in onClose
File "updateCheck.pyo", line 417, in _download
File "updateCheck.pyo", line 553, in __init__
KeyError: 'apiVersion

Cheers



Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Andy B.
 

If we do this, the naming of flags is important. Since last tested version
only checks an API version (how confusing is that?), it should be changed to
something more relevant. Last API version would make sense, but only if we
made use of min/max NVDA versions.
Minimum NVDA version: minimum version of NVDA the add-on will run against.
Anything lower will not work.
Maximum NVDA version: Maximum version of NVDA the add-on will run against.
Anything higher is not guaranteed.
Last tested API: The last API version the add-on was tested against. Useful
for development builds or testing. This is a soft limit not enforced by
NVDA, but only a guideline on the add-on's progress if the developer wishes
to make the statement.

Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Luke Davis
Sent: Wednesday, October 2, 2019 1:35 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA
version flags for add-on reviews and certification upon 2019.3 release?

I believe the Firefox case was raised by Jason earlier: how does Mozilla (or
other software) handle addon compatibility enforcement and deprecation? I am
reasonably sure all Firefox add-ons don't get updated every time Firefox
does, but I am also sure that some add-ons do eventually get terminated by
Firefox itself when they become known to be incompatible. But that is only
my assumption about how it works, I don't actually know.

I dislike the idea that every time NVDA does a release, whether it changes
the part of the API which an add-on relies on or not, the author has to
pre-update the add-on. Even if that is just changing a value in the
manifest, how many add-ons many people rely on today, would still be working
if that was enforced now?

So I guess I agree with Noelia about last-tested's purpose.

I am wondering now if we might actually need two values:

1. An advisory value, that the author uses to specify "I only guarantee
support up to this level of NVDA for this version of the add-on". That is a
sort of soft max value, that doesn't actually keep later versions of NVDA
from using the add-on by itself.
That would be what last-tested is supposedly doing now except in the case of
2019.3.
There are many reasons an author can't update an add-on right away upon a
new NVDA release (or even a few of them, if they are "fast" point releases);
and reasons a user may not be updating add-ons right away, especially given
the current update framework.

NVDA itself could always be coded so that a version known to break the API,
will make that soft "last tested" value into a hard "max compatibility"
value on the fly, and refuse to run an add-on. But that should be rare, only
happening in cases like this change to Python 3 and speech refactor.

2. The second value, is for when we know an add-on doesn't work with a
future version of NVDA. A hard max compatibility version.
Of course, not all add-ons (perhaps not even most) should specify that,
because they can't know what future version will break their code.
That is where I see a case for allowing administrators to update a manifest
based on known broken add-ons to specify the max version.
But we definitely know that value now, for add-ons that only work up to the
last Python 2 version of NVDA. Something like that could allow old and new
add-on versions to exist in relative harmony.

Just an idea.

Luke


On Mon, 30 Sep 2019, Andy B. wrote:

The last tested version is a supported version because a developer
will most likely not release an add-on with a nonexistent version of
NVDA, or leave last tested version set to an NVDA version in which the
add-on itself is broken.
This might work for testers, but not for the general public.
Understanding that minimum NVDA version and maximum NVDA version are
the min/max NVDA versions the add-on supports or is built for, helps
the user understand what he or she is getting into by installing this
add-on.

Re: Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Andy B.
 

This brings up a point I am trying to make... New add-on developers may not have any idea where to look for the documentation on last tested version. The goal of any software is to be as self-documenting as possible. So far, NVDA miserably fails on this point, at least for new add-on developers. As I mentioned, users wanting to have a try at add-on development will get lost quickly, as I did at one time.
NVDA, like any software package offering an API, should be as self-documenting as possible. To do this, last tested version should get changed to maximum NVDA version. Then it is self-evident what the flag does.


Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Wednesday, October 2, 2019 3:16 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?

Hi Luke and all:

I think that the meaning of the last tested version is documented, and if we read code and related issues and pull request can know that it's intended to avoid than authors need to update add-ons which can work well in the upcoming release of NVDA. In fact, the approach of api versions wass revised. Maybe useful an article in the NV Access wiki, though really for me this discussion is quite surprissing.
I would always recommend to specify last tested version and the other values of the manifest, as done by NV Access (I read it in the developer guide time ago). So we can be quite sure that add-ons don't break things if NVDA is updated. Also, if authors have time and availability, they can choose to update the last test version so that users can see it in the about button of the add-on. But imo this shouldn't be mandatory and is documented time ago.

Cheers


El 02/10/2019 a las 07:34, Luke Davis escribió:
I believe the Firefox case was raised by Jason earlier: how does
Mozilla (or other software) handle addon compatibility enforcement and
deprecation? I am reasonably sure all Firefox add-ons don't get
updated every time Firefox does, but I am also sure that some add-ons
do eventually get terminated by Firefox itself when they become known
to be incompatible. But that is only my assumption about how it works,
I don't actually know.

I dislike the idea that every time NVDA does a release, whether it
changes the part of the API which an add-on relies on or not, the
author has to pre-update the add-on. Even if that is just changing a
value in the manifest, how many add-ons many people rely on today,
would still be working if that was enforced now?

So I guess I agree with Noelia about last-tested's purpose.

I am wondering now if we might actually need two values:

1. An advisory value, that the author uses to specify "I only
guarantee support up to this level of NVDA for this version of the
add-on". That is a sort of soft max value, that doesn't actually keep
later versions of NVDA from using the add-on by itself.
That would be what last-tested is supposedly doing now except in the
case of 2019.3.
There are many reasons an author can't update an add-on right away
upon a new NVDA release (or even a few of them, if they are "fast"
point releases); and reasons a user may not be updating add-ons right
away, especially given the current update framework.

NVDA itself could always be coded so that a version known to break the
API, will make that soft "last tested" value into a hard "max
compatibility" value on the fly, and refuse to run an add-on. But that
should be rare, only happening in cases like this change to Python 3
and speech refactor.

2. The second value, is for when we know an add-on doesn't work with a
future version of NVDA. A hard max compatibility version.
Of course, not all add-ons (perhaps not even most) should specify
that, because they can't know what future version will break their code.
That is where I see a case for allowing administrators to update a
manifest based on known broken add-ons to specify the max version.
But we definitely know that value now, for add-ons that only work up
to the last Python 2 version of NVDA. Something like that could allow
old and new add-on versions to exist in relative harmony.

Just an idea.

Luke


On Mon, 30 Sep 2019, Andy B. wrote:

The last tested version is a supported version because a developer
will most likely not release an add-on with a nonexistent version of
NVDA, or leave last tested version set to an NVDA version in which
the add-on itself is broken. This might work for testers, but not for
the general public. Understanding that minimum NVDA version and
maximum NVDA version are the min/max NVDA versions the add-on
supports or is built for, helps the user understand what he or she is
getting into by installing this add-on.