Topics

Storing and Using Persistent Information Outside Your Add-on


Omer Zak
 

I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information Outside
Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using persistent
information, and whose techniques I could study?

Thanks,
--- Omer Zak

--
Did you shave a yak today?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html


 

Hi,
As the person responsible for saying "coming soon", I'll do something about it in coming days so the necessary information (including configuration data, pickle protocol, JSON, etc.) can be included in the 2020.3 edition of the guide.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 7:23 AM
To: nvda-addons@groups.io
Subject: [nvda-addons] Storing and Using Persistent Information Outside Your Add-on

I am developing a NVDA add-on which needs to access and store persistent information.
I joined this mailing list few days ago and I apologize if the following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using persistent information, and whose techniques I could study?

Thanks,
--- Omer Zak

--
Did you shave a yak today?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html


Noelia Ruiz
 

Hello. From my part:

An example of storing information in Pickle and text files, placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From my
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:

I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information Outside
Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using persistent
information, and whose techniques I could study?

Thanks,
--- Omer Zak

--
Did you shave a yak today?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html





James Scholes
 

There are many add-ons storing configuration in .ini files
Please don't encourage this. The NVDA config file should be used for simple INI-style, key/value pairs of data. Creating your own config files means that resetting or backing up the core NVDA config has no impact on your add-on. If you need to store anything more advanced, such as data structures, JSON and/or pickling is the way to go. Otherwise, try to integrate as tightly as possible into NVDA itself.

@Omer, you can take a look at Speech History and many other add-ons, particularly those which add an NVDA settings panel or dialog, for examples of storing config data. If this doesn't meet your needs, feel free to tell us a bit more about your use case and we can recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:
An example of storing information in Pickle and text files, placeMarkers:
https://github.com/nvdaes/placemarkers
There are many add-ons storing configuration in .ini files. From my
part, for example reportPassword, which is a super-simple add-on:
https://github.com/nvdaes/reportPasswords
Cheers
2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information Outside
Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using persistent
information, and whose techniques I could study?

Thanks,
--- Omer Zak

--
Did you shave a yak today?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html




Noelia Ruiz
 

Hello, the mentioned add-on, reportPasswords, stores data in
config.conf, but this ultimately stores data in nvda.ini or in ini
files for profiles.
My intention is not encouraging to use ini files specific for add-ons,
otherwise I would mention other add-on.

Regards

2020-09-08 18:46 GMT+02:00, James Scholes <james@...>:

> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used for
simple INI-style, key/value pairs of data. Creating your own config
files means that resetting or backing up the core NVDA config has no
impact on your add-on. If you need to store anything more advanced,
such as data structures, JSON and/or pickling is the way to go.
Otherwise, try to integrate as tightly as possible into NVDA itself.

@Omer, you can take a look at Speech History and many other add-ons,
particularly those which add an NVDA settings panel or dialog, for
examples of storing config data. If this doesn't meet your needs, feel
free to tell us a bit more about your use case and we can recommend
something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files, placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From my
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information Outside
Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using persistent
information, and whose techniques I could study?

Thanks,
--- Omer Zak

--
Did you shave a yak today?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which
I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html








Omer Zak
 

Hello James,

What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions extensionPoints.Filter)
which translates a string before speaking it or displaying it in
Braille. The filter would use the same database as my add-on.

Current status:

1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak

On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used
for
simple INI-style, key/value pairs of data. Creating your own config
files means that resetting or backing up the core NVDA config has no
impact on your add-on. If you need to store anything more advanced,
such as data structures, JSON and/or pickling is the way to go.
Otherwise, try to integrate as tightly as possible into NVDA itself.

@Omer, you can take a look at Speech History and many other add-ons,
particularly those which add an NVDA settings panel or dialog, for
examples of storing config data. If this doesn't meet your needs,
feel
free to tell us a bit more about your use case and we can recommend
something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From my
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information
Outside
Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent
information, and whose techniques I could study?
--
In civilized societies, captions are as important in movies as
soundtracks, professional photography and expert editing.
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with
which I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html


 

