Date   

Re: placeMarkers 14.1-dev and clipContentsDesigner 11.1-dev and other info about nvdaes add-ons #addontesting

Ján Kulik
 

If something has changed completely, I will also publish a translation
of these supplements for Slovak. In a week I would start translating all
of the add-ons with help.






Dňa 24. 11. 2019 o 13:22 zvonimir stanečić, 9a5dsz napísal(a):

Hi Noelia,
Can you wait till Friday, as I plan to update the placemarker translation for polish...
I have two fuzzy strings, so I will do that today

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, November 24, 2019 1:13 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] placeMarkers 14.1-dev and clipContentsDesigner 11.1-dev and other info about nvdaes add-ons #AddonTesting

Hi, as you may know, Cyrille has fixed the layout of the Find dialog
(control+NVDA+f) in NVDA's core. So I requested him for help to fix the specific search dialog in placeMarkers. He made a pull request and this is included in 14.1-dev version.
## Changes for 14.0 ##
* The command to copy the name of the file where place markers data
will be saved has been replaced by a command which shows this file name in browse mode. This is not assigned to a gesture.
* The "Text to search" field does not overlap the "Saved text" field
anymore. (Thanks to Cyrille Bougot).
* Requires NVDA 2019.3 or later.

This has been done using the addLabeledControl of guiHelper, and, though I think this has no visual impact in clipContentsDesigner add-on, I have using it too in 11.1-dev version as the appropiate way to ensure that edit controls in dialogs are well formatted. Reef did an excellent work providing us these facilities in guiHelper.

## Changes for 11.0
* Now it's possible to add text marked with the review cursor using standard commands of NVDA (NVDA+f9 and NVDA+f10). NVDA+windows+f9 is no longer used, for a better integration with the new NVDA+shift+f9 command.
* Requires NVDA 2019.3 or later.

Please, if you are using alpha versions of NVDA, update these add-ons for testing.
Other add-ons maintained by me don't have important visible changes.
These are: emoticons (the main author is Chris LM), eMule (in collaboration by Chris and Alberto Buffolino, just mentioning members of this list), readFeeds, reportSymbols, and pcKbBrl, created by Jamie (from NV Access), now maintained by me with possibility of using different keyboard layouts and typing braille with one hand. Please see the documentation to find more contributors and details. Dev version were provided and are available on the website to test with alpha versions of NVDA.






--
Ján Kulik


Re: placeMarkers 14.1-dev and clipContentsDesigner 11.1-dev and other info about nvdaes add-ons #addontesting

zvonimir stanečić, 9a5dsz
 

Hi Noelia,
Can you wait till Friday, as I plan to update the placemarker translation for polish...
I have two fuzzy strings, so I will do that today

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Noelia Ruiz
Sent: Sunday, November 24, 2019 1:13 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] placeMarkers 14.1-dev and clipContentsDesigner 11.1-dev and other info about nvdaes add-ons #AddonTesting

Hi, as you may know, Cyrille has fixed the layout of the Find dialog
(control+NVDA+f) in NVDA's core. So I requested him for help to fix the specific search dialog in placeMarkers. He made a pull request and this is included in 14.1-dev version.
## Changes for 14.0 ##
* The command to copy the name of the file where place markers data
will be saved has been replaced by a command which shows this file name in browse mode. This is not assigned to a gesture.
* The "Text to search" field does not overlap the "Saved text" field
anymore. (Thanks to Cyrille Bougot).
* Requires NVDA 2019.3 or later.

This has been done using the addLabeledControl of guiHelper, and, though I think this has no visual impact in clipContentsDesigner add-on, I have using it too in 11.1-dev version as the appropiate way to ensure that edit controls in dialogs are well formatted. Reef did an excellent work providing us these facilities in guiHelper.

## Changes for 11.0
* Now it's possible to add text marked with the review cursor using standard commands of NVDA (NVDA+f9 and NVDA+f10). NVDA+windows+f9 is no longer used, for a better integration with the new NVDA+shift+f9 command.
* Requires NVDA 2019.3 or later.

Please, if you are using alpha versions of NVDA, update these add-ons for testing.
Other add-ons maintained by me don't have important visible changes.
These are: emoticons (the main author is Chris LM), eMule (in collaboration by Chris and Alberto Buffolino, just mentioning members of this list), readFeeds, reportSymbols, and pcKbBrl, created by Jamie (from NV Access), now maintained by me with possibility of using different keyboard layouts and typing braille with one hand. Please see the documentation to find more contributors and details. Dev version were provided and are available on the website to test with alpha versions of NVDA.


