Important note about add-on manifest: surround summary text in quotes


 

Hi all,

 

In the course of debugging a bug with Add-on Updater reported by a user, it has come to my attention that there is at least one add-on out there that does not follow add-on manifest value conventions correctly. The add-on in question (Nuance Vocalizer Expressive – English Compact Voices) – does not use proper string quoting syntax for ini files, with this causing add-on manifest summary retrievers (including parts of Add-on Updater) to fail to parse this correctly (Python converts this into a list, not a string), with a possibility that the add-on was generated manually.

 

Thus, whenever you need to provide a string that contains list of items, please put quotes around the whole string, especially if you are creating add-on manifests by hand.

 

As a result, the next version of Add-on Updater will not seek out updates for the affected add-on until this is corrected from add-on authors in the future.

Cheers,

Joseph


Ethin Probst
 

You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be
a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring
the add-on just because you are unwilling to add in the appropriate
code to check the type of what's being parsed is quite rude. For the
list, for example, loop through and build the string, then output it
or do what you want with the new string. Ignoring the problem seems,
to me, like you are unwilling to make the problem go away no matter
what type you get from Python. If you get a number, str() it. Just a
thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a user, it
has come to my attention that there is at least one add-on out there that
does not follow add-on manifest value conventions correctly. The add-on in
question (Nuance Vocalizer Expressive - English Compact Voices) - does not
use proper string quoting syntax for ini files, with this causing add-on
manifest summary retrievers (including parts of Add-on Updater) to fail to
parse this correctly (Python converts this into a list, not a string), with
a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of items,
please put quotes around the whole string, especially if you are creating
add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out updates
for the affected add-on until this is corrected from add-on authors in the
future.

Cheers,

Joseph




--
Signed,
Ethin D. Probst


 

Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst


Doug Lee
 

Your point that adapting the add-on is likely trivial is a valid point; however, making an add-on insist on prescribed, documented, and standard file syntax is hardly "rude." :-)

Any code that depends on the syntax of hand-written files is best tested against a wide variety of hand-entered content. This is one thing I believe "proof of concept" to mean. Edge cases are surfacing as expected, and being
handled as they do.

On Sat, Aug 04, 2018 at 02:08:05PM -0500, Ethin Probst wrote:
You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be
a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring
the add-on just because you are unwilling to add in the appropriate
code to check the type of what's being parsed is quite rude. For the
list, for example, loop through and build the string, then output it
or do what you want with the new string. Ignoring the problem seems,
to me, like you are unwilling to make the problem go away no matter
what type you get from Python. If you get a number, str() it. Just a
thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a user, it
has come to my attention that there is at least one add-on out there that
does not follow add-on manifest value conventions correctly. The add-on in
question (Nuance Vocalizer Expressive - English Compact Voices) - does not
use proper string quoting syntax for ini files, with this causing add-on
manifest summary retrievers (including parts of Add-on Updater) to fail to
parse this correctly (Python converts this into a list, not a string), with
a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of items,
please put quotes around the whole string, especially if you are creating
add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out updates
for the affected add-on until this is corrected from add-on authors in the
future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst



--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com http://www.LevelAccess.com
A mailing list is like a car where brakes and accelerator are the same pedal:
The effect of putting your foot down is a bit hard to predict! (04/04/2012)


Noelia Ruiz
 

Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.

Cheers

El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes
You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.
On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph




--
Signed,
Ethin D. Probst


Ethin Probst
 

No, making an add-on use documented methods for manifest entries is
not rude, but ignoring it completely until it is fixed is, especially
since it needs to be hardcoded into the add-on, making an update to
the add-on that is ignoring the target add-on required when the
argeted add-on is fixed. Just type-cast the list into a string
manually by rebuilding it. It would take you about a minute to write,
would be no hardship to anyone, and would incur no overhead. Perhaps
later on we can modify the review process to fail add-ons if they
don't follow the manifest syntax, but for now this is what I think
this add-o needs to do. Its simpler and will probably make the add-on
easier to manage in the long run.

On 8/4/18, Doug Lee <nvda@dlee.org> wrote:
Your point that adapting the add-on is likely trivial is a valid point;
however, making an add-on insist on prescribed, documented, and standard
file syntax is hardly "rude." :-)

Any code that depends on the syntax of hand-written files is best tested
against a wide variety of hand-entered content. This is one thing I believe
"proof of concept" to mean. Edge cases are surfacing as expected, and being
handled as they do.

On Sat, Aug 04, 2018 at 02:08:05PM -0500, Ethin Probst wrote:
You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be
a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring
the add-on just because you are unwilling to add in the appropriate
code to check the type of what's being parsed is quite rude. For the
list, for example, loop through and build the string, then output it
or do what you want with the new string. Ignoring the problem seems,
to me, like you are unwilling to make the problem go away no matter
what type you get from Python. If you get a number, str() it. Just a
thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a user,
it
has come to my attention that there is at least one add-on out there that
does not follow add-on manifest value conventions correctly. The add-on
in
question (Nuance Vocalizer Expressive - English Compact Voices) - does
not
use proper string quoting syntax for ini files, with this causing add-on
manifest summary retrievers (including parts of Add-on Updater) to fail
to
parse this correctly (Python converts this into a list, not a string),
with
a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of items,
please put quotes around the whole string, especially if you are creating
add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out updates
for the affected add-on until this is corrected from add-on authors in
the
future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst



--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
A mailing list is like a car where brakes and accelerator are the same
pedal:
The effect of putting your foot down is a bit hard to predict!
(04/04/2012)



--
Signed,
Ethin D. Probst


 

Hi,
In this context, I think stringifying list.repr may not be what we want:
1. Limitations are present. When Add-on Updater receives a list of checked strings for add-ons excluded from updates (onSave method), it'll look for add-on ID's (names) with corresponding summary via manifest lookup. In case of Nuance Vocalizer Expressive English Compact, or any add-on where badly formatted summary text presents issues, the function will look up known constant(s) and change it back to a list, which then allows manifest lookup to work. But we can't forget the fact that...
2. English is not spoken by all 7 billion people around the world. Although the summary is written in English, it may have been translated differently depending on language in use. In the short-term, bundling hard-coded constants for add-on summaries might work, but it poses long-term problems. This is especially the case because...
3. Add-on Updater is a proof of concept for a feature under consideration for NVDA itself. In short, the lifetime of this add-on is finite; as I said when I released Add-on Updater last week, this add-on will be discontinued the day a stable version of NVDA that comes with native support for add-on update checking hits the air.