Hi,
Okay, I raise serious issues with this proposal:
1. Please be careful about word choice: when folks hear the word "abuse" in context of software, it can mean bad activities such as tampering with security. I sort of can tell that English might not be your first language, which is perfectly understandable. However, because this forum is public with a publicly viewable archive, it would be better to think about the words used when describing what the software should do. Note that this issue is subjective and is not that serious unless your motives say otherwise.
2. Persistent storage: JSON might be best suited for this, as it allows human-readable representation of a dictionary.
3. A very serious issue on localization and intent: app localization is NOT an add-on domain. An add-on is meant to improve usage of a feature or a program by using strategies to help users use a feature or an app. An add-on (in this case, an app module) is NOT AN EFFECTIVE route for app localization - that's a completely different activity. The best people to contact regarding app localization is the people who actually produced the program in question (this is applicable even to NVDA, as the people who should be contacted about NVDA localization is NV Access staff, who will then forward such requests to translators; this principle is also applicable to add-ons themselves, as authors are responsible for working with translators regarding add-on localization based on feedback from users).

Therefore, before thinking about persistent storage, please:
1. Tell us about the app you are trying to localize through this add-on.
2. Contact app developers about localization issues.
Although I recommend doing both, please do the second item as soon as possible.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 10:22 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information Outside Your Add-on

Hello James,

What I actually need is a convention for specifying the default location for a SQLite database (a single file) storing information needed by my add-on. My add-on will have a configuration dialog for overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not originally localized. It is relevant when the user cannot have the software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use speech or Braille. The accessible solution for them would be to use a filter (NVDA Add-on Development Guide mentions extensionPoints.Filter) which translates a string before speaking it or displaying it in Braille. The filter would use the same database as my add-on.

Current status:

1. Display of a translation for strings being hovered over - is implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak



On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used for
simple INI-style, key/value pairs of data. Creating your own config
files means that resetting or backing up the core NVDA config has no
impact on your add-on. If you need to store anything more advanced,
such as data structures, JSON and/or pickling is the way to go.
Otherwise, try to integrate as tightly as possible into NVDA itself.

@Omer, you can take a look at Speech History and many other add-ons,
particularly those which add an NVDA settings panel or dialog, for
examples of storing config data. If this doesn't meet your needs,
feel free to tell us a bit more about your use case and we can
recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From my
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Develo
pment%20Guide
)
has a section about Storing and Using Persistent Information
Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent information, and whose techniques I could study?
--
In civilized societies, captions are as important in movies as soundtracks, professional photography and expert editing.
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html


James Scholes
 

@Omer: Understood; the best place to store the SQLite DB path is within NVDA's core config. Speech History and other add-ons can provide a simple example of this. Of course, you can opt to store it elsewhere, e.g. in a separate file inside your add-on, but storing it inside NVDA's config file will allow users to save/reset it if they wish. You may also want to take advantage of separate databases or tables per application, and using NVDA's core config system will allow you to take advantage of app-specific profiles.

@Joseph: Unless a developer asks this community for an add-on review, it isn't necessarily our place to comment on the suitability of their use case(s). It is often appropriate to comment on the feasibility of a particular approach, be that technical or otherwise, and I agree with your comments about contacting application authors for localisation purposes. But unfortunately, many apps are not built from the ground up to support localisation or internationalisation, and NVDA could be said to be well-placed to help given its deep integration into the OS. If this add-on is released publically in any fashion, and the core NVAccess team feel that it brings undue negative attention to the screen reader, it is for them to take action as they see fit.

Regards,

James Scholes