placeMarkers 14.1-dev and clipContentsDesigner 11.1-dev and other info about nvdaes add-ons #addontesting

Noelia Ruiz
 

Hi, as you may know, Cyrille has fixed the layout of the Find dialog
(control+NVDA+f) in NVDA's core. So I requested him for help to fix
the specific search dialog in placeMarkers. He made a pull request and
this is included in 14.1-dev version.
## Changes for 14.0 ##
* The command to copy the name of the file where place markers data
will be saved has been replaced by a command which shows this file
name in browse mode. This is not assigned to a gesture.
* The "Text to search" field does not overlap the "Saved text" field
anymore. (Thanks to Cyrille Bougot).
* Requires NVDA 2019.3 or later.

This has been done using the addLabeledControl of guiHelper, and,
though I think this has no visual impact in clipContentsDesigner
add-on, I have using it too in 11.1-dev version as the appropiate way
to ensure that edit controls in dialogs are well formatted. Reef did
an excellent work providing us these facilities in guiHelper.

## Changes for 11.0
* Now it's possible to add text marked with the review cursor using
standard commands of NVDA (NVDA+f9 and NVDA+f10). NVDA+windows+f9 is
no longer used, for a better integration with the new NVDA+shift+f9
command.
* Requires NVDA 2019.3 or later.

Please, if you are using alpha versions of NVDA, update these add-ons
for testing.
Other add-ons maintained by me don't have important visible changes.
These are: emoticons (the main author is Chris LM), eMule (in
collaboration by Chris and Alberto Buffolino, just mentioning members
of this list), readFeeds, reportSymbols, and pcKbBrl, created by Jamie
(from NV Access), now maintained by me with possibility of using
different keyboard layouts and typing braille with one hand. Please
see the documentation to find more contributors and details. Dev
version were provided and are available on the website to test with
alpha versions of NVDA.


Re: Review Cursor Copier 1.2 released #addonrelease

Noelia Ruiz
 

Hi, also, I see that you have updated your email in the readme file,
so I will update it on the website.
Cheers

2019-11-24 12:19 GMT+01:00, Noelia Ruiz via Groups.Io
<nrm1977=gmail.com@groups.io>:

Hi Tuukka, I have updated the stable and dev version links to download
Review Cursor Copier 1.2 from the website.
This will be available in about 40 minutes, when the server is
automatically updated.
Cheers and thanks for this


2019-11-24 11:00 GMT+01:00, Tuukka Ojala <tuukka.ojala@iki.fi>:
Hi,
At long last I've released Review Cursor Copier 1.2. It contains the
necessary changes to make it compatible with NVDA 2019.3 as well as all
the
localization updates that were accumulated during the last 2 years.
Please
could someone with enough permissions update the download link for stable
and dev releases:
https://github.com/tuukkao/nvda-reviewCursorCopier/releases/download/1.2/reviewCursorCopier-1.2.nvda-addon

Thanks,
Tuukka






Re: Review Cursor Copier 1.2 released #addonrelease

Noelia Ruiz
 

Hi Tuukka, I have updated the stable and dev version links to download
Review Cursor Copier 1.2 from the website.
This will be available in about 40 minutes, when the server is
automatically updated.
Cheers and thanks for this


2019-11-24 11:00 GMT+01:00, Tuukka Ojala <tuukka.ojala@iki.fi>:

Hi,
At long last I've released Review Cursor Copier 1.2. It contains the
necessary changes to make it compatible with NVDA 2019.3 as well as all the
localization updates that were accumulated during the last 2 years. Please
could someone with enough permissions update the download link for stable
and dev releases:
https://github.com/tuukkao/nvda-reviewCursorCopier/releases/download/1.2/reviewCursorCopier-1.2.nvda-addon

Thanks,
Tuukka




Review Cursor Copier 1.2 released #addonrelease

Tuukka Ojala
 

Hi,
At long last I've released Review Cursor Copier 1.2. It contains the necessary changes to make it compatible with NVDA 2019.3 as well as all the localization updates that were accumulated during the last 2 years. Please could someone with enough permissions update the download link for stable and dev releases:
https://github.com/tuukkao/nvda-reviewCursorCopier/releases/download/1.2/reviewCursorCopier-1.2.nvda-addon
 
