Date
1 - 2 of 2
[nvda-addons] Some comments about possible add on problems
Hi,
The best method right now is to use NVDA with log level set to debug
warning, which should be done by add-on authors themselves. I used this
method to catch last-minute wxPython 4 deprecation warnings and wrote fixes
in NVDA Core.
To help add-on authors and users become aware of issues with future NVDA
releases, I propose a community-wide outreach campaign. This campaign should
inform add-on authors and third-party NVDA developers of what's coming in
future NVDA releases, especially when we do transition to Python 3. This
outreach campaign should also be used to inform users as to what to expect
with NVDA and add-ons in the future, as well as provide a way to let folks
report issues with add-ons that causes issues and warnings to be logged in
NVDA log. Lastly, the community should be given a chance to maintain
orphaned add-ons in preparation for future NVDA Core changes (orphaned
add-ons are those that are no longer maintained by their authors).
For reviewers: once start of Python 3 transition is declared, I propose that
we offer Python 3 compatibility as part of optional reviews package, and
then do compatibility checks as part of basic review once NVDA fully
transitions to Python 3.
Cheers,
Joseph
toggle quoted message
Show quoted text
The best method right now is to use NVDA with log level set to debug
warning, which should be done by add-on authors themselves. I used this
method to catch last-minute wxPython 4 deprecation warnings and wrote fixes
in NVDA Core.
To help add-on authors and users become aware of issues with future NVDA
releases, I propose a community-wide outreach campaign. This campaign should
inform add-on authors and third-party NVDA developers of what's coming in
future NVDA releases, especially when we do transition to Python 3. This
outreach campaign should also be used to inform users as to what to expect
with NVDA and add-ons in the future, as well as provide a way to let folks
report issues with add-ons that causes issues and warnings to be logged in
NVDA log. Lastly, the community should be given a chance to maintain
orphaned add-ons in preparation for future NVDA Core changes (orphaned
add-ons are those that are no longer maintained by their authors).
For reviewers: once start of Python 3 transition is declared, I propose that
we offer Python 3 compatibility as part of optional reviews package, and
then do compatibility checks as part of basic review once NVDA fully
transitions to Python 3.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Brian's Mail list account via Groups.Io
Sent: Sunday, August 19, 2018 4:06 AM
To: nvda-addons@nvda-addons.groups.io; nvda@groups.io
Subject: [nvda-addons] Some comments about possible add on problems
It is noted that although no errors of the audio alert kind occur on beta
and alpha snaps for error warnings about add ons that seem to be suggesting
that code is being deprecated and will not be supported, or indeed the
syntax is incorrect.
So as most people will not notice these as they are silent, who is
reporting the possible issues, and where are they reporting them to?
is there a central clearing site for add ons?
Also it did occur to me that folk who might rely on some add ons might need
an audible warning of a potential issue on a future version of nvda, so
maybe a well publicised add on for nvda which allows add on errors to be
flagged audible might be an idea now. it will be too late when the new code
mucks it up.
I'm assuming that these warnings are just that at the moment, ie, since the
add ons seem to be still doing what they do.
The two I've noted thus far are the sound schemes on and mp3 direct cut,
but since there has been no audio warning, I'd have no idea the warnings
existed and neither would anyone else as they are just warnings and hence
silent.
I'm sure the authors would be glad of such a facility to monitor the
problems coming up, as nobody is going to study the complexities of the
changing code in nvda all the time.
Lastly as in most of the error warnings I've seen suggestions are made for
what to do to fix them, some bright person might like to make an auto
correction tool. OK pi in the sky.. Pun intended.
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Brian's Mail list account via Groups.Io
Sent: Sunday, August 19, 2018 4:06 AM
To: nvda-addons@nvda-addons.groups.io; nvda@groups.io
Subject: [nvda-addons] Some comments about possible add on problems
It is noted that although no errors of the audio alert kind occur on beta
and alpha snaps for error warnings about add ons that seem to be suggesting
that code is being deprecated and will not be supported, or indeed the
syntax is incorrect.
So as most people will not notice these as they are silent, who is
reporting the possible issues, and where are they reporting them to?
is there a central clearing site for add ons?
Also it did occur to me that folk who might rely on some add ons might need
an audible warning of a potential issue on a future version of nvda, so
maybe a well publicised add on for nvda which allows add on errors to be
flagged audible might be an idea now. it will be too late when the new code
mucks it up.
I'm assuming that these warnings are just that at the moment, ie, since the
add ons seem to be still doing what they do.
The two I've noted thus far are the sound schemes on and mp3 direct cut,
but since there has been no audio warning, I'd have no idea the warnings
existed and neither would anyone else as they are just warnings and hence
silent.
I'm sure the authors would be glad of such a facility to monitor the
problems coming up, as nobody is going to study the complexities of the
changing code in nvda all the time.
Lastly as in most of the error warnings I've seen suggestions are made for
what to do to fix them, some bright person might like to make an auto
correction tool. OK pi in the sky.. Pun intended.
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Brian's Mail list account
Fine Joseph, but how would anyone know to actually look. My understanding of logging levels is that the actual messages flagged in audio is not altered. I always run in debug, so all levels of logging are shown in the log, but really unless the average user who uses snaps with add ons religiously looks at the log every time they run nvda, they would be totally unaware of any warnings, as they make no sound at all.
That was the main thrust of my comments.
It seems to me that during the next year or so the transitions that nvda will go through will render a lot of add ons non functional or they will make nvda malfunction. Without some way to test the add ons for errors in alpha and better snaps, they will not be seen and hence suddenly, a user might have to uninstall it. Far better in my view to suffer a unique warning sound for debug warnings and then see what has changed.
I obviously do not know if one can actually identify an error warning generated by an add on from an nvda core warning, but if one can it would be very useful I think for the feet on the ground, aspect of testing compatibility.
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
toggle quoted message
Show quoted text
That was the main thrust of my comments.
It seems to me that during the next year or so the transitions that nvda will go through will render a lot of add ons non functional or they will make nvda malfunction. Without some way to test the add ons for errors in alpha and better snaps, they will not be seen and hence suddenly, a user might have to uninstall it. Far better in my view to suffer a unique warning sound for debug warnings and then see what has changed.
I obviously do not know if one can actually identify an error warning generated by an add on from an nvda core warning, but if one can it would be very useful I think for the feet on the ground, aspect of testing compatibility.
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Joseph Lee" <joseph.lee22590@...>
To: <nvda-addons@nvda-addons.groups.io>; <nvda@groups.io>
Sent: Sunday, August 19, 2018 3:44 PM
Subject: Re: [nvda] [nvda-addons] Some comments about possible add on problems
From: "Joseph Lee" <joseph.lee22590@...>
To: <nvda-addons@nvda-addons.groups.io>; <nvda@groups.io>
Sent: Sunday, August 19, 2018 3:44 PM
Subject: Re: [nvda] [nvda-addons] Some comments about possible add on problems
Hi,
The best method right now is to use NVDA with log level set to debug
warning, which should be done by add-on authors themselves. I used this
method to catch last-minute wxPython 4 deprecation warnings and wrote fixes
in NVDA Core.
To help add-on authors and users become aware of issues with future NVDA
releases, I propose a community-wide outreach campaign. This campaign should
inform add-on authors and third-party NVDA developers of what's coming in
future NVDA releases, especially when we do transition to Python 3. This
outreach campaign should also be used to inform users as to what to expect
with NVDA and add-ons in the future, as well as provide a way to let folks
report issues with add-ons that causes issues and warnings to be logged in
NVDA log. Lastly, the community should be given a chance to maintain
orphaned add-ons in preparation for future NVDA Core changes (orphaned
add-ons are those that are no longer maintained by their authors).
For reviewers: once start of Python 3 transition is declared, I propose that
we offer Python 3 compatibility as part of optional reviews package, and
then do compatibility checks as part of basic review once NVDA fully
transitions to Python 3.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Brian's Mail list account via Groups.Io
Sent: Sunday, August 19, 2018 4:06 AM
To: nvda-addons@nvda-addons.groups.io; nvda@groups.io
Subject: [nvda-addons] Some comments about possible add on problems
It is noted that although no errors of the audio alert kind occur on beta
and alpha snaps for error warnings about add ons that seem to be suggesting
that code is being deprecated and will not be supported, or indeed the
syntax is incorrect.
So as most people will not notice these as they are silent, who is
reporting the possible issues, and where are they reporting them to?
is there a central clearing site for add ons?
Also it did occur to me that folk who might rely on some add ons might need
an audible warning of a potential issue on a future version of nvda, so
maybe a well publicised add on for nvda which allows add on errors to be
flagged audible might be an idea now. it will be too late when the new code
mucks it up.
I'm assuming that these warnings are just that at the moment, ie, since the
add ons seem to be still doing what they do.
The two I've noted thus far are the sound schemes on and mp3 direct cut,
but since there has been no audio warning, I'd have no idea the warnings
existed and neither would anyone else as they are just warnings and hence
silent.
I'm sure the authors would be glad of such a facility to monitor the
problems coming up, as nobody is going to study the complexities of the
changing code in nvda all the time.
Lastly as in most of the error warnings I've seen suggestions are made for
what to do to fix them, some bright person might like to make an auto
correction tool. OK pi in the sky.. Pun intended.
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.