On 08/09/2020 at 12:22 pm, Omer Zak wrote:
Hello James,
What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.
My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.
The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.
Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.
Accessibility note:
The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions extensionPoints.Filter)
which translates a string before speaking it or displaying it in
Braille. The filter would use the same database as my add-on.
Current status:
1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO
Regards,
--- Omer Zak
On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files
Please don't encourage this. The NVDA config file should be used
for simple INI-style, key/value pairs of data. Creating your own config files means that resetting or backing up the core NVDA config has no impact on your add-on. If you need to store anything more advanced, such as data structures, JSON and/or pickling is the way to go. Otherwise, try to integrate as tightly as possible into NVDA itself.
@Omer, you can take a look at Speech History and many other add-ons, particularly those which add an NVDA settings panel or dialog, for examples of storing config data. If this doesn't meet your needs,
feel free to tell us a bit more about your use case and we can recommend something specific.
Regards,
James Scholes
On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:
An example of storing information in Pickle and text files,
placeMarkers:
https://github.com/nvdaes/placemarkers
There are many add-ons storing configuration in .ini files. From my
part, for example reportPassword, which is a super-simple add-on:
https://github.com/nvdaes/reportPasswords
Cheers
2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.
The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Development%20Guide
)
has a section about Storing and Using Persistent Information
Outside
Your Add-on.
However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.
Is there any alternative source for this information that I could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent
information, and whose techniques I could study?


Omer Zak
 

Hello Joseph,
See my comments below.

On Tue, 2020-09-08 at 10:42 -0700, Joseph Lee wrote:
Hi,
Okay, I raise serious issues with this proposal:
1. Please be careful about word choice: when folks hear the word
"abuse" in context of software, it can mean bad activities such as
tampering with security. I sort of can tell that English might not be
your first language, which is perfectly understandable. However,
because this forum is public with a publicly viewable archive, it
would be better to think about the words used when describing what
the software should do. Note that this issue is subjective and is not
that serious unless your motives say otherwise.
I used the word 'abuse' in the meaning of 'use for a different purpose
than originally intended'.
You confirmed the 'a different purpose than originally intended' part
below.
Thanks for your warning, and I'll try to be more careful in my word
choice in the future.

2. Persistent storage: JSON might be best suited for this, as it
allows human-readable representation of a dictionary.
When and if the dictionary has 10^5 or more strings, it will be more
efficient to use a database with a cache Dict in memory.
I do plan to use JSON files for the time being and switch later to
SQLite if so warranted. However they too need to be placed in a
directory in the user's hard disk.

3. A very serious issue on localization and intent: app localization
is NOT an add-on domain. An add-on is meant to improve usage of a
feature or a program by using strategies to help users use a feature
or an app. An add-on (in this case, an app module) is NOT AN
EFFECTIVE route for app localization - that's a completely different
activity. The best people to contact regarding app localization is
the people who actually produced the program in question (this is
applicable even to NVDA, as the people who should be contacted about
NVDA localization is NV Access staff, who will then forward such
requests to translators; this principle is also applicable to add-ons
themselves, as authors are responsible for working with translators
regarding add-on localization based on feedback from users).

Therefore, before thinking about persistent storage, please:
1. Tell us about the app you are trying to localize through this add-
on.
2. Contact app developers about localization issues.
Although I recommend doing both, please do the second item as soon as
possible.
This solution was already considered and ruled out as impractical.
Otherwise I'd not start working on this add-on.

People who need my add-on are people who successfully learned to read
their native language but have some learning disability preventing them
from learning to read English. They get stuck when they need to use
non-localized professional software to work in their professions.

The number of such people, needing to use each software application, is
too small to justify corporate investment in localizing the software in
question.

The software applications in question are proprietary (it is not a
problem to localize Free Software) and I checked with a lawyer
specializing in intellectual property, and he confirmed that my
approach is legal if certain conditions are met.

So the NVDA way is a cost-effective solution to the above problem.
After actually implementing the add-on, we'll see if it really solves
those people's problem.


Cheers,
Joseph

Regards,
--- Omer Zak


-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <
nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 10:22 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information
Outside Your Add-on

Hello James,

What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions
extensionPoints.Filter) which translates a string before speaking it
or displaying it in Braille. The filter would use the same database
as my add-on.

Current status:

1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak



On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used
for
simple INI-style, key/value pairs of data. Creating your own
config
files means that resetting or backing up the core NVDA config has
no
impact on your add-on. If you need to store anything more
advanced,
such as data structures, JSON and/or pickling is the way to go.
Otherwise, try to integrate as tightly as possible into NVDA
itself.

@Omer, you can take a look at Speech History and many other add-
ons,
particularly those which add an NVDA settings panel or dialog, for
examples of storing config data. If this doesn't meet your needs,
feel free to tell us a bit more about your use case and we can
recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From
my
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Develo
pment%20Guide
)
has a section about Storing and Using Persistent Information
Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I
could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent information, and whose techniques I could study?
--
My Commodore 64 is suffering from slowness and insufficiency of memory;
and its display device is grievously short of pixels. Can anyone help?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with
which I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html


 

Hi,
Okay, that justifies the need for the add-on.
Once the add-on is created, do let us know so someone can review it (at both the usability and source code levels).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 11:20 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information Outside Your Add-on

Hello Joseph,
See my comments below.

On Tue, 2020-09-08 at 10:42 -0700, Joseph Lee wrote:
Hi,
Okay, I raise serious issues with this proposal:
1. Please be careful about word choice: when folks hear the word
"abuse" in context of software, it can mean bad activities such as
tampering with security. I sort of can tell that English might not be
your first language, which is perfectly understandable. However,
because this forum is public with a publicly viewable archive, it
would be better to think about the words used when describing what the
software should do. Note that this issue is subjective and is not that
serious unless your motives say otherwise.
I used the word 'abuse' in the meaning of 'use for a different purpose than originally intended'.
You confirmed the 'a different purpose than originally intended' part below.
Thanks for your warning, and I'll try to be more careful in my word choice in the future.

2. Persistent storage: JSON might be best suited for this, as it
allows human-readable representation of a dictionary.
When and if the dictionary has 10^5 or more strings, it will be more efficient to use a database with a cache Dict in memory.
I do plan to use JSON files for the time being and switch later to SQLite if so warranted. However they too need to be placed in a directory in the user's hard disk.

3. A very serious issue on localization and intent: app localization
is NOT an add-on domain. An add-on is meant to improve usage of a
feature or a program by using strategies to help users use a feature
or an app. An add-on (in this case, an app module) is NOT AN EFFECTIVE
route for app localization - that's a completely different activity.
The best people to contact regarding app localization is the people
who actually produced the program in question (this is applicable even
to NVDA, as the people who should be contacted about NVDA localization
is NV Access staff, who will then forward such requests to
translators; this principle is also applicable to add-ons themselves,
as authors are responsible for working with translators regarding
add-on localization based on feedback from users).

Therefore, before thinking about persistent storage, please:
1. Tell us about the app you are trying to localize through this add-
on.
2. Contact app developers about localization issues.
Although I recommend doing both, please do the second item as soon as
possible.
This solution was already considered and ruled out as impractical.
Otherwise I'd not start working on this add-on.

People who need my add-on are people who successfully learned to read their native language but have some learning disability preventing them from learning to read English. They get stuck when they need to use non-localized professional software to work in their professions.

The number of such people, needing to use each software application, is too small to justify corporate investment in localizing the software in question.

The software applications in question are proprietary (it is not a problem to localize Free Software) and I checked with a lawyer specializing in intellectual property, and he confirmed that my approach is legal if certain conditions are met.

So the NVDA way is a cost-effective solution to the above problem.
After actually implementing the add-on, we'll see if it really solves those people's problem.


Cheers,
Joseph

Regards,
--- Omer Zak


-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <
nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 10:22 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information
Outside Your Add-on

Hello James,

What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions
extensionPoints.Filter) which translates a string before speaking it
or displaying it in Braille. The filter would use the same database as
my add-on.

Current status:

1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak



On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used
for simple INI-style, key/value pairs of data. Creating your own
config files means that resetting or backing up the core NVDA config
has no impact on your add-on. If you need to store anything more
advanced, such as data structures, JSON and/or pickling is the way
to go.
Otherwise, try to integrate as tightly as possible into NVDA itself.