Thanks,
Tuukka


Re: Beginner to addon development

derek riemer
 

Should we just package those with the addon template?

On Fri, Nov 22, 2019 at 10:14 PM Luke Davis <luke@...> wrote:
On Fri, 22 Nov 2019, hmelias09@... wrote:

> My name is Hector Elias, and I have began reading the NVDA addon development guide. I have a simple question regarding this manual. Under the section of
> “Setting up your development environment” where it is talking about the gettext software, I find the following line:
>
> ◦ Once downloaded, copy both exe files to your add-on development folder. See the next section for a description of the add-on folder structure.

Sorry, I thought I had clarified that section.

The two files you need are:

msgfmt.exe
xgettext.exe

In order to stop carrying these files in repos, or having to exempt them, and
since I discontinued my own build environment and started using Appveyor, I have
a gist for those files, and you are welcome to use that directly or download
them as you see fit.

https://gist.github.com/XLTechie/f0ebdfefef3e5df88b289434ae07370b/raw/bb79b4d989a8245347afdddda0f59f26f1af7279/gettextFiles.zip

Luke





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

•    Personal website: https://derekriemer.com





Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Hi,
I'll get back to you all on this proposal after this weekend (at a speech
tournament at the moment).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Luke Davis
Sent: Friday, November 22, 2019 9:56 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify
add-on files database to include add-on name/ID for easier comparison and
for future-proofing

On Fri, 22 Nov 2019, Joseph Lee wrote:

Part of the reason why it is a bit difficult to test the pull request
as it stands and the complexity of Add-on Updater at the moment is due
to add-on name/ID to shorthand lookup. Whenever an add-on is added to
community add-ons website, a shorthand is created, which is then added
to Add-on Updater (I call this "registration"). This ad-on
name/shorthand map is then updated via Add-on Updater whenever the new
version of Add-on Updater is released. The proposal here is to store
the add-on name alongside shorthands on the server side, rather than
letting Add-on Updater carry this map.

As I understand what you are saying, you would alter the existing addons
names table, and add a nickname column.
Thus making your look-up process easier.
That seems perfectly reasonable if it is considered a temporary measure to
help with update deployment.
My objection is to two things:
1. Considering that in any way to be other than a temporary measure. I would
hate to see the nicknames system become part of core, because the wiki
software which demands them will probably go away as something new comes
online. If it is just intended to help with the current add-on updater
add-on, I think it would be fine.
2. Your original proposal suggested adding a new nickname, in addition to
the wiki-based one that is used in URLs. I think that adds a layer of
complexity and maintenance that is just unnecessary, which I think you have
now realized.

So, what I'm saying is:

If your proposal is to take the existing nicknames that the wiki based
system uses, and add those to a new column in the names table to provide a
one-to-one mapping for use exclusively by add-on updater, I would not
complain about that.

In an ideal situation what James is proposing should take place: just
create the add-ons metadata database rather than duplicating entries.
But I feel that in order to at least test the viability of this
approach, some kind of a testbed should be created somewhere.
Then make a new table in the existing database. If the existing add-on names
are a key, use those as the unique foreign key for your new table, put the
current wiki-derived nicknames in there along side the add-on names, and
point add-on updater to it to get its information.
That way you have zero impact on the current arrangement if you need to
suddenly revert thereto. I.E. something like this (unchecked):

CREATE TABLE addon_handles (
id serial unique,
name varchar(255) character set UTF8 not null default '' primary
key
comment "Long to allow enough length for multibyte
characters"
REFERENCES main_addons_table(addon_name_column) on delete
cascade,
handle varchar(50) not null
comment "Nickname used for URLs and NVDA internals" -- May
not need to be UTF8 );

version, URL, and hash for each entry. In short, what we really need
is a group of people that will work on the server and transport
infrastructure,
Which is what Derek and I have been doing, all be it both getting frequently
distracted by other things.

P.S. Usually I'm not like this - being in control of a situation and
not displaying breakdowns like this. Dear NVDA community, please HELP
ME!!!

It's a forest and trees problem. We can get so focused on a particular way
of doing a thing, that alternatives do not even occur to us. If it didn't
also happen to you, I would fear for your humanity.

Luke


Re: Audio editors

Adriani Botez
 

Usually between 40 min and 120 min. Due to different microfon qualities and microfon gain the files need spot editing.



Von meinem iPhone gesendet