What I'm really doing is letting people field test add-on update feature so changes can be made to the pull request, and so far, it is doing more than just that. In fact, this add-on confirmed a concern I had for a while: the add-ons community has become fragmented:
* Add-ons listed on community add-ons website represents a small sample of NVDA add-ons out there.
* Some of the edge cases are coming from add-ons that were written prior to widespread use of add-on template (old ones prior to say, 2014) when folks packaged add-ons by hand.
* Some of the essential add-ons users may need are not even listed on community add-ons website. The most prominent example is Remote Support add-on.

Hope this helps.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 1:02 PM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

No, making an add-on use documented methods for manifest entries is not rude, but ignoring it completely until it is fixed is, especially since it needs to be hardcoded into the add-on, making an update to the add-on that is ignoring the target add-on required when the argeted add-on is fixed. Just type-cast the list into a string manually by rebuilding it. It would take you about a minute to write, would be no hardship to anyone, and would incur no overhead. Perhaps later on we can modify the review process to fail add-ons if they don't follow the manifest syntax, but for now this is what I think this add-o needs to do. Its simpler and will probably make the add-on easier to manage in the long run.

On 8/4/18, Doug Lee <nvda@dlee.org> wrote:
Your point that adapting the add-on is likely trivial is a valid
point; however, making an add-on insist on prescribed, documented, and
standard file syntax is hardly "rude." :-)

Any code that depends on the syntax of hand-written files is best
tested against a wide variety of hand-entered content. This is one
thing I believe "proof of concept" to mean. Edge cases are surfacing
as expected, and being handled as they do.

On Sat, Aug 04, 2018 at 02:08:05PM -0500, Ethin Probst wrote:
You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be
a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring
the add-on just because you are unwilling to add in the appropriate
code to check the type of what's being parsed is quite rude. For the
list, for example, loop through and build the string, then output it
or do what you want with the new string. Ignoring the problem seems,
to me, like you are unwilling to make the problem go away no matter
what type you get from Python. If you get a number, str() it. Just a
thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility
that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst



--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
A mailing list is like a car where brakes and accelerator are the same
pedal:
The effect of putting your foot down is a bit hard to predict!
(04/04/2012)




--
Signed,
Ethin D. Probst


 

Hi,
Add-on version string convention: this is due to limitations of the PHP file hosted on add-ons server and to deal with different add-on installers coming from different locations (Amazon Cloud, a specific website, etc.). This is one of the reasons why I'll continue to advocate that we create a database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that talks about this hasn't been updated since 2014, so we need to do that ASAP. I'll do something about it (perhaps as an appendix in add-on development guide where info such as value and types are shown as a table).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.

Cheers


El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst






Noelia Ruiz
 

I understand the reasons about add-on names, I knew your add-on is based on this while server side work is done.
About the developer guide, I'm talking about the guide of NV Access, updated more recently, since the new script decorator is included.
Anyway, this doesn't change my previous message.

Cheers

El 04/08/2018 a las 22:32, Joseph Lee escribió:
Hi,
Add-on version string convention: this is due to limitations of the PHP file hosted on add-ons server and to deal with different add-on installers coming from different locations (Amazon Cloud, a specific website, etc.). This is one of the reasons why I'll continue to advocate that we create a database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that talks about this hasn't been updated since 2014, so we need to do that ASAP. I'll do something about it (perhaps as an appendix in add-on development guide where info such as value and types are shown as a table).
Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes
Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.
Cheers
El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst






Noelia Ruiz
 

Hi, just to point out that Remote Support could be considered also as an add-on with a limited lifetime, since there is an open issue in NVDA's repo for this. Also placeMarkers, as two examples, maybe more add-ons. Others, like rapid settings (with differences), or Braille Note, have been included mostly in NVDA's core.
This doesn't mean they need to be developed as more "incomplete" add-ons.
Notice I'm not depreciating your work. Otherwise I would ignore your messages completely.

Cheers

El 04/08/2018 a las 22:28, Joseph Lee escribió:
Hi,
In this context, I think stringifying list.repr may not be what we want:
1. Limitations are present. When Add-on Updater receives a list of checked strings for add-ons excluded from updates (onSave method), it'll look for add-on ID's (names) with corresponding summary via manifest lookup. In case of Nuance Vocalizer Expressive English Compact, or any add-on where badly formatted summary text presents issues, the function will look up known constant(s) and change it back to a list, which then allows manifest lookup to work. But we can't forget the fact that...
2. English is not spoken by all 7 billion people around the world. Although the summary is written in English, it may have been translated differently depending on language in use. In the short-term, bundling hard-coded constants for add-on summaries might work, but it poses long-term problems. This is especially the case because...
3. Add-on Updater is a proof of concept for a feature under consideration for NVDA itself. In short, the lifetime of this add-on is finite; as I said when I released Add-on Updater last week, this add-on will be discontinued the day a stable version of NVDA that comes with native support for add-on update checking hits the air.
What I'm really doing is letting people field test add-on update feature so changes can be made to the pull request, and so far, it is doing more than just that. In fact, this add-on confirmed a concern I had for a while: the add-ons community has become fragmented:
* Add-ons listed on community add-ons website represents a small sample of NVDA add-ons out there.
* Some of the edge cases are coming from add-ons that were written prior to widespread use of add-on template (old ones prior to say, 2014) when folks packaged add-ons by hand.
* Some of the essential add-ons users may need are not even listed on community add-ons website. The most prominent example is Remote Support add-on.
Hope this helps.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 1:02 PM
To: nvda-addons@nvda-addons.groups.io; Doug Lee <nvda@dlee.org>
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes
No, making an add-on use documented methods for manifest entries is not rude, but ignoring it completely until it is fixed is, especially since it needs to be hardcoded into the add-on, making an update to the add-on that is ignoring the target add-on required when the argeted add-on is fixed. Just type-cast the list into a string manually by rebuilding it. It would take you about a minute to write, would be no hardship to anyone, and would incur no overhead. Perhaps later on we can modify the review process to fail add-ons if they don't follow the manifest syntax, but for now this is what I think this add-o needs to do. Its simpler and will probably make the add-on easier to manage in the long run.
On 8/4/18, Doug Lee <nvda@dlee.org> wrote:
Your point that adapting the add-on is likely trivial is a valid
point; however, making an add-on insist on prescribed, documented, and
standard file syntax is hardly "rude." :-)