@Omer, you can take a look at Speech History and many other add-
ons, particularly those which add an NVDA settings panel or dialog,
for examples of storing config data. If this doesn't meet your
needs, feel free to tell us a bit more about your use case and we
can recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From
my part, for example reportPassword, which is a super-simple
add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Deve
lo
pment%20Guide
)
has a section about Storing and Using Persistent Information
Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I
could consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent information, and whose techniques I could study?
--
My Commodore 64 is suffering from slowness and insufficiency of memory; and its display device is grievously short of pixels. Can anyone help?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html


Rui Fontes
 

Why not using the application dictionary add-on?


Rui Fontes


Às 19:26 de 08/09/2020, Joseph Lee escreveu:

Hi,
Okay, that justifies the need for the add-on.
Once the add-on is created, do let us know so someone can review it (at both the usability and source code levels).
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 11:20 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information Outside Your Add-on

Hello Joseph,
See my comments below.

On Tue, 2020-09-08 at 10:42 -0700, Joseph Lee wrote:
Hi,
Okay, I raise serious issues with this proposal:
1. Please be careful about word choice: when folks hear the word
"abuse" in context of software, it can mean bad activities such as
tampering with security. I sort of can tell that English might not be
your first language, which is perfectly understandable. However,
because this forum is public with a publicly viewable archive, it
would be better to think about the words used when describing what the
software should do. Note that this issue is subjective and is not that
serious unless your motives say otherwise.
I used the word 'abuse' in the meaning of 'use for a different purpose than originally intended'.
You confirmed the 'a different purpose than originally intended' part below.
Thanks for your warning, and I'll try to be more careful in my word choice in the future.

2. Persistent storage: JSON might be best suited for this, as it
allows human-readable representation of a dictionary.
When and if the dictionary has 10^5 or more strings, it will be more efficient to use a database with a cache Dict in memory.
I do plan to use JSON files for the time being and switch later to SQLite if so warranted. However they too need to be placed in a directory in the user's hard disk.

3. A very serious issue on localization and intent: app localization
is NOT an add-on domain. An add-on is meant to improve usage of a
feature or a program by using strategies to help users use a feature
or an app. An add-on (in this case, an app module) is NOT AN EFFECTIVE
route for app localization - that's a completely different activity.
The best people to contact regarding app localization is the people
who actually produced the program in question (this is applicable even
to NVDA, as the people who should be contacted about NVDA localization
is NV Access staff, who will then forward such requests to
translators; this principle is also applicable to add-ons themselves,
as authors are responsible for working with translators regarding
add-on localization based on feedback from users).

Therefore, before thinking about persistent storage, please:
1. Tell us about the app you are trying to localize through this add-
on.
2. Contact app developers about localization issues.
Although I recommend doing both, please do the second item as soon as
possible.
This solution was already considered and ruled out as impractical.
Otherwise I'd not start working on this add-on.

People who need my add-on are people who successfully learned to read their native language but have some learning disability preventing them from learning to read English. They get stuck when they need to use non-localized professional software to work in their professions.

The number of such people, needing to use each software application, is too small to justify corporate investment in localizing the software in question.

The software applications in question are proprietary (it is not a problem to localize Free Software) and I checked with a lawyer specializing in intellectual property, and he confirmed that my approach is legal if certain conditions are met.

So the NVDA way is a cost-effective solution to the above problem.
After actually implementing the add-on, we'll see if it really solves those people's problem.


Cheers,
Joseph
Regards,
--- Omer Zak


-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <
nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 10:22 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information
Outside Your Add-on

Hello James,

What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions
extensionPoints.Filter) which translates a string before speaking it
or displaying it in Braille. The filter would use the same database as
my add-on.

Current status:

1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak



On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used
for simple INI-style, key/value pairs of data. Creating your own
config files means that resetting or backing up the core NVDA config
has no impact on your add-on. If you need to store anything more
advanced, such as data structures, JSON and/or pickling is the way
to go.
Otherwise, try to integrate as tightly as possible into NVDA itself.

@Omer, you can take a look at Speech History and many other add-
ons, particularly those which add an NVDA settings panel or dialog,
for examples of storing config data. If this doesn't meet your
needs, feel free to tell us a bit more about your use case and we
can recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From
my part, for example reportPassword, which is a super-simple
add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Deve
lo
pment%20Guide
)
has a section about Storing and Using Persistent Information
Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I
could consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent information, and whose techniques I could study?
--
My Commodore 64 is suffering from slowness and insufficiency of memory; and its display device is grievously short of pixels. Can anyone help?
My own blog is at https://tddpirate.zak.co.il/

My opinions, as expressed in this E-mail message, are mine alone.
They do not represent the official policy of any organization with which I may be affiliated in any way.
WARNING TO SPAMMERS: at https://www.zak.co.il/spamwarning.html







Locutor Antonio Cezar
 

I'm sorry if I did not understand what exactly the purpose of the Add-On that friend is creating, but here in Brazil some people use the AppDictionary Add-On to translate applications because the main function of AppDictionary is to create a dictionary for each application it is accessed as NVDA screen reader... Thanks.



Locutor Antonio Cezar

Em 08/09/2020 15:20, Omer Zak escreveu:

Hello Joseph,
See my comments below.

On Tue, 2020-09-08 at 10:42 -0700, Joseph Lee wrote:
Hi,
Okay, I raise serious issues with this proposal:
1. Please be careful about word choice: when folks hear the word
"abuse" in context of software, it can mean bad activities such as
tampering with security. I sort of can tell that English might not be
your first language, which is perfectly understandable. However,
because this forum is public with a publicly viewable archive, it
would be better to think about the words used when describing what
the software should do. Note that this issue is subjective and is not
that serious unless your motives say otherwise.
I used the word 'abuse' in the meaning of 'use for a different purpose
than originally intended'.
You confirmed the 'a different purpose than originally intended' part
below.
Thanks for your warning, and I'll try to be more careful in my word
choice in the future.

2. Persistent storage: JSON might be best suited for this, as it
allows human-readable representation of a dictionary.
When and if the dictionary has 10^5 or more strings, it will be more
efficient to use a database with a cache Dict in memory.
I do plan to use JSON files for the time being and switch later to
SQLite if so warranted. However they too need to be placed in a
directory in the user's hard disk.

3. A very serious issue on localization and intent: app localization
is NOT an add-on domain. An add-on is meant to improve usage of a
feature or a program by using strategies to help users use a feature
or an app. An add-on (in this case, an app module) is NOT AN
EFFECTIVE route for app localization - that's a completely different
activity. The best people to contact regarding app localization is
the people who actually produced the program in question (this is
applicable even to NVDA, as the people who should be contacted about
NVDA localization is NV Access staff, who will then forward such
requests to translators; this principle is also applicable to add-ons 
themselves, as authors are responsible for working with translators
regarding add-on localization based on feedback from users).

Therefore, before thinking about persistent storage, please:
1. Tell us about the app you are trying to localize through this add-
on.
2. Contact app developers about localization issues.
Although I recommend doing both, please do the second item as soon as
possible.
This solution was already considered and ruled out as impractical.
Otherwise I'd not start working on this add-on.

People who need my add-on are people who successfully learned to read
their native language but have some learning disability preventing them
from learning to read English. They get stuck when they need to use
non-localized professional software to work in their professions.

The number of such people, needing to use each software application, is
too small to justify corporate investment in localizing the software in
question.

The software applications in question are proprietary (it is not a
problem to localize Free Software) and I checked with a lawyer
specializing in intellectual property, and he confirmed that my
approach is legal if certain conditions are met.

So the NVDA way is a cost-effective solution to the above problem.
After actually implementing the add-on, we'll see if it really solves
those people's problem.


Cheers,
Joseph