Am 23.11.2019 um 09:05 schrieb Brian's Mail list account via Groups.Io <bglists=blueyonder.co.uk@groups.io>:

Hi, How long are these files and do they need spot editing or is it just global effects that need to be performed, IE if its clicks, provided they are symmetrical then one can usually find a level where the bad ones are removed without making the audio distorted. For normalising, often some compression might be needed first to remove the peaks so one can normalise the whole file without huge discrepancies, but there are limits to what can be done with noise hum and background stuff as I'm sure you know.
I do not have the time now, had I known you might need help I'd have gladly put some time aside, but I've agreed to do some stuff for somebody else in the next few weeks and Christmas is coming!

Brian

bglists@blueyonder.co.uk
Sent via blueyonder.
Please address personal E-mail to:-
briang1@blueyonder.co.uk, putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Adriani Botez" <adriani.botez@gmail.com>
To: <nvda@nvda.groups.io>; <nvda-addons@nvda-addons.groups.io>; <intl@NVDACon.groups.io>
Sent: Friday, November 22, 2019 11:22 PM
Subject: [nvda-addons] Audio editors


Dear all,



we are still in process of audio editing of NVDACon sessions and realized we
need help to finish the work as fast as possible.



If you are familiar with normalizing volume, labeling, removing crackling
noise, removing echo and improving audio quality in general, please write me
an email and I will send you files which still need editing.

Note that I will send raw flac files to avoid quality losses.



If you want to have an impression of the quality that we would like to have,
here is a link where you can find the finalized files so far.



https://derekriemer.com/nvdacon/finished/



Best regards

Adriani







Re: Audio editors

Brian's Mail list account
 

Hi, How long are these files and do they need spot editing or is it just global effects that need to be performed, IE if its clicks, provided they are symmetrical then one can usually find a level where the bad ones are removed without making the audio distorted. For normalising, often some compression might be needed first to remove the peaks so one can normalise the whole file without huge discrepancies, but there are limits to what can be done with noise hum and background stuff as I'm sure you know.
I do not have the time now, had I known you might need help I'd have gladly put some time aside, but I've agreed to do some stuff for somebody else in the next few weeks and Christmas is coming!

Brian

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

----- Original Message -----
From: "Adriani Botez" <adriani.botez@gmail.com>
To: <nvda@nvda.groups.io>; <nvda-addons@nvda-addons.groups.io>; <intl@NVDACon.groups.io>
Sent: Friday, November 22, 2019 11:22 PM
Subject: [nvda-addons] Audio editors


Dear all,



we are still in process of audio editing of NVDACon sessions and realized we
need help to finish the work as fast as possible.



If you are familiar with normalizing volume, labeling, removing crackling
noise, removing echo and improving audio quality in general, please write me
an email and I will send you files which still need editing.

Note that I will send raw flac files to avoid quality losses.



If you want to have an impression of the quality that we would like to have,
here is a link where you can find the finalized files so far.



https://derekriemer.com/nvdacon/finished/



Best regards

Adriani






Re: Speech history, translate, and other add-ons

Brian's Mail list account
 

Maybe it can be fixed or even put into nvda core.
Brian

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

----- Original Message -----
From: "David Moore" <jesusloves1966@gmail.com>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Friday, November 22, 2019 9:59 PM
Subject: Re: [nvda-addons] Speech history, translate, and other add-ons


Yes!
Say as product name and version was the add-on I used the most!
It was so beautiful to know the version that I Was using so easily!
People really like this feature in JAWS, so I really pray we can get it back into NVDA.
David Moore

Sent from Mail for Windows 10

From: Ján Kulik
Sent: Friday, November 22, 2019 3:32 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] Speech history, translate, and other add-ons

Hi all,



do some add-on authors who are in charge of Speech history, Translate
and other older add-ons know that they will not be compatible with
python 3? I use these add-ons for my own use. The add-on for the NVDA
Sais Product name and version, I don't know who's in charge, but it
looks like this add-on will probably not evolve anymore. I use it to
determine the application, so I use them to determine the versions of
applications, if I'm not sure what version of the application I use,
then I use the shortcut SHIFT + NVDA + V to find out thanks to Sais
Product name and version.




thank.



--
Ján Kulik


Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

Luke Davis
 

On Fri, 22 Nov 2019, Joseph Lee wrote:

Part of the reason why it is a bit difficult to test the pull request as it stands and the complexity of Add-on Updater at the moment is due to add-on name/ID to shorthand lookup. Whenever an add-on is added to community add-ons website, a shorthand is created, which is then added to Add-on Updater (I call this "registration"). This ad-on name/shorthand map is then updated via Add-on Updater whenever the new version of Add-on Updater is released. The proposal here is to store the add-on name alongside shorthands on the server side, rather than letting Add-on Updater carry this map.
As I understand what you are saying, you would alter the existing addons names table, and add a nickname column.
Thus making your look-up process easier.
That seems perfectly reasonable if it is considered a temporary measure to help with update deployment.
My objection is to two things:
1. Considering that in any way to be other than a temporary measure. I would hate to see the nicknames system become part of core, because the wiki software which demands them will probably go away as something new comes online. If it is just intended to help with the current add-on updater add-on, I think it would be fine.
2. Your original proposal suggested adding a new nickname, in addition to the wiki-based one that is used in URLs. I think that adds a layer of complexity and maintenance that is just unnecessary, which I think you have now realized.

So, what I'm saying is:

If your proposal is to take the existing nicknames that the wiki based system uses, and add those to a new column in the names table to provide a one-to-one mapping for use exclusively by add-on updater, I would not complain about that.

In an ideal situation what James is proposing should take place: just create the add-ons metadata database rather than duplicating entries. But I feel that in order to at least test the viability of this approach, some kind of a testbed should be created somewhere.
Then make a new table in the existing database. If the existing add-on names are a key, use those as the unique foreign key for your new table, put the current wiki-derived nicknames in there along side the add-on names, and point add-on updater to it to get its information.
That way you have zero impact on the current arrangement if you need to suddenly revert thereto. I.E. something like this (unchecked):

CREATE TABLE addon_handles (
id serial unique,
name varchar(255) character set UTF8 not null default '' primary key
comment "Long to allow enough length for multibyte characters"
REFERENCES main_addons_table(addon_name_column) on delete cascade,
handle varchar(50) not null
comment "Nickname used for URLs and NVDA internals" -- May not need to be UTF8
);

version, URL, and hash for each entry. In short, what we really need is a group of people that will work on the server and transport infrastructure,
Which is what Derek and I have been doing, all be it both getting frequently distracted by other things.

P.S. Usually I'm not like this - being in control of a situation and not displaying breakdowns like this. Dear NVDA community, please HELP ME!!!
It's a forest and trees problem. We can get so focused on a particular way of doing a thing, that alternatives do not even occur to us. If it didn't also happen to you, I would fear for your humanity.

Luke


Re: Beginner to addon development

Luke Davis
 

On Fri, 22 Nov 2019, hmelias09@gmail.com wrote:

My name is Hector Elias, and I have began reading the NVDA addon development guide. I have a simple question regarding this manual. Under the section of
“Setting up your development environment” where it is talking about the gettext software, I find the following line:
◦ Once downloaded, copy both exe files to your add-on development folder. See the next section for a description of the add-on folder structure.
Sorry, I thought I had clarified that section.

The two files you need are:

msgfmt.exe
xgettext.exe

In order to stop carrying these files in repos, or having to exempt them, and since I discontinued my own build environment and started using Appveyor, I have a gist for those files, and you are welcome to use that directly or download them as you see fit.

https://gist.github.com/XLTechie/f0ebdfefef3e5df88b289434ae07370b/raw/bb79b4d989a8245347afdddda0f59f26f1af7279/gettextFiles.zip

Luke


Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Hi,
I should have said, "I felt" when talking about the proposal.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Joseph Lee via Groups.Io
Sent: Friday, November 22, 2019 9:06 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