Any code that depends on the syntax of hand-written files is best
tested against a wide variety of hand-entered content. This is one
thing I believe "proof of concept" to mean. Edge cases are surfacing
as expected, and being handled as they do.

On Sat, Aug 04, 2018 at 02:08:05PM -0500, Ethin Probst wrote:
You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be
a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring
the add-on just because you are unwilling to add in the appropriate
code to check the type of what's being parsed is quite rude. For the
list, for example, loop through and build the string, then output it
or do what you want with the new string. Ignoring the problem seems,
to me, like you are unwilling to make the problem go away no matter
what type you get from Python. If you get a number, str() it. Just a
thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility
that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst



--
Doug Lee dgl@dlee.org http://www.dlee.org
Level Access doug.lee@LevelAccess.com
http://www.LevelAccess.com
A mailing list is like a car where brakes and accelerator are the same
pedal:
The effect of putting your foot down is a bit hard to predict!
(04/04/2012)



--
Signed,
Ethin D. Probst


James Scholes
 

I'm happy to see the wealth of discussion surrounding this topic.

From a technical point of view, as a proof of concept there is no call for the add-on to be perfect. Far from it, in fact. Given the extent to which the current implementation relies on HTML scraping and hard-coded add-on information, I don't believe the quality of it to exceed alpha status. However, there are several issues here that need to be considered and addressed:

1. The add-on was promoted across the NVDA community, outside of development-specific mailing lists. It was also posted on social media. Here's the text of the widely-reposted tweet:

Introducing Add-on Updater - check, download, apply #NVDASR add-on
updates: https://addons.nvda-project.org/addons/addonUpdater.en.html @NVDAAddons @NVAccess

This tweet makes no mention of the fact that your aim with this work is to solicit comments from technical testers or feedback on a pull request. Upon opening the add-on's information page, users are informed that the current version offered for download is "stable". It is not stable. Whatever else the page may say is largely irrelevant because nowhere near the majority of users will read and understand it.

2. This add-on was anounced, reviewed and posted without any consultation with members of this group. Nobody was able to raise any concerns they might have had, because they weren't given the opportunity. Personally, I don't think it should have been listed on the add-ons website at all initially, certainly not listed as "stable". I would have been happy to raise these issues earlier and if I had been overruled by an opposing majority then that is something I would've accepted gracefully.

My primary concern is that the community of NVDA users is served in the best way that we can serve them and clearly, this is a feature people want to see. Your efforts are appreciated not only by myself, but by many users around the world and, I'm sure, by the core NVDA team. But you're absolutely right that the community is fragmented, and I think everybody has a part to play in that. Certainly, reviewing our own add-ons, posting them to the add-ons website without consultation, and promoting cutting edge alpha add-ons without suitable warnings understandable by every single end user doesn't help.

Regards,

James Scholes
https://twitter.com/JamesScholes


Ethin Probst
 

James, 100-percent agree. It seems like useful input -- like mine (on
the basis of not ignoring add-ons via hardcoding) is being ignored.
The advice is good, and would take less than a minute to implement,
yet the author doesn't wish to do so (for a reason I can only fathom
to be laziness). I know, perhaps its insulting, perhaps its rude, but
its all I can come up with. This add-on needs a lot more review, IMO,
than it has had.

On 8/4/18, James Scholes <james@jls-radio.com> wrote:
I'm happy to see the wealth of discussion surrounding this topic.

From a technical point of view, as a proof of concept there is no call
for the add-on to be perfect. Far from it, in fact. Given the extent
to which the current implementation relies on HTML scraping and
hard-coded add-on information, I don't believe the quality of it to
exceed alpha status. However, there are several issues here that need
to be considered and addressed:

1. The add-on was promoted across the NVDA community, outside of
development-specific mailing lists. It was also posted on social media.
Here's the text of the widely-reposted tweet:

> Introducing Add-on Updater - check, download, apply #NVDASR add-on
updates: https://addons.nvda-project.org/addons/addonUpdater.en.html
@NVDAAddons @NVAccess

This tweet makes no mention of the fact that your aim with this work is
to solicit comments from technical testers or feedback on a pull
request. Upon opening the add-on's information page, users are informed
that the current version offered for download is "stable". It is not
stable. Whatever else the page may say is largely irrelevant because
nowhere near the majority of users will read and understand it.

2. This add-on was anounced, reviewed and posted without any
consultation with members of this group. Nobody was able to raise any
concerns they might have had, because they weren't given the
opportunity. Personally, I don't think it should have been listed on
the add-ons website at all initially, certainly not listed as "stable".
I would have been happy to raise these issues earlier and if I had been
overruled by an opposing majority then that is something I would've
accepted gracefully.

My primary concern is that the community of NVDA users is served in the
best way that we can serve them and clearly, this is a feature people
want to see. Your efforts are appreciated not only by myself, but by
many users around the world and, I'm sure, by the core NVDA team. But
you're absolutely right that the community is fragmented, and I think
everybody has a part to play in that. Certainly, reviewing our own
add-ons, posting them to the add-ons website without consultation, and
promoting cutting edge alpha add-ons without suitable warnings
understandable by every single end user doesn't help.

Regards,

James Scholes
https://twitter.com/JamesScholes



--
Signed,
Ethin D. Probst


James Scholes
 

Ethin Probst wrote:
It seems like useful input -- like mine (on the basis of not ignoring
add-ons via hardcoding) is being ignored.

The core issue is not with hardcoding of information with in an add-on. For proof of concept code, it's a perfectly valid approach to take. Obviously once the add-on and server-side infrastructure reach production or even beta quality level, it should be relied upon less and less and, ultimately, not at all.

There is a problem when something is hardcoded to conveniently fix an issue in the short term, but that solution ends up surviving longer than intended. In those cases the original cause of the original problem remains unaddressed. I do expect add-on authors to proactively work to avoid this from happening, and to take all feedback on board. But I don't expect a proof of concept to be rock-solid and perfect in any way.

The advice is good, and would take less than a minute to implement,
yet the author doesn't wish to do so (for a reason I can only fathom to be laziness). I know, perhaps its insulting, perhaps its rude

It's both potentially insulting and rude. Constructive feedback about add-ons and the state of the add-ons community are fine, and it's only natural that discussions will sometimes get a little heated and people will speak frankly. But personal attacks or assumptions about a person's state of mind and motivations aren't welcome. If you are aware that something may be rude or otherwise inappropriate, take a step back and consider either rephrasing it or leaving it out. We're here to make the community a great place for everyone, not belittle each other.