Regards,
--- Omer Zak


-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <
nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 10:22 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information
Outside Your Add-on

Hello James,

What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions
extensionPoints.Filter) which translates a string before speaking it
or displaying it in Braille. The filter would use the same database
as my add-on.

Current status:

1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak



On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
 > There are many add-ons storing configuration in .ini files

Please don't encourage this.  The NVDA config file should be used
for 
simple INI-style, key/value pairs of data.  Creating your own
config 
files means that resetting or backing up the core NVDA config has
no 
impact on your add-on.  If you need to store anything more
advanced, 
such as data structures, JSON and/or pickling is the way to go.
Otherwise, try to integrate as tightly as possible into NVDA
itself.

@Omer, you can take a look at Speech History and many other add-
ons, 
particularly those which add an NVDA settings panel or dialog, for 
examples of storing config data.  If this doesn't meet your needs, 
feel free to tell us a bit more about your use case and we can 
recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From
my 
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store 
persistent information.
I joined this mailing list few days ago and I apologize if the 
following is violating any mailing list ethics.

The NVDA Add-on Development Guide ( 
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Develo
pment%20Guide
)
has a section about Storing and Using Persistent Information 
Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I
could 
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using 
persistent information, and whose techniques I could study?


Robert Hänggi
 

This is obviously not an add-on for visually impaired people.
It merely needs NVDA as a vehicle to access focus and associated tooltips etc.
Thus, integrating closely with core doesn't make sense.
The proper storage place is probably somewhere in the appdata folder,
e.g. local or roaming, especially if it is a sql database.
On the other hand, if it should be human readable/editable, it should
go under documents.
The add-on needs its own mechanism to backup the data or migrate it to
other computers/users/storage media.
Robert

On 08/09/2020, Locutor Antonio Cezar <antoniocezarlocutor@...> wrote:
I'm sorry if I did not understand what exactly the purpose of the Add-On
that friend is creating, but here in Brazil some people use the
AppDictionary Add-On to translate applications because the main function
of AppDictionary is to create a dictionary for each application it is
accessed as NVDA screen reader... Thanks.


------------------------------------------------------------------------


Locutor Antonio Cezar

Em 08/09/2020 15:20, Omer Zak escreveu:
Hello Joseph,
See my comments below.

On Tue, 2020-09-08 at 10:42 -0700, Joseph Lee wrote:
Hi,
Okay, I raise serious issues with this proposal:
1. Please be careful about word choice: when folks hear the word
"abuse" in context of software, it can mean bad activities such as
tampering with security. I sort of can tell that English might not be
your first language, which is perfectly understandable. However,
because this forum is public with a publicly viewable archive, it
would be better to think about the words used when describing what
the software should do. Note that this issue is subjective and is not
that serious unless your motives say otherwise.
I used the word 'abuse' in the meaning of 'use for a different purpose
than originally intended'.
You confirmed the 'a different purpose than originally intended' part
below.
Thanks for your warning, and I'll try to be more careful in my word
choice in the future.

2. Persistent storage: JSON might be best suited for this, as it
allows human-readable representation of a dictionary.
When and if the dictionary has 10^5 or more strings, it will be more
efficient to use a database with a cache Dict in memory.
I do plan to use JSON files for the time being and switch later to
SQLite if so warranted. However they too need to be placed in a
directory in the user's hard disk.

3. A very serious issue on localization and intent: app localization
is NOT an add-on domain. An add-on is meant to improve usage of a
feature or a program by using strategies to help users use a feature
or an app. An add-on (in this case, an app module) is NOT AN
EFFECTIVE route for app localization - that's a completely different
activity. The best people to contact regarding app localization is
the people who actually produced the program in question (this is
applicable even to NVDA, as the people who should be contacted about
NVDA localization is NV Access staff, who will then forward such
requests to translators; this principle is also applicable to add-ons
themselves, as authors are responsible for working with translators
regarding add-on localization based on feedback from users).

