Date   

Re: Quick Notetaker, a new NVDA add-on, request for review

Travis Roth
 

Hi,

And synchronization that needs servers, supports multiple platforms, etc., is a good use case for a stand alone not screen reader dependent add-on. NVDA doesn’t run on my iPhone.

Nothing against this add-on it has its place, etc. But keep expectations reasonable. I agree with another poster, asking for synchronization, etc., is a big and possibly unreasonable ask.

 

 

From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> On Behalf Of Christo de Klerk
Sent: Wednesday, October 6, 2021 11:51 AM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] Quick Notetaker, a new NVDA add-on, request for review

 

Hello

 

The Windows Sticky Notes app synchronises across devices linked to the same MS account. So, when I add, edit or delete notes on, say, my desktop, they get automatically synced to my laptop so that I have them handy when I take the laptop somewhere else with me. This is a really handy feature.

 

Kind regards

 

Christo

 

 

On 2021/10/06 06:27pm, mohammad suliman wrote:

Thanks Akash. Can you please give an example of an online service where the notes can be synced with? And what is the use case you are aiming for?

 

On Sat, 2 Oct 2021 at 19:53, Akash Kakkar <akash.diverse@...> wrote:

would be good if the notes will get synced to some online service

On 02/10/2021, Rowen Cary <manchen_0528@...> wrote:
> I tested the latest release and there seems to be no problem.
>
>
>
>
>
>




 


Re: Quick Notetaker, a new NVDA add-on, request for review

Timothy Wynn
 

On Sat, Oct 2, 2021 at 01:13 PM, Christo de Klerk wrote:

Syncing between Windows devices would be a really useful feature. Up until now I have been using Sticky Notes which does sync, but QuickNotetaker has so much to offer that I would prefer to use that instead, but I really would need the syncing feature.

Could you not change the default document directory to a location in OneDrive, Dropbox, Google Drive, etc? All these services have File Explorer integration so theoretically, you just need to tell the add-on to save the notes in a different location. Expecting an add-on developer to either support cloud integration or host a sync service seems rather unreasonable.

Timothy


Re: Is there a way to ignore certain events with an app module?

Muhammad Aamir Shafique
 

Hi Alberto!

Thank you

On 10/6/2021 11:01 PM, Alberto Buffolino wrote:
Muhammad Aamir Shafique, il 06/10/2021 18.41, ha scritto:
With the help of the new event tracker add-on, I
see that NVDA is being flooded with focusEntered and nameChange events, causing NVDA to freeze and respond very slow. is there a way to just drop them somehow?
Alberto:
Hi Muhammad,
yes, in my knowledge, you can overlay class for the object raises event, and then re-define the event to do nothing (pass).
See ACLogStaticText here for example:
https://raw.githubusercontent.com/ABuffEr/acLog/master/addon/appModules/aclog.py
Hth.
Alberto




Re: Is there a way to ignore certain events with an app module?

Alberto Buffolino
 

Muhammad Aamir Shafique, il 06/10/2021 18.41, ha scritto:
With the help of the new event tracker add-on, I
see that NVDA is being flooded with focusEntered and nameChange events, causing NVDA to freeze and respond very slow. is there a way to just drop them somehow?
Alberto:
Hi Muhammad,
yes, in my knowledge, you can overlay class for the object raises event, and then re-define the event to do nothing (pass).
See ACLogStaticText here for example:
https://raw.githubusercontent.com/ABuffEr/acLog/master/addon/appModules/aclog.py
Hth.
Alberto


Re: requesting review: Spellcheck

José Manuel Delicado Alcolea
 

Hi,

Although they are now optional, I have performed a basic review for this add-on. Here are the results:

* License and copyright: pass (with comments).

* Security: pass (with comments).

* Documentation: pass.

* User experience: pass (with comments).

Comments:

* This add-on is not helpful on secure screens. In the GlobalPlugin constructor, do the following before calling any other instruction to prevent possible attacks:

if globalVars.appArgs.secure:

    return

* The add-on code includes all required copyright headers, but not all external libraries may be compatible with GPL. Excluding Enchant and modules taken from the Python standard library, these are the licenses in use:

httpx, httpcore, idna, cached_property: bsd
RFC3986: Apache
Sniffio: Apache, MIT
Certifi: MPL 2.0
H11, Anyio, charset-normalizer: MIT

MIT license is not a problem, as allows re-licensing the product. Has anyone more information on Apache, BSD and MPL licenses?

* The control+r and control+c gestures are intended to be changed from the Input Gestures dialog, but the dialog can't be opened while the virtual menu is being used. Note that input gestures for an object can only be changed when such object has focus.

* The add-on code is not compatible with controlTypes refactor, so future work will be required once NVDA 2022.1 beta 1 is released.

Regards.


El 16/09/2021 a las 19:45, Fawaz Abdul rahman escribió:
Hello,
We are thrilled to announce a new add-on for the NVDA screen reader.
From readme:
"The purpose of the addon is to find and correct the spelling errors quickly in a written text; additionally, you can create a list of words called personal dictionary; the words in which will be added to the suggestions list of the misspelled words."
The addon was developed by Musharraf Omar and me under his guidance.
download the addon from:
the repo at:
Looking forward to hearing your suggestions and feedback.
best regards
--

José Manuel Delicado Alcolea
Equipo de gestión web y desarrollo



Asociación Comunidad Hispanohablante de NVDA
- Tel.: (+34) 910 05 33 25 ext. 2001
- jm.delicado@...
- www.NVDA.es
- @nvda_es

***Este mensaje y sus adjuntos están dirigidos a su destinatario y pueden contener información exclusiva o confidencial. La utilización, copia o divulgación de los mismos por parte de alguien diferente a dicho destinatario no está permitida sin autorización. Si ha recibido este mensaje por error, le rogamos que lo comunique por esta misma vía y seguidamente lo destruya.***


Re: Quick Notetaker, a new NVDA add-on, request for review

Christo de Klerk
 

Hello

The Windows Sticky Notes app synchronises across devices linked to the same MS account. So, when I add, edit or delete notes on, say, my desktop, they get automatically synced to my laptop so that I have them handy when I take the laptop somewhere else with me. This is a really handy feature.

Kind regards

Christo


On 2021/10/06 06:27pm, mohammad suliman wrote:
Thanks Akash. Can you please give an example of an online service where the notes can be synced with? And what is the use case you are aiming for?

On Sat, 2 Oct 2021 at 19:53, Akash Kakkar <akash.diverse@...> wrote:
would be good if the notes will get synced to some online service

On 02/10/2021, Rowen Cary <manchen_0528@...> wrote:
> I tested the latest release and there seems to be no problem.
>
>
>
>
>
>







Re: Quick Notetaker, a new NVDA add-on, request for review

Cyrille
 

Yes, even with Python 3, you need the encoding line in your file if this file contains non ascii character (even just in comments).
It's needed for gettext, not for Python of course.

Cyrille
De : "mohammad suliman"
A : nvda-addons@nvda-addons.groups.io
Envoyé: mercredi 6 Octobre 2021 18:22
Objet : Re: [nvda-addons] Quick Notetaker, a new NVDA add-on, request for review
 
Hi Rowen,
 
Thanks for the heads up! In fact, I am not able to replicate the issue on my machine, not sure whether adding an encoding line to the python files of the add-on will correct the issue. I haven't bothered to add such lines because in Python 3 the default encoding is utf8. Maybe gettext needs those lines to be added to function correctly?
I am attaching the pot file that I have created in case you are still interested.
 
Thanks,
Mohammad

 
On Tue, 5 Oct 2021 at 13:55, Rui Fontes <rui.fontes@...> wrote:

Check if the document is in UTF-8...

 

Rui Fontes

 

Às 01:47 de 05/10/2021, Rowen Cary escreveu:

I tried to translate it into Chinese, but I saw an error when generating the pot template, can you see it? It seems that the original encoding is not specified: xgettext: Non-ASCII string at addon\globalPlugins\quickNotetaker\helpers.py:134.

 

 


Is there a way to ignore certain events with an app module?

Muhammad Aamir Shafique
 

Hi all, I'm using an app which has a standard tree-view but is very, very laggy with NVDA. With the help of the new event tracker add-on, I see that NVDA is being flooded with focusEntered and nameChange events, causing NVDA to freeze and respond very slow. is there a way to just drop them somehow? Thanks for any help


Re: Quick Notetaker, a new NVDA add-on, request for review

mohammad suliman
 

Thanks Akash. Can you please give an example of an online service where the notes can be synced with? And what is the use case you are aiming for?


On Sat, 2 Oct 2021 at 19:53, Akash Kakkar <akash.diverse@...> wrote:
would be good if the notes will get synced to some online service

On 02/10/2021, Rowen Cary <manchen_0528@...> wrote:
> I tested the latest release and there seems to be no problem.
>
>
>
>
>
>






Re: Quick Notetaker, a new NVDA add-on, request for review

mohammad suliman
 

Thanks everyone for the suggestions, we will definitely take them to consideration for next versions.


On Sat, 2 Oct 2021 at 20:13, Christo de Klerk <christodeklerk@...> wrote:
Syncing between Windows devices would be a really useful feature. Up until now I have been using Sticky Notes which does sync, but QuickNotetaker has so much to offer that I would prefer to use that instead, but I really would need the syncing feature.

An excellent piece of work!

Kind regards

Christo


On 2021/10/02 06:53pm, Akash Kakkar wrote:
would be good if the notes will get synced to some online service

On 02/10/2021, Rowen Cary <manchen_0528@...> wrote:
I tested the latest release and there seems to be no problem.









Re: Quick Notetaker, a new NVDA add-on, request for review

mohammad suliman
 

Hi Rowen,

Thanks for the heads up! In fact, I am not able to replicate the issue on my machine, not sure whether adding an encoding line to the python files of the add-on will correct the issue. I haven't bothered to add such lines because in Python 3 the default encoding is utf8. Maybe gettext needs those lines to be added to function correctly?
I am attaching the pot file that I have created in case you are still interested.

Thanks,
Mohammad

On Tue, 5 Oct 2021 at 13:55, Rui Fontes <rui.fontes@...> wrote:

Check if the document is in UTF-8...


Rui Fontes


Às 01:47 de 05/10/2021, Rowen Cary escreveu:

I tried to translate it into Chinese, but I saw an error when generating the pot template, can you see it? It seems that the original encoding is not specified: xgettext: Non-ASCII string at addon\globalPlugins\quickNotetaker\helpers.py:134.


Re: Are there any specific caveats for add-ons documentation on the website?

Cyrille
 

Generally,to test if a syntax is OK, the following 3 html files should be checked:
* English add-on's doc generated by the add-on scons command from the readme.md file
* English website's doc generated from the .mdwn 
* Translated website's doc generated from the mdwn and the .po file
Indeed, there may be slight differences in how the tools generate the html files.
I do not think that the translated add-on's doc needs to be checked since it is generated the same way as the website's translated doc.

I would also like to add some points and confirm other ones:

1. The reference style for links is nicer to read in the source (md) file but it is not mandatory

2. The reference style for too long links does not work (ikiwiki limitation). E.g: use the embedded link instead: "Click [here](http://www.here.com).". I do not know the max length for links allowed to be referenced; but you can see example of too long links in the Windows Magnifier (winMag) documentation.

3. Embedded lists
To be avoided when possible: risk of bad formatting that may lead to sublist items not split for translation.

Also, the following construct (cf winMag documentation) is not totally satisfying even if it is the best compromise:

===== beginning of markdown ======

Following is a list:

* A big item 1
  
    * sub-item 1
    * sub-item 2
  
  Another line still belonging to item 1

* Item 2

===== end of markdown ====== 

Other tries on this structure lead to sub-items not split.

HTH

Cyrille
 
De : "Noelia Ruiz"
A : nvda-addons@nvda-addons.groups.io
Envoyé: mercredi 6 Octobre 2021 12:26
Objet : Re: [nvda-addons] Are there any specific caveats for add-ons documentation on the website?
 
Great! Always happy to read your ideas. I suppose it's OK.

2021-10-06 12:20 GMT+02:00, Alberto Buffolino :
> Noelia Ruiz, il 06/10/2021 06.32, ha scritto:
>> 4. Use "reference" style for links, that is, include the corresponding
>> urls at the botom of the file, with a blank line between urls (not sure if
>> it"s needed, but maybe, and place a blank line at the bottom).
> Alberto:
> Hi Noelia and all,
> about reference style, in last years I always saw numeric reference, like:
> [stable version][1]
> but recently I'm adopting more often (due to my blog) a more confortable
> word/sequence reference, like:
> [download stable][stable]
> I think it's ok for translation system, so I report it here 🙂
> Alberto
>
>
>
>
>
>




 


Re: Are there any specific caveats for add-ons documentation on the website?

Noelia Ruiz
 

Great! Always happy to read your ideas. I suppose it's OK.

2021-10-06 12:20 GMT+02:00, Alberto Buffolino <a.buffolino@gmail.com>:

Noelia Ruiz, il 06/10/2021 06.32, ha scritto:
4. Use "reference" style for links, that is, include the corresponding
urls at the botom of the file, with a blank line between urls (not sure if
it"s needed, but maybe, and place a blank line at the bottom).
Alberto:
Hi Noelia and all,
about reference style, in last years I always saw numeric reference, like:
[stable version][1]
but recently I'm adopting more often (due to my blog) a more confortable
word/sequence reference, like:
[download stable][stable]
I think it's ok for translation system, so I report it here 🙂
Alberto






Re: Are there any specific caveats for add-ons documentation on the website?

Alberto Buffolino
 

Noelia Ruiz, il 06/10/2021 06.32, ha scritto:
4. Use "reference" style for links, that is, include the corresponding urls at the botom of the file, with a blank line between urls (not sure if it"s needed, but maybe, and place a blank line at the bottom).
Alberto:
Hi Noelia and all,
about reference style, in last years I always saw numeric reference, like:
[stable version][1]
but recently I'm adopting more often (due to my blog) a more confortable word/sequence reference, like:
[download stable][stable]
I think it's ok for translation system, so I report it here 🙂
Alberto


Re: Are there any specific caveats for add-ons documentation on the website?

Noelia Ruiz
 

And something that I wanted to mention: name the markdown file exactly
as the corresponding repo, needed for the translation system.


2021-10-06 10:40 GMT+02:00, José Manuel Delicado Alcolea via groups.io
<jm.delicado=nvda.es@groups.io>:

Hi,

Also, pay attention to nested lists. Put a blank line before the first
sub-item and after the last one, and use four spaces to indent.

Regards.


El 06/10/2021 a las 6:32, Noelia Ruiz escribió:
Hello: I"m not a translator, so I cannot provide the most reliable and
complete answer. But I"ll start this thread saying what I try to do
(despite mistakes):

1. Ensure that your document has the .mdwn extension in Assembla, though
the extension on Github is .md.
2. Replace the heading level 1 úhich starts by a square symbol with the
meta title tag, puting the title between double quotes (see a .mdwn file
for examples).
3. Use asterisks followedb by space, not dash, for lists. Dashes are
allowed on Github and on the website, but just in English. When the
documentation is converted to .po files, using dashes doesn"t split the
list in the desired items.
4. Use "reference" style for links, that is, include the corresponding
urls at the botom of the file, with a blank line between urls (not sure if
it"s needed, but maybe, and place a blank line at the bottom).
See examples. On Github we can include URLS between parentheses, but on
the website we"ve always used reference style)..
5. Place the tags corresponding to the sections where the adddocumentation
should appear before the references to the links, just before, with blank
lines after the main content of the documentation and dev stable or dev
tags, and a blank line after that and before the urls.
6. Try to use short paragraphs and lists, and headings of level 2 or 3 for
a good structure and understandable documentation, avoiding a superlong
or detailed changelog, since it should be translated and it"s better to
focus in important things. This is just an additional recommendation and
my own opinion.
Kind regards
Enviado desde mi iPhone

El 5 oct 2021, a las 17:05, Lukasz Golonka via
groups.io<lukasz.golonka=mailbox.org@groups.io> escribió:

Dear all,

From time to time there are discussions here about add-ons
documentation
in markdown being rendered correctly on GitHub but wrongly after it is
committed into SVN and shown on the add-ons website. Until now I had no
access to Assembla and someone else had to update documentation of my
add-ons of my behalf, but since I can do it myself now I would like to
ask if there are any specific points which should be taken into account
when using markdown so that it renders correctly on the add-ons web
page.

--
Regards
Lukasz







--

José Manuel Delicado Alcolea
Equipo de gestión web y desarrollo
Experto certificado en NVDA <https://certification.nvaccess.org>

Logotipo de la comunidad hispanohablante de NVDA
Asociación Comunidad Hispanohablante de NVDA
- Tel.: (+34) 910 05 33 25 ext. 2001 <tel:+34910053325,2001>
- jm.delicado@nvda.es
- www.NVDA.es <https://nvda.es>
- @nvda_es <https://twitter.com/nvda_es>

***Este mensaje y sus adjuntos están dirigidos a su destinatario y
pueden contener información exclusiva o confidencial. La utilización,
copia o divulgación de los mismos por parte de alguien diferente a dicho
destinatario no está permitida sin autorización. Si ha recibido este
mensaje por error, le rogamos que lo comunique por esta misma vía y
seguidamente lo destruya.***







Re: Are there any specific caveats for add-ons documentation on the website?

José Manuel Delicado Alcolea
 

Hi,

Also, pay attention to nested lists. Put a blank line before the first sub-item and after the last one, and use four spaces to indent.

Regards.


El 06/10/2021 a las 6:32, Noelia Ruiz escribió:
Hello: I"m not a translator,  so I cannot provide the most reliable and complete answer. But I"ll start this thread saying what I try to do (despite mistakes):

1. Ensure that your document has the .mdwn extension in Assembla, though the extension on Github is .md.
2. Replace the heading level 1 úhich starts by a square symbol with the meta title tag, puting the title between double quotes (see a .mdwn file for examples).
3. Use asterisks followedb by space,  not dash, for lists. Dashes are allowed on Github and on the website, but just in English. When the documentation is converted to .po files,  using dashes doesn"t split the list in the desired items.
4. Use "reference" style for links, that is,  include the corresponding urls at the botom of the file, with a blank line between urls (not sure if it"s needed, but maybe, and place a blank line at the bottom).
See examples. On Github we can include URLS between parentheses, but on the website we"ve always used reference style)..
5. Place the tags corresponding to the sections where the adddocumentation should appear before the references to the links, just before, with blank lines after the main content of the documentation and dev stable or dev tags, and a blank line after that and before the urls.
6. Try to use short paragraphs and lists, and headings of level 2 or 3 for a good structure and understandable documentation,  avoiding a superlong or detailed changelog, since it should be translated and it"s better to focus in important things. This is just an additional recommendation and my own opinion.
Kind regards
Enviado desde mi iPhone

El 5 oct 2021, a las 17:05, Lukasz Golonka via groups.io <lukasz.golonka@...> escribió:

Dear all,

From time to time there are discussions here about add-ons documentation
in markdown being rendered correctly on GitHub but wrongly after it is
committed into SVN and shown on the add-ons website. Until now I had no
access to Assembla and someone else had to update documentation of my
add-ons of my behalf, but since I  can do it myself now I would like to
ask if there are any specific points which should be taken into account
when using markdown so that it renders correctly on the add-ons web page.

-- 
Regards
Lukasz










--

José Manuel Delicado Alcolea
Equipo de gestión web y desarrollo



Asociación Comunidad Hispanohablante de NVDA
- Tel.: (+34) 910 05 33 25 ext. 2001
- jm.delicado@...
- www.NVDA.es
- @nvda_es

***Este mensaje y sus adjuntos están dirigidos a su destinatario y pueden contener información exclusiva o confidencial. La utilización, copia o divulgación de los mismos por parte de alguien diferente a dicho destinatario no está permitida sin autorización. Si ha recibido este mensaje por error, le rogamos que lo comunique por esta misma vía y seguidamente lo destruya.***


Re: Are there any specific caveats for add-ons documentation on the website?

Noelia Ruiz
 

Hello: I"m not a translator, so I cannot provide the most reliable and complete answer. But I"ll start this thread saying what I try to do (despite mistakes):

1. Ensure that your document has the .mdwn extension in Assembla, though the extension on Github is .md.
2. Replace the heading level 1 úhich starts by a square symbol with the meta title tag, puting the title between double quotes (see a .mdwn file for examples).
3. Use asterisks followedb by space, not dash, for lists. Dashes are allowed on Github and on the website, but just in English. When the documentation is converted to .po files, using dashes doesn"t split the list in the desired items.
4. Use "reference" style for links, that is, include the corresponding urls at the botom of the file, with a blank line between urls (not sure if it"s needed, but maybe, and place a blank line at the bottom).
See examples. On Github we can include URLS between parentheses, but on the website we"ve always used reference style)..
5. Place the tags corresponding to the sections where the adddocumentation should appear before the references to the links, just before, with blank lines after the main content of the documentation and dev stable or dev tags, and a blank line after that and before the urls.
6. Try to use short paragraphs and lists, and headings of level 2 or 3 for a good structure and understandable documentation, avoiding a superlong or detailed changelog, since it should be translated and it"s better to focus in important things. This is just an additional recommendation and my own opinion.
Kind regards
Enviado desde mi iPhone

El 5 oct 2021, a las 17:05, Lukasz Golonka via groups.io <lukasz.golonka=mailbox.org@groups.io> escribió:

Dear all,

From time to time there are discussions here about add-ons documentation
in markdown being rendered correctly on GitHub but wrongly after it is
committed into SVN and shown on the add-ons website. Until now I had no
access to Assembla and someone else had to update documentation of my
add-ons of my behalf, but since I can do it myself now I would like to
ask if there are any specific points which should be taken into account
when using markdown so that it renders correctly on the add-ons web page.

--
Regards
Lukasz






Are there any specific caveats for add-ons documentation on the website?

Lukasz Golonka
 

Dear all,

From time to time there are discussions here about add-ons documentation
in markdown being rendered correctly on GitHub but wrongly after it is
committed into SVN and shown on the add-ons website. Until now I had no
access to Assembla and someone else had to update documentation of my
add-ons of my behalf, but since I can do it myself now I would like to
ask if there are any specific points which should be taken into account
when using markdown so that it renders correctly on the add-ons web page.

--
Regards
Lukasz


Re: Clock October 1st development build posted, candidate for next broad dev channel update

 

Hi all,

Clock October 1st development build is now being offered via Add-on Updater. The next broad dev build is tentatively planned for middle of October.

Cheers,

Joseph


Re: Add-on Updater 21.10, mandatory update for NVDA 2021.1 or later users #addonrelease

 

Hi all,

Add-on Updater 21.10 is being pushed to Add-on Updater users. Note that if you receive errors when checking for add-on updates, you must install Add-on Updater 21.10 manually.

Cheers,

Joseph

661 - 680 of 17823