Thanks.

James Scholes


 

Hi all,
After probing around a bit, I found a temporary solution that won't involve excluding add-ons: converting to and from Unicode strings. There is a caveat, however: the add-ons in question will be shown with Python code syntax. Note that this is a short-term solution - my stance on long-term solution hasn't changed.

Regarding other matters raised:
* Review: yes, this add-on went through a basic review process (Noelia reviewed this).
* Visibility: based on feedback from this community, I'll limit Add-on Updater to the development section.
* Possible personal attacks and impression of my rudeness: yes: I did feel bad when someone mentioned that my perceived attitude towards "not taking suggestions" was rude. At the same time, I understood that this may have come from someone who may have not known about the history of NVDA add-ons community, as the root problem is related to that - old assumptions versus what we have now. My ethos for pointing out history of this community and root cause is because I was an early contributor to the add-ons community - back in 2013, and I helped write text of the community add-ons website when it was first designed. And no, I won't ask for apologies forcefully, because I think saying sorry is tied to willpower.
* Perceived rudeness and stress: I think part of the reason for folks getting the 'rudeness" impression may have had to do with my own stress and not controlling it well. Because the bug raised was a showstopper and I couldn't reproduce this on my system in the beginning, it took me a while to figure out the root cause thanks to a log fragment sent by a user and asking this person to try something on Python Console. After locating the problem, I then realized that it could affect a whole class of add-ons - old ones where manifest data had issues, hence the notice.
* Bad public relations regarding proof of concept tag: as James pointed out, I should have said from the beginning that this is a proof of concept work. This was communicated here and on add-ons website, but wasn't done on social media, and I apologize for that.

Cheers,
Joseph

-----Original Message-----
From: joseph.lee22590@gmail.com <joseph.lee22590@gmail.com>
Sent: Saturday, August 4, 2018 1:32 PM
To: 'nvda-addons@nvda-addons.groups.io' <nvda-addons@nvda-addons.groups.io>
Subject: RE: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

Hi,
Add-on version string convention: this is due to limitations of the PHP file hosted on add-ons server and to deal with different add-on installers coming from different locations (Amazon Cloud, a specific website, etc.). This is one of the reasons why I'll continue to advocate that we create a database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that talks about this hasn't been updated since 2014, so we need to do that ASAP. I'll do something about it (perhaps as an appendix in add-on development guide where info such as value and types are shown as a table).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.

Cheers


El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst






Noelia Ruiz
 

Hi, here is a thread with messages which shows that I reviewed the add-on.
It produced me a good impression. Notice that I mentioned that user experience maybe improved and I recommended to post a dev version, and my intention was this add-on could be improved as much as possible..
Later we discussed about the possibility that authors decide what is declared stable and I requested you, as a person with great abilities to write documentation, document it in the review process.
My intention was you could improve this add-on, as shown below.
Please don't feel bad. This is not my intention. BTW, I started writing add-ons in 2012 before the website was created and also I listen to Mesar when he created the first process review: we talk on an IRC channel.
Limitations of this process are that add-ons pass a basic review before being included on the website, but other versions are not explicitly reviewed, but they can receive feedback and imo it's the best we can do.
A question: Should we post add-ons in development section when they haven't been reviewed? Who did review screenCurtain?
Cheers
Here's the thread.
Thanks for all your work, sincerely.

Hi, here are results of basic review:
License and copyright: Pass.
Security: Pass.
User experience: May be improved.
1. After updating add-ons, if possible, require to restart NVDA, or explain this in the readme file.
2. Provide a mechanism to update add-ons deppending on the selected channel, for instance, if I'm using a dev version of VLC, maybe I don't want to update to a stable version.
Anyway, this is an excellent work for me and I would like to see a dev version for testing inmediately posted on the website.
Also, if this is compatible with WX Python 4, once it's used this in the add-on, and I think this is not longer used in NVDA:
self.Center(wx.BOTH | wx.CENTER_ON_SCREEN)
Now it's used:
self.CentreOnScreen()
Please fix me if I'm wrong.
I think this should be considered as a robust add-on and mantained as such, since we don't know when this will be included in NVDA's core, and for me it's better than including this in individual add-ons. I'm happy for waiting and for not including this in add-ons maintained by me.
More reviews could be made in daily life.
Thanks


El 05/08/2018 a las 3:30, Joseph Lee escribió:
Hi all,
After probing around a bit, I found a temporary solution that won't involve excluding add-ons: converting to and from Unicode strings. There is a caveat, however: the add-ons in question will be shown with Python code syntax. Note that this is a short-term solution - my stance on long-term solution hasn't changed.
Regarding other matters raised:
* Review: yes, this add-on went through a basic review process (Noelia reviewed this).
* Visibility: based on feedback from this community, I'll limit Add-on Updater to the development section.
* Possible personal attacks and impression of my rudeness: yes: I did feel bad when someone mentioned that my perceived attitude towards "not taking suggestions" was rude. At the same time, I understood that this may have come from someone who may have not known about the history of NVDA add-ons community, as the root problem is related to that - old assumptions versus what we have now. My ethos for pointing out history of this community and root cause is because I was an early contributor to the add-ons community - back in 2013, and I helped write text of the community add-ons website when it was first designed. And no, I won't ask for apologies forcefully, because I think saying sorry is tied to willpower.
* Perceived rudeness and stress: I think part of the reason for folks getting the 'rudeness" impression may have had to do with my own stress and not controlling it well. Because the bug raised was a showstopper and I couldn't reproduce this on my system in the beginning, it took me a while to figure out the root cause thanks to a log fragment sent by a user and asking this person to try something on Python Console. After locating the problem, I then realized that it could affect a whole class of add-ons - old ones where manifest data had issues, hence the notice.
* Bad public relations regarding proof of concept tag: as James pointed out, I should have said from the beginning that this is a proof of concept work. This was communicated here and on add-ons website, but wasn't done on social media, and I apologize for that.
Cheers,
Joseph
-----Original Message-----
From: joseph.lee22590@gmail.com <joseph.lee22590@gmail.com>
Sent: Saturday, August 4, 2018 1:32 PM
To: 'nvda-addons@nvda-addons.groups.io' <nvda-addons@nvda-addons.groups.io>
Subject: RE: [nvda-addons] Important note about add-on manifest: surround summary text in quotes
Hi,
Add-on version string convention: this is due to limitations of the PHP file hosted on add-ons server and to deal with different add-on installers coming from different locations (Amazon Cloud, a specific website, etc.). This is one of the reasons why I'll continue to advocate that we create a database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that talks about this hasn't been updated since 2014, so we need to do that ASAP. I'll do something about it (perhaps as an appendix in add-on development guide where info such as value and types are shown as a table).
Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes
Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.
Cheers
El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst






 