Therefore, before thinking about persistent storage, please:
1. Tell us about the app you are trying to localize through this add-
on.
2. Contact app developers about localization issues.
Although I recommend doing both, please do the second item as soon as
possible.
This solution was already considered and ruled out as impractical.
Otherwise I'd not start working on this add-on.

People who need my add-on are people who successfully learned to read
their native language but have some learning disability preventing them
from learning to read English. They get stuck when they need to use
non-localized professional software to work in their professions.

The number of such people, needing to use each software application, is
too small to justify corporate investment in localizing the software in
question.

The software applications in question are proprietary (it is not a
problem to localize Free Software) and I checked with a lawyer
specializing in intellectual property, and he confirmed that my
approach is legal if certain conditions are met.

So the NVDA way is a cost-effective solution to the above problem.
After actually implementing the add-on, we'll see if it really solves
those people's problem.


Cheers,
Joseph
Regards,
--- Omer Zak


-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <
nvda-addons@nvda-addons.groups.io> On Behalf Of Omer Zak
Sent: Tuesday, September 8, 2020 10:22 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Storing and Using Persistent Information
Outside Your Add-on

Hello James,

What I actually need is a convention for specifying the default
location for a SQLite database (a single file) storing information
needed by my add-on. My add-on will have a configuration dialog for
overriding the above default.

My use-case is to abuse NVDA to localize software for sighted (and
hard-of-sight) speakers of a language, for which the software was not
originally localized. It is relevant when the user cannot have the
software properly localized due to various reasons.

The idea is that when a sighted user hovers over a string using a
mouse, the add-on would display its translation in a small window.

Of course, such an add-on will need a database of translations for
strings used by such a non-localized software.

Accessibility note:

The above add-on would not be accessible to blind people, who use
speech or Braille. The accessible solution for them would be to use a
filter (NVDA Add-on Development Guide mentions
extensionPoints.Filter) which translates a string before speaking it
or displaying it in Braille. The filter would use the same database
as my add-on.

Current status:

1. Display of a translation for strings being hovered over - is
implemented.
2. Database of translations - work in progress.
3. Configuration dialog - TODO
4. Installation file - TODO

Regards,
--- Omer Zak



On Tue, 2020-09-08 at 11:46 -0500, James Scholes wrote:
> There are many add-ons storing configuration in .ini files

Please don't encourage this. The NVDA config file should be used
for
simple INI-style, key/value pairs of data. Creating your own
config
files means that resetting or backing up the core NVDA config has
no
impact on your add-on. If you need to store anything more
advanced,
such as data structures, JSON and/or pickling is the way to go.
Otherwise, try to integrate as tightly as possible into NVDA
itself.

@Omer, you can take a look at Speech History and many other add-
ons,
particularly those which add an NVDA settings panel or dialog, for
examples of storing config data. If this doesn't meet your needs,
feel free to tell us a bit more about your use case and we can
recommend something specific.

Regards,

James Scholes

On 08/09/2020 at 11:40 am, Noelia Ruiz wrote:
Hello. From my part:

An example of storing information in Pickle and text files,
placeMarkers:

https://github.com/nvdaes/placemarkers


There are many add-ons storing configuration in .ini files. From
my
part, for example reportPassword, which is a super-simple add-on:

https://github.com/nvdaes/reportPasswords
Cheers

2020-09-08 16:22 GMT+02:00, Omer Zak <w1@...>:
I am developing a NVDA add-on which needs to access and store
persistent information.
I joined this mailing list few days ago and I apologize if the
following is violating any mailing list ethics.

The NVDA Add-on Development Guide (
https://github.com/nvdaaddons/devguide/wiki/NVDA%20Add-on%20Develo
pment%20Guide
)
has a section about Storing and Using Persistent Information
Outside Your Add-on.

However, this section has only the text "Coming Soon".
And I would like to have the information earlier than that.

Is there any alternative source for this information that I
could
consult?
Is there any existing add-on in
https://addons.nvda-project.org/index.en.html which is using
persistent information, and whose techniques I could study?