Date   
A new error?

Brian's Mail list account
 

Don't think I've seen this one before. should I be worried?
IO - speech.speak (16:40:58.573) - MainThread (5604):
Speaking [LangChangeCommand ('en_GB'), 'oleacc.AccessibleObjectFromEvent with window 327702, objectID 475 and childID 0: [WinError -2147467259] Unspecified error\r']

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

Re: A new error?

Cyrille
 

Hello Brian

This unique line tells us that you were reading a line of the log where this
error occurred.
But without context, we cannot know if you were reading your log or the one
of someone else, e.g. in an e-mail or on Github. We cannot know what you
were doing...

Cyrille

-----Message d'origine-----
De : nvda-devel@groups.io <nvda-devel@groups.io> De la part de Brian's Mail
list account via Groups.Io
Envoyé : lundi 23 septembre 2019 17:54
À : NVDA Dev list on groups.io <nvda-devel@groups.io>
Objet : [nvda-devel] A new error?

Don't think I've seen this one before. should I be worried?
IO - speech.speak (16:40:58.573) - MainThread (5604):
Speaking [LangChangeCommand ('en_GB'), 'oleacc.AccessibleObjectFromEvent
with window 327702, objectID 475 and childID 0: [WinError -2147467259]
Unspecified error\r']

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

Re: A new error?

Brian's Mail list account
 

Oh It was mine, I was just intrigued what it mean, as I see it a lot in alpha snaps but there seems to be no ding or indeed any kind of obvious issue.

Sorry if it confused you!

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: "Cyrille via Groups.Io" <cyrille.bougot2=laposte.net@groups.io>
To: <nvda-devel@groups.io>
Sent: Monday, September 23, 2019 8:00 PM
Subject: Re: [nvda-devel] A new error?


Hello Brian

This unique line tells us that you were reading a line of the log where this
error occurred.
But without context, we cannot know if you were reading your log or the one
of someone else, e.g. in an e-mail or on Github. We cannot know what you
were doing...

Cyrille



-----Message d'origine-----
De : nvda-devel@groups.io <nvda-devel@groups.io> De la part de Brian's Mail
list account via Groups.Io
Envoyé : lundi 23 septembre 2019 17:54
À : NVDA Dev list on groups.io <nvda-devel@groups.io>
Objet : [nvda-devel] A new error?

Don't think I've seen this one before. should I be worried?
IO - speech.speak (16:40:58.573) - MainThread (5604):
Speaking [LangChangeCommand ('en_GB'), 'oleacc.AccessibleObjectFromEvent
with window 327702, objectID 475 and childID 0: [WinError -2147467259]
Unspecified error\r']

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

Re: A new error?

James Scholes
 

If there's no problematic behaviour, it's not a problem.

Regards,

James Scholes

On 23/09/2019 at 8:46 pm, Brian's Mail list account via Groups.Io wrote:
Oh It was mine, I was just intrigued what it mean, as I see it a lot in alpha snaps but there seems to be no ding or indeed any kind of obvious issue.
Sorry if it confused you!
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: "Cyrille via Groups.Io" <cyrille.bougot2=laposte.net@groups.io>
To: <nvda-devel@groups.io>
Sent: Monday, September 23, 2019 8:00 PM
Subject: Re: [nvda-devel] A new error?
Hello Brian
This unique line tells us that you were reading a line of the log where this
error occurred.
But without context, we cannot know if you were reading your log or the one
of someone else, e.g. in an e-mail or on Github. We cannot know what you
were doing...
Cyrille
-----Message d'origine-----
De : nvda-devel@groups.io <nvda-devel@groups.io> De la part de Brian's Mail
list account via Groups.Io
Envoyé : lundi 23 septembre 2019 17:54
À : NVDA Dev list on groups.io <nvda-devel@groups.io>
Objet : [nvda-devel] A new error?
Don't think I've seen this one before. should I be worried?
IO - speech.speak (16:40:58.573) - MainThread (5604):
Speaking [LangChangeCommand ('en_GB'), 'oleacc.AccessibleObjectFromEvent
with window 327702, objectID 475 and childID 0: [WinError -2147467259]
Unspecified error\r']
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

Re: A new error?

Brian's Mail list account
 

Well not entirely true. I have been around long enough to have seen some that show no immediate issues but end up in a crash due to memory leaks and the like so I always mention something different, just in case.
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: "James Scholes" <james@...>
To: <nvda-devel@groups.io>
Sent: Monday, September 23, 2019 8:49 PM
Subject: Re: [nvda-devel] A new error?


If there's no problematic behaviour, it's not a problem.

Regards,

James Scholes

On 23/09/2019 at 8:46 pm, Brian's Mail list account via Groups.Io wrote:
Oh It was mine, I was just intrigued what it mean, as I see it a lot in alpha snaps but there seems to be no ding or indeed any kind of obvious issue.

Sorry if it confused you!

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: "Cyrille via Groups.Io" <cyrille.bougot2=laposte.net@groups.io>
To: <nvda-devel@groups.io>
Sent: Monday, September 23, 2019 8:00 PM
Subject: Re: [nvda-devel] A new error?


Hello Brian

This unique line tells us that you were reading a line of the log where this
error occurred.
But without context, we cannot know if you were reading your log or the one
of someone else, e.g. in an e-mail or on Github. We cannot know what you
were doing...

Cyrille



-----Message d'origine-----
De : nvda-devel@groups.io <nvda-devel@groups.io> De la part de Brian's Mail
list account via Groups.Io
Envoyé : lundi 23 septembre 2019 17:54
À : NVDA Dev list on groups.io <nvda-devel@groups.io>
Objet : [nvda-devel] A new error?

Don't think I've seen this one before. should I be worried?
IO - speech.speak (16:40:58.573) - MainThread (5604):
Speaking [LangChangeCommand ('en_GB'), 'oleacc.AccessibleObjectFromEvent
with window 327702, objectID 475 and childID 0: [WinError -2147467259]
Unspecified error\r']

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










Re: Latest alpha, cannot create portable copy

Brian's Mail list account
 

Seems to work on this mornings update thus far.

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: Monday, September 23, 2019 4:51 PM
Subject: Re: [nvda-devel] Latest alpha, cannot create portable copy


I see this has caused some activity on the ticket I raised, best wait till the fix is approved as its not in the current snap as 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: Monday, September 23, 2019 9:57 AM
Subject: Re: [nvda-devel] Latest alpha, cannot create portable copy


here is the log entry. This straight from the auto download of the version.

entering wx application main loop
ERROR - gui.installerGui.doCreatePortable (09:47:32.418) - MainThread (4576):
Failed to create portable copy
Traceback (most recent call last):
File "gui\installerGui.pyc", line 359, in doCreatePortable
File "gui\__init__.pyc", line 900, in __init__
File "threading.pyc", line 1077, in name
AssertionError: Thread.__init__() not called
IO - speech.speak (09:47:32.444) - MainThread (4576):
Speaking [LangChangeCommand ('en_GB'), 'Desktop list']


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 Dev list on groups.io" <nvda-devel@groups.io>
Sent: Monday, September 23, 2019 9:50 AM
Subject: [nvda-devel] Latext alpha, Cannot creae portable copy


thread.init not called.
No idea what this means.
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





nvdaControllerClient.dll

Vincent Le Goff
 

Hi everyone,


Sorry for insisting on this topic, but as a developer I would appreciate if my applications remain accessible despite the change in NVDA's programming language.  In short: will I need to update the nvdaControllerClient.dll file to "talk" to NVDA?  And if so, how will I maintain compatibility with people using older versions of NVDA?  I admit I have no idea if a dll file built for Python 2 will need to be updated for Python 3, but the date is drawing near and I will need to know what to do, if I don't want to run the risk of my applications becoming inaccessible to NVDA users.


Thanks in advance!


Vincent

Re : [nvda-devel] nvdaControllerClient.dll

Cyrille
 

Hello Vincent
I have no knowledge on how this DLL is interfaced with NVDA.
However, I had created once an exe linking this DLL to control NVDA speaking via command line. I have not modified or recompiled the exe neither the DLL I was using and I can confirm you that this is still working with latest alpha.
Cyrille
----- Mail d'origine -----
De: Vincent Le Goff <vincent.legoff.srs@...>
À: nvda-devel@groups.io
Envoyé: Tue, 24 Sep 2019 12:44:10 +0200 (CEST)
Objet: [nvda-devel] nvdaControllerClient.dll

Hi everyone,

Sorry for insisting on this topic, but as a developer I would
appreciate if my applications remain accessible despite the change
in NVDA's programming language.  In short: will I need to update
the nvdaControllerClient.dll file to "talk" to NVDA?  And if
so, how will I maintain compatibility with people using older
versions of NVDA?  I admit I have no idea if a dll file built
for Python 2 will need to be updated for Python 3, but the date
is drawing near and I will need to know what to do, if I don't
want to run the risk of my applications becoming inaccessible to
NVDA users.

 

Thanks in advance!

 

Vincent

Re: nvdaControllerClient.dll

James Scholes
 

The controller client is implemented in C++, so is not necessarily subject to direct changes during the Python 3 transition. I would expect any internal changes to NVDA's speech and other frameworks to be handled in a backward-compatible way.

Regards,

James Scholes

On 24/09/2019 at 11:44 am, Vincent Le Goff wrote:
Hi everyone,
Sorry for insisting on this topic, but as a developer I would appreciate if my applications remain accessible despite the change in NVDA's programming language.  In short: will I need to update the nvdaControllerClient.dll*file to "talk" to NVDA?  And if so, how will I maintain compatibility with people using older versions of NVDA?  I admit I have no idea if a dll file built for Python 2 will need to be updated for Python 3, but the date is drawing near and I will need to know what to do, if I don't want to run the risk of my applications becoming inaccessible to NVDA users.*
*
*
*Thanks in advance!*
*
*
*Vincent*

Re: nvdaControllerClient.dll

Vincent Le Goff
 

That's a good news, thanks.

On 9/24/2019 1:56 PM, James Scholes wrote:
The controller client is implemented in C++, so is not necessarily subject to direct changes during the Python 3 transition.  I would expect any internal changes to NVDA's speech and other frameworks to be handled in a backward-compatible way.

Regards,

James Scholes

On 24/09/2019 at 11:44 am, Vincent Le Goff wrote:
Hi everyone,


Sorry for insisting on this topic, but as a developer I would appreciate if my applications remain accessible despite the change in NVDA's programming language.  In short: will I need to update the nvdaControllerClient.dll*file to "talk" to NVDA?  And if so, how will I maintain compatibility with people using older versions of NVDA?  I admit I have no idea if a dll file built for Python 2 will need to be updated for Python 3, but the date is drawing near and I will need to know what to do, if I don't want to run the risk of my applications becoming inaccessible to NVDA users.*

*
*

*Thanks in advance!*

*
*

*Vincent*

NVDA add-on Developer toolkit 2020.1.1 is now available!

Andy B.
 

Hi,

 

The NVDA add-on, Developer toolkit, is now available for download. You can find it here: https://github.com/ajborka/nvda_developer_toolkit/releases/tag/2020.1.1. This version improves Unicode support by explicitly defining Unicode strings that are compatible with Python 3. All users of DTK should test the Unicode support with NVDA 2019.1 and later. I am more interested in the results people have with NVDA alpha snaps moving forward. Please test and let me know your results, good or bad

 

Andy Borka

Accessibility Engineer

 

Re: NVDA add-on Developer toolkit 2020.1.1 is now available!

Tage Johansson
 

Hi,


Seems like a very interesting addon and I should probably try it out soon.


I think that even if it may be obvious, it is good practise to have a section in the README which describes how to install the addon.

Nearly every README I've seen on github describes how to install/compile/run it, or there is at least a link to an installation guide. I think that a such installation instruction helps alot for new users who just want to try it out.


This was just a small pedantic suggestion, and I'm sorry if you think that I dig to deep into details.


Best regards,

Tage


On 9/24/2019 5:10 PM, Andy B. wrote:

Hi,

 

The NVDA add-on, Developer toolkit, is now available for download. You can find it here: https://github.com/ajborka/nvda_developer_toolkit/releases/tag/2020.1.1. This version improves Unicode support by explicitly defining Unicode strings that are compatible with Python 3. All users of DTK should test the Unicode support with NVDA 2019.1 and later. I am more interested in the results people have with NVDA alpha snaps moving forward. Please test and let me know your results, good or bad

 

Andy Borka

Accessibility Engineer

 

Re: NVDA add-on Developer toolkit 2020.1.1 is now available!

Andy B.
 

Noted for the next release…

 

 

Andy Borka

Accessibility Engineer

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Tage Johansson
Sent: Tuesday, September 24, 2019 11:26 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] NVDA add-on Developer toolkit 2020.1.1 is now available!

 

Hi,

 

Seems like a very interesting addon and I should probably try it out soon.

 

I think that even if it may be obvious, it is good practise to have a section in the README which describes how to install the addon.

Nearly every README I've seen on github describes how to install/compile/run it, or there is at least a link to an installation guide. I think that a such installation instruction helps alot for new users who just want to try it out.

 

This was just a small pedantic suggestion, and I'm sorry if you think that I dig to deep into details.

 

Best regards,

Tage

 

On 9/24/2019 5:10 PM, Andy B. wrote:

Hi,

 

The NVDA add-on, Developer toolkit, is now available for download. You can find it here: https://github.com/ajborka/nvda_developer_toolkit/releases/tag/2020.1.1. This version improves Unicode support by explicitly defining Unicode strings that are compatible with Python 3. All users of DTK should test the Unicode support with NVDA 2019.1 and later. I am more interested in the results people have with NVDA alpha snaps moving forward. Please test and let me know your results, good or bad

 

Andy Borka

Accessibility Engineer

 

I see nvda 2019.2.1 beta 1 is about now

Brian's Mail list account
 

Just noting the fact as I'd not seen it mentioned on other lists 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

The Klite Codec pack inaccessible?

Brian's Mail list account
 

Has anyone tried to update or install this recently with nvda?
I know it used to work, but now it seems many choices can be heard in screen navigation mode but not selected though some buttons do still work.
Does anyone know who to talk to for this installer?
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

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

 

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

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

Noelia Ruiz
 

As mentioned, in this discussion for me is clear that the webpage should talk about compatibility with NVDA 2019.3, or something like that, prioritizing the purpose of the informative webpage, which could serve to inform if a particular add-on will work as expected if users update NVDA 2019.2 to 2019.3.
Users may not know about Python versions or other changes in the api like speech refactor. This is useful for devs and reviewers, not for other users.
About planning times, imo add-ons should be updated before NVDA 2019.3 stable is released, sho users can update NVDA without issues. This is important for NVDa development and even donations to NV Access, since some people may be used to donate when stable versions are released (personally I try to do so generally).
Also, we can try to enforze or talk to authors about dates, but it's up to them to follow our recommendations. We can just admin the website.
This is my opinion.
Cheers

El 27/09/2019 a las 00:53, Joseph Lee escribió:
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

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

Brian's Mail list account
 

OK I do think you are right here. On e has to draw a line in the sand at some point or it gets confusing, not only to users, but those building add ons. I also do agree that if a fix is simply a couple of lines of source and the manifest, if the author has not fixed it and somebody has made it work, it should be possible for that version to be added as an unofficial dev version for testing and if it seems stable and works the modifier can be added to the author list and the add on declared stable. Not all authors are still around of course, since life is like that and it would be a great shame if functions in some of these add ons are lost just because a couple of lines of source and a manifest tweak are needed. Obviously, very complex add ons such as the pesky 3D sounds one, are probably beyond the scope of 'simple fix' solutions. grin.
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: "Joseph Lee" <@joslee>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Thursday, September 26, 2019 11:53 PM
Subject: [nvda-devel] Proposal: enforce minimum and last tested NVDA version flags for add-on reviews and certification upon 2019.3 release?


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



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

Andy B.
 

Try and keep the technical stuff away from the typical user. As you said, they could care less, or not understand anything about Python. They just want something that works without problems.


Andy Borka
Accessibility Engineer

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Noelia Ruiz
Sent: Thursday, September 26, 2019 11:50 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?

As mentioned, in this discussion for me is clear that the webpage should talk about compatibility with NVDA 2019.3, or something like that, prioritizing the purpose of the informative webpage, which could serve to inform if a particular add-on will work as expected if users update NVDA 2019.2 to 2019.3.
Users may not know about Python versions or other changes in the api like speech refactor. This is useful for devs and reviewers, not for other users.
About planning times, imo add-ons should be updated before NVDA 2019.3 stable is released, sho users can update NVDA without issues. This is important for NVDa development and even donations to NV Access, since some people may be used to donate when stable versions are released (personally I try to do so generally).
Also, we can try to enforze or talk to authors about dates, but it's up to them to follow our recommendations. We can just admin the website.
This is my opinion.
Cheers


El 27/09/2019 a las 00:53, Joseph Lee escribió:
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




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

Travis Siegel
 

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


Virus-free. www.avast.com