Hi,
James reviewed Screen Curtain and provided suggestions.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 8:04 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes

Hi, here is a thread with messages which shows that I reviewed the add-on.
It produced me a good impression. Notice that I mentioned that user experience maybe improved and I recommended to post a dev version, and my intention was this add-on could be improved as much as possible..
Later we discussed about the possibility that authors decide what is declared stable and I requested you, as a person with great abilities to write documentation, document it in the review process.
My intention was you could improve this add-on, as shown below.
Please don't feel bad. This is not my intention. BTW, I started writing add-ons in 2012 before the website was created and also I listen to Mesar when he created the first process review: we talk on an IRC channel.
Limitations of this process are that add-ons pass a basic review before being included on the website, but other versions are not explicitly reviewed, but they can receive feedback and imo it's the best we can do.
A question: Should we post add-ons in development section when they haven't been reviewed? Who did review screenCurtain?
Cheers
Here's the thread.
Thanks for all your work, sincerely.

Hi, here are results of basic review:

License and copyright: Pass.
Security: Pass.
User experience: May be improved.
1. After updating add-ons, if possible, require to restart NVDA, or explain this in the readme file.
2. Provide a mechanism to update add-ons deppending on the selected channel, for instance, if I'm using a dev version of VLC, maybe I don't want to update to a stable version.

Anyway, this is an excellent work for me and I would like to see a dev version for testing inmediately posted on the website.
Also, if this is compatible with WX Python 4, once it's used this in the add-on, and I think this is not longer used in NVDA:

self.Center(wx.BOTH | wx.CENTER_ON_SCREEN)

Now it's used:
self.CentreOnScreen()

Please fix me if I'm wrong.

I think this should be considered as a robust add-on and mantained as such, since we don't know when this will be included in NVDA's core, and for me it's better than including this in individual add-ons. I'm happy for waiting and for not including this in add-ons maintained by me.
More reviews could be made in daily life.

Thanks


El 05/08/2018 a las 3:30, Joseph Lee escribió:
Hi all,
After probing around a bit, I found a temporary solution that won't involve excluding add-ons: converting to and from Unicode strings. There is a caveat, however: the add-ons in question will be shown with Python code syntax. Note that this is a short-term solution - my stance on long-term solution hasn't changed.

Regarding other matters raised:
* Review: yes, this add-on went through a basic review process (Noelia reviewed this).
* Visibility: based on feedback from this community, I'll limit Add-on Updater to the development section.
* Possible personal attacks and impression of my rudeness: yes: I did feel bad when someone mentioned that my perceived attitude towards "not taking suggestions" was rude. At the same time, I understood that this may have come from someone who may have not known about the history of NVDA add-ons community, as the root problem is related to that - old assumptions versus what we have now. My ethos for pointing out history of this community and root cause is because I was an early contributor to the add-ons community - back in 2013, and I helped write text of the community add-ons website when it was first designed. And no, I won't ask for apologies forcefully, because I think saying sorry is tied to willpower.
* Perceived rudeness and stress: I think part of the reason for folks getting the 'rudeness" impression may have had to do with my own stress and not controlling it well. Because the bug raised was a showstopper and I couldn't reproduce this on my system in the beginning, it took me a while to figure out the root cause thanks to a log fragment sent by a user and asking this person to try something on Python Console. After locating the problem, I then realized that it could affect a whole class of add-ons - old ones where manifest data had issues, hence the notice.
* Bad public relations regarding proof of concept tag: as James pointed out, I should have said from the beginning that this is a proof of concept work. This was communicated here and on add-ons website, but wasn't done on social media, and I apologize for that.

Cheers,
Joseph

-----Original Message-----
From: joseph.lee22590@gmail.com <joseph.lee22590@gmail.com>
Sent: Saturday, August 4, 2018 1:32 PM
To: 'nvda-addons@nvda-addons.groups.io'
<nvda-addons@nvda-addons.groups.io>
Subject: RE: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Hi,
Add-on version string convention: this is due to limitations of the PHP file hosted on add-ons server and to deal with different add-on installers coming from different locations (Amazon Cloud, a specific website, etc.). This is one of the reasons why I'll continue to advocate that we create a database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that talks about this hasn't been updated since 2014, so we need to do that ASAP. I'll do something about it (perhaps as an appendix in add-on development guide where info such as value and types are shown as a table).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.

Cheers


El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst










Noelia Ruiz
 

Thanks, I lose that email. Sometimes I notice some messages are losen
or something.

Cheers

2018-08-05 5:20 GMT+02:00, Joseph Lee <joseph.lee22590@gmail.com>:

Hi,
James reviewed Screen Curtain and provided suggestions.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 8:04 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround
summary text in quotes

Hi, here is a thread with messages which shows that I reviewed the add-on.
It produced me a good impression. Notice that I mentioned that user
experience maybe improved and I recommended to post a dev version, and my
intention was this add-on could be improved as much as possible..
Later we discussed about the possibility that authors decide what is
declared stable and I requested you, as a person with great abilities to
write documentation, document it in the review process.
My intention was you could improve this add-on, as shown below.
Please don't feel bad. This is not my intention. BTW, I started writing
add-ons in 2012 before the website was created and also I listen to Mesar
when he created the first process review: we talk on an IRC channel.
Limitations of this process are that add-ons pass a basic review before
being included on the website, but other versions are not explicitly
reviewed, but they can receive feedback and imo it's the best we can do.
A question: Should we post add-ons in development section when they haven't
been reviewed? Who did review screenCurtain?
Cheers
Here's the thread.
Thanks for all your work, sincerely.

Hi, here are results of basic review:

License and copyright: Pass.
Security: Pass.
User experience: May be improved.
1. After updating add-ons, if possible, require to restart NVDA, or
explain this in the readme file.
2. Provide a mechanism to update add-ons deppending on the selected
channel, for instance, if I'm using a dev version of VLC, maybe I don't
want to update to a stable version.

Anyway, this is an excellent work for me and I would like to see a dev
version for testing inmediately posted on the website.
Also, if this is compatible with WX Python 4, once it's used this in the
add-on, and I think this is not longer used in NVDA:

self.Center(wx.BOTH | wx.CENTER_ON_SCREEN)

Now it's used:
self.CentreOnScreen()

Please fix me if I'm wrong.

I think this should be considered as a robust add-on and mantained as
such, since we don't know when this will be included in NVDA's core, and
for me it's better than including this in individual add-ons. I'm happy
for waiting and for not including this in add-ons maintained by me.
More reviews could be made in daily life.

Thanks


El 05/08/2018 a las 3:30, Joseph Lee escribió:
Hi all,
After probing around a bit, I found a temporary solution that won't
involve excluding add-ons: converting to and from Unicode strings. There
is a caveat, however: the add-ons in question will be shown with Python
code syntax. Note that this is a short-term solution - my stance on
long-term solution hasn't changed.

Regarding other matters raised:
* Review: yes, this add-on went through a basic review process (Noelia
reviewed this).
* Visibility: based on feedback from this community, I'll limit Add-on
Updater to the development section.
* Possible personal attacks and impression of my rudeness: yes: I did feel
bad when someone mentioned that my perceived attitude towards "not taking
suggestions" was rude. At the same time, I understood that this may have
come from someone who may have not known about the history of NVDA add-ons
community, as the root problem is related to that - old assumptions versus
what we have now. My ethos for pointing out history of this community and
root cause is because I was an early contributor to the add-ons community
- back in 2013, and I helped write text of the community add-ons website
when it was first designed. And no, I won't ask for apologies forcefully,
because I think saying sorry is tied to willpower.
* Perceived rudeness and stress: I think part of the reason for folks
getting the 'rudeness" impression may have had to do with my own stress
and not controlling it well. Because the bug raised was a showstopper and
I couldn't reproduce this on my system in the beginning, it took me a
while to figure out the root cause thanks to a log fragment sent by a user
and asking this person to try something on Python Console. After locating
the problem, I then realized that it could affect a whole class of add-ons
- old ones where manifest data had issues, hence the notice.
* Bad public relations regarding proof of concept tag: as James pointed
out, I should have said from the beginning that this is a proof of concept
work. This was communicated here and on add-ons website, but wasn't done
on social media, and I apologize for that.

Cheers,
Joseph

-----Original Message-----
From: joseph.lee22590@gmail.com <joseph.lee22590@gmail.com>
Sent: Saturday, August 4, 2018 1:32 PM
To: 'nvda-addons@nvda-addons.groups.io'
<nvda-addons@nvda-addons.groups.io>
Subject: RE: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Hi,
Add-on version string convention: this is due to limitations of the PHP
file hosted on add-ons server and to deal with different add-on installers
coming from different locations (Amazon Cloud, a specific website, etc.).
This is one of the reasons why I'll continue to advocate that we create a
database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that
talks about this hasn't been updated since 2014, so we need to do that
ASAP. I'll do something about it (perhaps as an appendix in add-on
development guide where info such as value and types are shown as a
table).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Imo, you are free to do what you want. I don't use the add-on since it
caused problems with a dev version, which were updated to stable, but we
can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for
summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be
included. Maybe you are using conventions based on add-on template, but if
you want add-ons to serve to test future features, I think you should
listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions
when appropiate.

Cheers


El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so
people can be aware as to what's going on. For now, the add-on in
question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be a
bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the
add-on just because you are unwilling to add in the appropriate code to
check the type of what's being parsed is quite rude. For the list, for
example, loop through and build the string, then output it or do what you
want with the new string. Ignoring the problem seems, to me, like you are
unwilling to make the problem go away no matter what type you get from
Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility
that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst















Ethin Probst
 

James:
Thanks. I'm used to speaking frankly and leaving nothing out, I'll try
to sensor myself.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi,
James reviewed Screen Curtain and provided suggestions.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 8:04 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround
summary text in quotes

Hi, here is a thread with messages which shows that I reviewed the add-on.
It produced me a good impression. Notice that I mentioned that user
experience maybe improved and I recommended to post a dev version, and my
intention was this add-on could be improved as much as possible..
Later we discussed about the possibility that authors decide what is
declared stable and I requested you, as a person with great abilities to
write documentation, document it in the review process.
My intention was you could improve this add-on, as shown below.
Please don't feel bad. This is not my intention. BTW, I started writing
add-ons in 2012 before the website was created and also I listen to Mesar
when he created the first process review: we talk on an IRC channel.
Limitations of this process are that add-ons pass a basic review before
being included on the website, but other versions are not explicitly
reviewed, but they can receive feedback and imo it's the best we can do.
A question: Should we post add-ons in development section when they haven't
been reviewed? Who did review screenCurtain?
Cheers
Here's the thread.
Thanks for all your work, sincerely.

Hi, here are results of basic review:

License and copyright: Pass.
Security: Pass.
User experience: May be improved.
1. After updating add-ons, if possible, require to restart NVDA, or
explain this in the readme file.
2. Provide a mechanism to update add-ons deppending on the selected
channel, for instance, if I'm using a dev version of VLC, maybe I don't
want to update to a stable version.

Anyway, this is an excellent work for me and I would like to see a dev
version for testing inmediately posted on the website.
Also, if this is compatible with WX Python 4, once it's used this in the
add-on, and I think this is not longer used in NVDA:

self.Center(wx.BOTH | wx.CENTER_ON_SCREEN)

Now it's used:
self.CentreOnScreen()

Please fix me if I'm wrong.

I think this should be considered as a robust add-on and mantained as
such, since we don't know when this will be included in NVDA's core, and
for me it's better than including this in individual add-ons. I'm happy
for waiting and for not including this in add-ons maintained by me.
More reviews could be made in daily life.

Thanks


El 05/08/2018 a las 3:30, Joseph Lee escribió:
Hi all,
After probing around a bit, I found a temporary solution that won't
involve excluding add-ons: converting to and from Unicode strings. There
is a caveat, however: the add-ons in question will be shown with Python
code syntax. Note that this is a short-term solution - my stance on
long-term solution hasn't changed.