Hi,
Part of the reason why it is a bit difficult to test the pull request as it stands and the complexity of Add-on Updater at the moment is due to add-on name/ID to shorthand lookup. Whenever an add-on is added to community add-ons website, a shorthand is created, which is then added to Add-on Updater (I call this "registration"). This ad-on name/shorthand map is then updated via Add-on Updater whenever the new version of Add-on Updater is released. The proposal here is to store the add-on name alongside shorthands on the server side, rather than letting Add-on Updater carry this map.
In an ideal situation what James is proposing should take place: just create the add-ons metadata database rather than duplicating entries. But I feel that in order to at least test the viability of this approach, some kind of a testbed should be created somewhere.
As for numeric ID's, this will work if the add-on updater client (that's the portion I'm working on) sends a list of installed add-ons alongside NVDA version and Windows version one is using to the add-ons server. At the high level, all the server needs to do is return a map (encoded via JSON at least) that records names of add-ons with updates, along with metadata such as version, URL, and hash for each entry. In short, what we really need is a group of people that will work on the server and transport infrastructure, along with training add-on authors as to how to update their add-on metadata via a user interface - that is, transforming our current add-on files Git repo push/pull mechanism to database transactions.
I know I'm ranting and might be showing my frustration and anger at this point (angry at myself), and after thinking about the below post, I begin to wonder if I am indeed losing touch with reality... Luke and James are right.
P.S. Usually I'm not like this - being in control of a situation and not displaying breakdowns like this. Dear NVDA community, please HELP ME!!!
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Luke Davis
Sent: Friday, November 22, 2019 3:27 PM
To: nvda-devel@groups.io; nvda-addons@groups.io
Subject: Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

On Fri, 22 Nov 2019, Joseph Lee wrote:

Currently add-on files database, which hosts links for add-on
downloads, uses shorthands to store add-on link information. I’m
thinking about adding add-on name/ID entries to this database, both to
simplify Add-on Updater add-on and to serve as a proof of concept for
a future add-ons metadata database, which will host metadata such as add-on version, description, changelog paragraph for a new version, compatibility range flags and other useful information. This metadata database, which is being designed by several community members, will also serve as a backbone for future add-on updating functionality in NVDA screen reader.
I have two points.

1. If any part of that was referencing the work that Derek and I are doing, I will note that by its nature, the PostGreSQL database used will include guaranteed unique numeric IDs for each add-on.

2. That aside, I completely agree with James Scholes, in not really understanding what problem adding a third identifier will solve.

A. We have the actual single-word add-on name that everything uses to one degree or another.
B. We have the shorthand form that the add-on site wiki imposes on us because of localization length limits.
C. Now you want to add a third unique alpha-numeric identifier for reasons that don't seem clear when we already have two unique identifiers.
D. Whether the work Derek and I are doing is ultimately accepted, or whether someone else does something that is, surely any database will have a unique numeric identifier of some kind associated with each add-on. I have not seen the current database, but I'm kind of surprised it doesn't have one already.

So, my question is: why not use A, or B, or D in the work you are doing? Why add C?

More than just practicality, I note the below:

* For now if this proposal is adopted, only Add-on Updater will use the new keys. In the end, both Add-on Updater and the eventual add-on update feature
in NVDA will consult the new add-on metadata database.
I'm not clear on whether that means it will use this new identifier, in which case we're all stuck with the new identifiers and having to maintain them for the long term, or if it means that you will throw out the new identifiers and use the new metadatabase you are talking about.
In the first case, then I strongly oppose adding a new set of identifiers now.
In the latter case then I reiterate my question above: what's the point? Use one of the existing unique identifiers, and eliminate half the work involved since it's all going to be ripped out in some months anyway.

The biggest advantage is simplified Add-on Updater and add-on updating
functionality in NVDA screen reader – one can just check add-on name/ID and figure out if an update is available. The drawback is duplicate entries and prone to typos, along with translation concerns.
While that is a significant drawback, I would like to understand what stands in the way of doing the first part now? Why can't you check name and database number, or name and short identifier, or whatever arrangement is needed?

Are you suggesting that the existing identifiers are not unique?

* The new add-on name/ID keys will not be visible to the public via community add-ons website – shorthands will still be used. This should minimize
translation issues.
Numeric IDs would minimize them more.

Luke


Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Hi,
Part of the reason why it is a bit difficult to test the pull request as it stands and the complexity of Add-on Updater at the moment is due to add-on name/ID to shorthand lookup. Whenever an add-on is added to community add-ons website, a shorthand is created, which is then added to Add-on Updater (I call this "registration"). This ad-on name/shorthand map is then updated via Add-on Updater whenever the new version of Add-on Updater is released. The proposal here is to store the add-on name alongside shorthands on the server side, rather than letting Add-on Updater carry this map.
In an ideal situation what James is proposing should take place: just create the add-ons metadata database rather than duplicating entries. But I feel that in order to at least test the viability of this approach, some kind of a testbed should be created somewhere.
As for numeric ID's, this will work if the add-on updater client (that's the portion I'm working on) sends a list of installed add-ons alongside NVDA version and Windows version one is using to the add-ons server. At the high level, all the server needs to do is return a map (encoded via JSON at least) that records names of add-ons with updates, along with metadata such as version, URL, and hash for each entry. In short, what we really need is a group of people that will work on the server and transport infrastructure, along with training add-on authors as to how to update their add-on metadata via a user interface - that is, transforming our current add-on files Git repo push/pull mechanism to database transactions.
I know I'm ranting and might be showing my frustration and anger at this point (angry at myself), and after thinking about the below post, I begin to wonder if I am indeed losing touch with reality... Luke and James are right.
P.S. Usually I'm not like this - being in control of a situation and not displaying breakdowns like this. Dear NVDA community, please HELP ME!!!
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Luke Davis
Sent: Friday, November 22, 2019 3:27 PM
To: nvda-devel@groups.io; nvda-addons@groups.io
Subject: Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