Regarding other matters raised:
* Review: yes, this add-on went through a basic review process (Noelia
reviewed this).
* Visibility: based on feedback from this community, I'll limit Add-on
Updater to the development section.
* Possible personal attacks and impression of my rudeness: yes: I did feel
bad when someone mentioned that my perceived attitude towards "not taking
suggestions" was rude. At the same time, I understood that this may have
come from someone who may have not known about the history of NVDA add-ons
community, as the root problem is related to that - old assumptions versus
what we have now. My ethos for pointing out history of this community and
root cause is because I was an early contributor to the add-ons community
- back in 2013, and I helped write text of the community add-ons website
when it was first designed. And no, I won't ask for apologies forcefully,
because I think saying sorry is tied to willpower.
* Perceived rudeness and stress: I think part of the reason for folks
getting the 'rudeness" impression may have had to do with my own stress
and not controlling it well. Because the bug raised was a showstopper and
I couldn't reproduce this on my system in the beginning, it took me a
while to figure out the root cause thanks to a log fragment sent by a user
and asking this person to try something on Python Console. After locating
the problem, I then realized that it could affect a whole class of add-ons
- old ones where manifest data had issues, hence the notice.
* Bad public relations regarding proof of concept tag: as James pointed
out, I should have said from the beginning that this is a proof of concept
work. This was communicated here and on add-ons website, but wasn't done
on social media, and I apologize for that.

Cheers,
Joseph

-----Original Message-----
From: joseph.lee22590@gmail.com <joseph.lee22590@gmail.com>
Sent: Saturday, August 4, 2018 1:32 PM
To: 'nvda-addons@nvda-addons.groups.io'
<nvda-addons@nvda-addons.groups.io>
Subject: RE: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Hi,
Add-on version string convention: this is due to limitations of the PHP
file hosted on add-ons server and to deal with different add-on installers
coming from different locations (Amazon Cloud, a specific website, etc.).
This is one of the reasons why I'll continue to advocate that we create a
database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that
talks about this hasn't been updated since 2014, so we need to do that
ASAP. I'll do something about it (perhaps as an appendix in add-on
development guide where info such as value and types are shown as a
table).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Imo, you are free to do what you want. I don't use the add-on since it
caused problems with a dev version, which were updated to stable, but we
can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for
summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be
included. Maybe you are using conventions based on add-on template, but if
you want add-ons to serve to test future features, I think you should
listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions
when appropiate.

Cheers


El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so
people can be aware as to what's going on. For now, the add-on in
question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

You do know that you could just check the type() of the manifest value
instead of ignoring the add-on as a workaround? I find this move to be a
bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the
add-on just because you are unwilling to add in the appropriate code to
check the type of what's being parsed is quite rude. For the list, for
example, loop through and build the string, then output it or do what you
want with the new string. Ignoring the problem seems, to me, like you are
unwilling to make the problem go away no matter what type you get from
Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility
that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst














--
Signed,
Ethin D. Probst


James Scholes
 

Joseph Lee wrote:
James reviewed Screen Curtain and provided suggestions.
Presuming this refers to me, I didn't actually provide a full review. In fact, in an email sent to the list not long afterwards, in response to the posting of the InputLock add-on, I pointed out that I'm not familiar enough with the review process to carry one out. Apologies if I gave the impression that I had carried out a review. If you're referring to someone else, I didn't see any email giving Screen Curtain a pass.

Cheers,
Joseph
-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 8:04 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest: surround summary text in quotes
Hi, here is a thread with messages which shows that I reviewed the add-on.
It produced me a good impression. Notice that I mentioned that user experience maybe improved and I recommended to post a dev version, and my intention was this add-on could be improved as much as possible..
Later we discussed about the possibility that authors decide what is declared stable and I requested you, as a person with great abilities to write documentation, document it in the review process.
My intention was you could improve this add-on, as shown below.
Please don't feel bad. This is not my intention. BTW, I started writing add-ons in 2012 before the website was created and also I listen to Mesar when he created the first process review: we talk on an IRC channel.
Limitations of this process are that add-ons pass a basic review before being included on the website, but other versions are not explicitly reviewed, but they can receive feedback and imo it's the best we can do.
A question: Should we post add-ons in development section when they haven't been reviewed? Who did review screenCurtain?
Cheers
Here's the thread.
Thanks for all your work, sincerely.

Hi, here are results of basic review:

License and copyright: Pass.
Security: Pass.
User experience: May be improved.
1. After updating add-ons, if possible, require to restart NVDA, or explain this in the readme file.
2. Provide a mechanism to update add-ons deppending on the selected channel, for instance, if I'm using a dev version of VLC, maybe I don't want to update to a stable version.

Anyway, this is an excellent work for me and I would like to see a dev version for testing inmediately posted on the website.
Also, if this is compatible with WX Python 4, once it's used this in the add-on, and I think this is not longer used in NVDA:

self.Center(wx.BOTH | wx.CENTER_ON_SCREEN)

Now it's used:
self.CentreOnScreen()

Please fix me if I'm wrong.

I think this should be considered as a robust add-on and mantained as such, since we don't know when this will be included in NVDA's core, and for me it's better than including this in individual add-ons. I'm happy for waiting and for not including this in add-ons maintained by me.
More reviews could be made in daily life.

Thanks
El 05/08/2018 a las 3:30, Joseph Lee escribió:
Hi all,
After probing around a bit, I found a temporary solution that won't involve excluding add-ons: converting to and from Unicode strings. There is a caveat, however: the add-ons in question will be shown with Python code syntax. Note that this is a short-term solution - my stance on long-term solution hasn't changed.

Regarding other matters raised:
* Review: yes, this add-on went through a basic review process (Noelia reviewed this).
* Visibility: based on feedback from this community, I'll limit Add-on Updater to the development section.
* Possible personal attacks and impression of my rudeness: yes: I did feel bad when someone mentioned that my perceived attitude towards "not taking suggestions" was rude. At the same time, I understood that this may have come from someone who may have not known about the history of NVDA add-ons community, as the root problem is related to that - old assumptions versus what we have now. My ethos for pointing out history of this community and root cause is because I was an early contributor to the add-ons community - back in 2013, and I helped write text of the community add-ons website when it was first designed. And no, I won't ask for apologies forcefully, because I think saying sorry is tied to willpower.
* Perceived rudeness and stress: I think part of the reason for folks getting the 'rudeness" impression may have had to do with my own stress and not controlling it well. Because the bug raised was a showstopper and I couldn't reproduce this on my system in the beginning, it took me a while to figure out the root cause thanks to a log fragment sent by a user and asking this person to try something on Python Console. After locating the problem, I then realized that it could affect a whole class of add-ons - old ones where manifest data had issues, hence the notice.
* Bad public relations regarding proof of concept tag: as James pointed out, I should have said from the beginning that this is a proof of concept work. This was communicated here and on add-ons website, but wasn't done on social media, and I apologize for that.