On Fri, 22 Nov 2019, Joseph Lee wrote:

Currently add-on files database, which hosts links for add-on
downloads, uses shorthands to store add-on link information. I’m
thinking about adding add-on name/ID entries to this database, both to
simplify Add-on Updater add-on and to serve as a proof of concept for
a future add-ons metadata database, which will host metadata such as add-on version, description, changelog paragraph for a new version, compatibility range flags and other useful information. This metadata database, which is being designed by several community members, will also serve as a backbone for future add-on updating functionality in NVDA screen reader.
I have two points.

1. If any part of that was referencing the work that Derek and I are doing, I will note that by its nature, the PostGreSQL database used will include guaranteed unique numeric IDs for each add-on.

2. That aside, I completely agree with James Scholes, in not really understanding what problem adding a third identifier will solve.

A. We have the actual single-word add-on name that everything uses to one degree or another.
B. We have the shorthand form that the add-on site wiki imposes on us because of localization length limits.
C. Now you want to add a third unique alpha-numeric identifier for reasons that don't seem clear when we already have two unique identifiers.
D. Whether the work Derek and I are doing is ultimately accepted, or whether someone else does something that is, surely any database will have a unique numeric identifier of some kind associated with each add-on. I have not seen the current database, but I'm kind of surprised it doesn't have one already.

So, my question is: why not use A, or B, or D in the work you are doing? Why add C?

More than just practicality, I note the below:

* For now if this proposal is adopted, only Add-on Updater will use the new keys. In the end, both Add-on Updater and the eventual add-on update feature
in NVDA will consult the new add-on metadata database.
I'm not clear on whether that means it will use this new identifier, in which case we're all stuck with the new identifiers and having to maintain them for the long term, or if it means that you will throw out the new identifiers and use the new metadatabase you are talking about.
In the first case, then I strongly oppose adding a new set of identifiers now.
In the latter case then I reiterate my question above: what's the point? Use one of the existing unique identifiers, and eliminate half the work involved since it's all going to be ripped out in some months anyway.

The biggest advantage is simplified Add-on Updater and add-on updating
functionality in NVDA screen reader – one can just check add-on name/ID and figure out if an update is available. The drawback is duplicate entries and prone to typos, along with translation concerns.
While that is a significant drawback, I would like to understand what stands in the way of doing the first part now? Why can't you check name and database number, or name and short identifier, or whatever arrangement is needed?

Are you suggesting that the existing identifiers are not unique?

* The new add-on name/ID keys will not be visible to the public via community add-ons website – shorthands will still be used. This should minimize
translation issues.
Numeric IDs would minimize them more.

Luke


Beginner to addon development

hmelias09@...
 

Hello Everyone:

 

My name is Hector Elias, and I have began reading the NVDA addon development guide. I have a simple question regarding this manual. Under the section of “Setting up your development environment” where it is talking about the gettext software, I find the following line:

◦ Once downloaded, copy both exe files to your add-on development folder. See the next section for a description of the add-on folder structure.

 

I went to the SourceForge website, and only got one exe file. What am I missing? What is the second file? I only saw the source archive.

 

Any assistance is greatly appreciated.

 

Respectfully,

 

Hector


Re: [nvda-devel] [nvda-addons] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

Luke Davis
 

On Fri, 22 Nov 2019, Joseph Lee wrote:

Currently add-on files database, which hosts links for add-on downloads, uses shorthands to store add-on link information. I’m thinking about adding add-on
name/ID entries to this database, both to simplify Add-on Updater add-on and to serve as a proof of concept for a future add-ons metadata database, which
will host metadata such as add-on version, description, changelog paragraph for a new version, compatibility range flags and other useful information. This
metadata database, which is being designed by several community members, will also serve as a backbone for future add-on updating functionality in NVDA
screen reader.
I have two points.