Cheers,
Joseph

-----Original Message-----
From: joseph.lee22590@gmail.com <joseph.lee22590@gmail.com>
Sent: Saturday, August 4, 2018 1:32 PM
To: 'nvda-addons@nvda-addons.groups.io'
<nvda-addons@nvda-addons.groups.io>
Subject: RE: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Hi,
Add-on version string convention: this is due to limitations of the PHP file hosted on add-ons server and to deal with different add-on installers coming from different locations (Amazon Cloud, a specific website, etc.). This is one of the reasons why I'll continue to advocate that we create a database to store version information to make our lives easier.
As for manifest string requirement: the portion of development guide that talks about this hasn't been updated since 2014, so we need to do that ASAP. I'll do something about it (perhaps as an appendix in add-on development guide where info such as value and types are shown as a table).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Saturday, August 4, 2018 1:01 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

Imo, you are free to do what you want. I don't use the add-on since it caused problems with a dev version, which were updated to stable, but we can go to the website and update manually, no problem.
Anyway, I think there is not a convention about quotations in manifest for summaries in NV Access developer guide. (please fix me if I'm wrong).
Also, you suggested to change the add-on name of speechHistory to be included. Maybe you are using conventions based on add-on template, but if you want add-ons to serve to test future features, I think you should listen a bit more suggestions of people.
This is my opinion for now, I'try to be flexible and change my opinions when appropiate.

Cheers


El 04/08/2018 a las 21:40, Joseph Lee escribió:
Hi,
Taking actions: that is what I have in mind. I sent out this notice so people can be aware as to what's going on. For now, the add-on in question will be ignored by my add-on.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io
<nvda-addons@nvda-addons.groups.io> On Behalf Of Ethin Probst
Sent: Saturday, August 4, 2018 12:08 PM
To: nvda-addons@nvda-addons.groups.io
Cc: NVDA screen reader development <nvda-devel@lists.sourceforge.net>
Subject: Re: [nvda-addons] Important note about add-on manifest:
surround summary text in quotes

You do know that you could just check the type() of the manifest value instead of ignoring the add-on as a workaround? I find this move to be a bit rude; you could just do something like:
if type(val)==str:
# actions
elif type(val)==list:
# actions
else:
#...
It would provide practically no overhead on the processor. Ignoring the add-on just because you are unwilling to add in the appropriate code to check the type of what's being parsed is quite rude. For the list, for example, loop through and build the string, then output it or do what you want with the new string. Ignoring the problem seems, to me, like you are unwilling to make the problem go away no matter what type you get from Python. If you get a number, str() it. Just a thought.

On 8/4/18, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi all,



In the course of debugging a bug with Add-on Updater reported by a
user, it has come to my attention that there is at least one add-on
out there that does not follow add-on manifest value conventions
correctly. The add-on in question (Nuance Vocalizer Expressive -
English Compact Voices) - does not use proper string quoting syntax
for ini files, with this causing add-on manifest summary retrievers
(including parts of Add-on Updater) to fail to parse this correctly
(Python converts this into a list, not a string), with a possibility that the add-on was generated manually.



Thus, whenever you need to provide a string that contains list of
items, please put quotes around the whole string, especially if you
are creating add-on manifests by hand.



As a result, the next version of Add-on Updater will not seek out
updates for the affected add-on until this is corrected from add-on
authors in the future.

Cheers,

Joseph





--
Signed,
Ethin D. Probst











Regards,

James Scholes
https://twitter.com/JamesScholes


Adriani Botez
 

In my opinion, the official website is the place where the users can be sure that add-ons are secure and that they have been reviewed by the community. This is our single argument when it comes to discussions with organizations and institutions about how secure NVDA and its add-ons are. So please be aware of that and take this processes seriously. If we want every proof of concept to land on an official webpage, then let's create a separate website for proof of concepts. But let's not start to declare proof of concepts as official add-ons. This will confuse users and developers at the same time and in the long term can create chaos.

In my view, all add-ons on the official add-on webpage must be reviewed, even the add-ons in the development section. Add-ons in development means that they have passed a basic review and at least from a security point of view the add-on cann be installed by any user.


Best regards
Adriani

-----Ursprüngliche Nachricht-----
Von: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-
addons.groups.io> Im Auftrag von James Scholes
Gesendet: Sonntag, 5. August 2018 00:34
An: nvda-addons@nvda-addons.groups.io
Betreff: Re: [nvda-addons] Important note about add-on manifest: surround
summary text in quotes

I'm happy to see the wealth of discussion surrounding this topic.

From a technical point of view, as a proof of concept there is no call for the
add-on to be perfect. Far from it, in fact. Given the extent to which the
current implementation relies on HTML scraping and hard-coded add-on
information, I don't believe the quality of it to exceed alpha status. However,
there are several issues here that need to be considered and addressed:

1. The add-on was promoted across the NVDA community, outside of
development-specific mailing lists. It was also posted on social media.
Here's the text of the widely-reposted tweet:

> Introducing Add-on Updater - check, download, apply #NVDASR add-on
updates: https://addons.nvda-project.org/addons/addonUpdater.en.html
@NVDAAddons @NVAccess

This tweet makes no mention of the fact that your aim with this work is to
solicit comments from technical testers or feedback on a pull request. Upon
opening the add-on's information page, users are informed that the current
version offered for download is "stable". It is not stable. Whatever else the
page may say is largely irrelevant because nowhere near the majority of users
will read and understand it.

2. This add-on was anounced, reviewed and posted without any consultation
with members of this group. Nobody was able to raise any concerns they
might have had, because they weren't given the opportunity. Personally, I
don't think it should have been listed on the add-ons website at all initially,
certainly not listed as "stable".
I would have been happy to raise these issues earlier and if I had been
overruled by an opposing majority then that is something I would've accepted
gracefully.

My primary concern is that the community of NVDA users is served in the best
way that we can serve them and clearly, this is a feature people want to see.
Your efforts are appreciated not only by myself, but by many users around the
world and, I'm sure, by the core NVDA team. But you're absolutely right that
the community is fragmented, and I think everybody has a part to play in that.
Certainly, reviewing our own add-ons, posting them to the add-ons website
without consultation, and promoting cutting edge alpha add-ons without
suitable warnings understandable by every single end user doesn't help.

Regards,

James Scholes
https://twitter.com/JamesScholes