1. If any part of that was referencing the work that Derek and I are doing, I will note that by its nature, the PostGreSQL database used will include guaranteed unique numeric IDs for each add-on.

2. That aside, I completely agree with James Scholes, in not really understanding what problem adding a third identifier will solve.

A. We have the actual single-word add-on name that everything uses to one degree or another.
B. We have the shorthand form that the add-on site wiki imposes on us because of localization length limits.
C. Now you want to add a third unique alpha-numeric identifier for reasons that don't seem clear when we already have two unique identifiers.
D. Whether the work Derek and I are doing is ultimately accepted, or whether someone else does something that is, surely any database will have a unique numeric identifier of some kind associated with each add-on. I have not seen the current database, but I'm kind of surprised it doesn't have one already.

So, my question is: why not use A, or B, or D in the work you are doing? Why add C?

More than just practicality, I note the below:

* For now if this proposal is adopted, only Add-on Updater will use the new keys. In the end, both Add-on Updater and the eventual add-on update feature
in NVDA will consult the new add-on metadata database.
I'm not clear on whether that means it will use this new identifier, in which case we're all stuck with the new identifiers and having to maintain them for the long term, or if it means that you will throw out the new identifiers and use the new metadatabase you are talking about.
In the first case, then I strongly oppose adding a new set of identifiers now.
In the latter case then I reiterate my question above: what's the point? Use one of the existing unique identifiers, and eliminate half the work involved since it's all going to be ripped out in some months anyway.

The biggest advantage is simplified Add-on Updater and add-on updating functionality in NVDA screen reader – one can just check add-on name/ID and figure
out if an update is available. The drawback is duplicate entries and prone to typos, along with translation concerns.
While that is a significant drawback, I would like to understand what stands in the way of doing the first part now? Why can't you check name and database number, or name and short identifier, or whatever arrangement is needed?

Are you suggesting that the existing identifiers are not unique?

* The new add-on name/ID keys will not be visible to the public via community add-ons website – shorthands will still be used. This should minimize
translation issues.
Numeric IDs would minimize them more.

Luke


Audio editors

Adriani Botez
 

Dear all,

 

we are still in process of audio editing of NVDACon sessions and realized we need help to finish the work as fast as possible.

 

If you are familiar with normalizing volume, labeling, removing crackling noise, removing echo and improving audio quality in general, please write me an email and I will send you files which still need editing.

Note that I will send raw flac files to avoid quality losses.

 

If you want to have an impression of the quality that we would like to have, here is a link where you can find the finalized files so far.

 

https://derekriemer.com/nvdacon/finished/

 

Best regards

Adriani

 


Re: Speech history, translate, and other add-ons

David Moore
 

Yes!

Say as product name and version was the add-on I used the most!

It was so beautiful to know the version that I Was using so easily!

People really like this feature in JAWS, so I really pray we can get it back into NVDA.

David Moore

 

Sent from Mail for Windows 10

 

From: Ján Kulik
Sent: Friday, November 22, 2019 3:32 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] Speech history, translate, and other add-ons

 

Hi all,

 

 

 

do some add-on authors who are in charge of Speech history, Translate

and other older add-ons know that they will not be compatible with

python 3? I use these add-ons for my own use. The add-on for the NVDA

Sais Product name and version, I don't know who's in charge, but it

looks like this add-on will probably not evolve anymore. I use it to

determine the application, so I use them to determine the versions of

applications, if I'm not sure what version of the application I use,

then I use the shortcut SHIFT + NVDA + V to find out thanks to Sais

Product name and version.

 

 

 

 

thank.

 

 

 

--

Ján Kulik

 

 


Speech history, translate, and other add-ons

Ján Kulik
 

Hi all,



do some add-on authors who are in charge of Speech history, Translate
and other older add-ons know that they will not be compatible with
python 3? I use these add-ons for my own use. The add-on for the NVDA
Sais Product name and version, I don't know who's in charge, but it
looks like this add-on will probably not evolve anymore. I use it to
determine the application, so I use them to determine the versions of
applications, if I'm not sure what version of the application I use,
then I use the shortcut SHIFT + NVDA + V to find out thanks to Sais
Product name and version.




thank.



--
Ján Kulik

4401 - 4420 of 14681