Date   

Re: Braille routing keys, which API?

derek riemer
 

Does it fire event_caret?
Also, take a look at script_routing, and the gestures assigned to it. The gestures system creates a map dynamically by consulting a lot of different subsystems in NVDA. The gesture map handles the mapping from a routing key press to a script. when a user presses a routing key, NVDA looks up any scripts associated with that key, discovers the key in the globalCommands system, finds a script, and fires the relevant script, which does the magic. I think that script is in source/globalCommands.py and just fires braille.handler.routeTo with the correct braille cell. (gesture.routingIndex)
After a complicated set of abstractions, NVDA finally calls routeTo on the braille region associated with that key (The internals of the braille system are being glossed over because I don't want to explain all of the components for you when it isn't relevant to your question). For browsers, you probably are dealing with a TextInfoRegion or CursorManagerRegion. Can you type brlRegions in the NVDA python console after snapshotting the console on the element you're interested in inspecting? This will show you the regions. I don't remember exactly how regions work, or in which order the regions appear, but consulting the code for braille.Handler will hopefully help.

On Fri, Nov 22, 2019 at 11:33 PM mohammad suliman <Mohmad.s93@...> wrote:
Hello Leonard,
Thanks for this valuable info bro!! According to our observation with Firefox, no selection event is fired when the user changes the cursor position neither with arrow keys, nor with braille routing keys.
I hope that we are mistaking with this regard, and I hope to hear from someone from the browser side of things. Is Jamie still subscribed to this list, and can offer us his insight on this? This will be much appreciated!!
thanks and have a nice weekend!!
Mohammad

On Fri, 22 Nov 2019 at 08:49, Leonard de Ruijter <alderuijter@...> wrote:

Hey Mohammad,


This is interesting. Relevant code to look at in NVDA is NVDAObjects.IAccessible.IA2TextTextInfo._setCaretOffset and _setSelectionOffsets, I believe.

I assume the selection event isn't fired either when changing the caret position with arrow keys?


Regards,

Leonard

Op 21-11-2019 om 20:28 schreef mohammad suliman:
Hi Leonard,
Thanks for that info brother. So, we tried to listen for the selection change event. In Google chrome, this event is fired when the user navigates the textarea with arrow keys, or with the braille display routing keys. This is brilliant, and, behaves as one expects from the browser in those situations. However, for our surprise, Firefox doesn't do this at all!! Which is very strange actually. The only event that Firefox fires is a mousedown event when you click the routing key where the cursor is found. I am guessing that NVDA triggers this event? Not sure though.
So, if you, or someone can share a suggestion how to overcome this, it will be much appreciated!
have a grate time!
Mohammad

On Thu, 21 Nov 2019 at 12:47, Leonard de Ruijter <alderuijter@...> wrote:

Dear Mohammad,


NVDA asks the browser to change the caret position, so you probably have to listen to caret or selection events if that's possible. Communication to the browser is performed with the accessibility API of use, UIA in Edge and IE and IAccessible2 in Firefox and Chrome.


Regards,

Leonard

Op 20-11-2019 om 18:48 schreef mohammad suliman:
Hello all,
It has been a long time since I have posted here, so hope all of you are well, and doing well also!
I have a question regarding the braille routing keys. The question is as follows: Which API NVDA calls to set the cursor position when the user presses a routing key on a braille display on the web?
To clarify, here is what we are trying to achieve: we have an <input> element, and we want to track the cursor position when the user moves the cursor mainly by the braille display routing keys, and by arrows also, but this is not the issue here. So, we want to know when the user presses a routing key, and handle it appropriately in our system. We tried to listen to click and keypress events, but none of them is triggered as far as we have observed. So, in short, my question: how NVDA behaves when the user presses a routing key, while the focus is in an element with a caret, and this element is a web element.
Thanks in advance!
Mohammad



--
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: How to detect the creation of a UI object?

derek riemer
 

you may need to check out eventHandler.registerEvents. There are some events we hide creation of, because otherwise, you'll get spammed with events and that can be expensive to handle. Also, uia does interesting things, and this is always difficult. is NVDA ever showing the alert? If you can object nav to it and look, you might be able to know more.

On Fri, Nov 22, 2019 at 2:04 AM Cyrille via Groups.Io <cyrille.bougot2=laposte.net@groups.io> wrote:
Hello

I would like to be able to detect the creation of a button. Is there an associated event? How to know it? And how to let NVDA listen to this event?

Detailed context:
In Outlook 2016, when you type an e-mail address in the "To" field, an alert message is displayed if an auto-reply has been configured for this e-mail address on the Exchange server.
I would like to alert the NVDA user when this alert pops up. This alert contains a button that allows to remove the corresponding e-mail address from the "To" field.

What I have tried:
I have tried to subclass this button and to define event_NVDAObject_init. However, it seems that NVDAObjects are created only when NVDA needs it (object getting focus, navigator object, etc.). The NVDAObject is not created as soon as the object occurs.

Questions:
how to be informed that this button has been created in the UI? Does NVDA need to subscribe to an event in an accessibility API? If yes, how to do this?

Below is the dev info when I press NVDA+F1 on this button
Developer info for navigator object:
name: u'DUPONT Jean 12345'
role: ROLE_BUTTON
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <appModules.outlook.UIARecipientButton object at 0x0DCE17B0>
Python class mro: (<class 'appModules.outlook.UIARecipientButton'>, <class 'NVDAObjects.UIA.UIA'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u"\ufeff \r\n\r\nThis is an out-of-office message. Supprimer le destinataire\xa0: Jean DUPONT 12345"
location: RectLTWH(left=67, top=221, width=143, height=20)
value: None
appModule: <'outlook' (appName u'outlook', process ID 2812) at address aa58870>
appModule.productName: u'Microsoft Outlook'
appModule.productVersion: u'16.0.4900.1000'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 3278568
windowClassName: u'NetUIHWND'
windowControlID: 0
windowStyle: 1442840576
extendedWindowStyle: 0
windowThreadID: 1892
windowText: u''
displayText: u''
UIAElement: <POINTER(IUIAutomationElement) ptr=0xa42ac00 at dae7da0>
UIA automationID: RecipientButton
UIA frameworkID:
UIA runtimeID: (42, 3278568, 3, -1265467264, 0)
UIA providerDescription: [pid:2812,providerId:0x0 Main(parent link):Unidentified Provider (unmanaged:mso40uiwin32client.dll)]
UIA className: NetUISimpleButton
UIA patterns available: LegacyIAccessiblePattern, InvokePattern, ScrollItemPattern

Any idea is welcome. Thanks in advance.
Kind regards,

Cyrille



--
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: Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

Brian's Mail list account
 

I do think that there will at least for a while be folk staying on 2019.2.1, since not every add on will be ready, or indeed if from other sources, ever likely to be converted for the new nvda. Thus info on versions that an add on will work on is crucial so they do not overwrite things that work so to speak.
Brian

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

----- Original Message -----
From: "Leonard de Ruijter" <@leonardder>
To: <nvda-devel@groups.io>
Sent: Friday, November 22, 2019 6:34 PM
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing


Dear Joseph,


I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are
available for an add-on with the same add-on name, i.e. don't
distinguish between wintenApps and wintenApps-dev at the identifier
levels, but allow adding multiple channels/versions per add-on.


Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on
does have a field for it as part of the downloader class.

As for database schema, we have:

* Add-on ID/name (string)
* Friendly name (string
* Current version (string)
* New version (string)
* Minimum NVDA version (string)
* Last tested NVDA version (string)
* Hash (SHA256 minimum)
* Changelog (text)
* Download URL (URL)
* Author contact information (string and email address)

To answer James’s question: yes, designing the new database should be
done. But I think there should be a way to prototype it, and using
current infrastructure gives us an avenue to do so – in the end,
Add-on Updater is really a testbed for the pull request I’m working
on, so that add-on will have everything (or almost everything) the
pull request will have.

Cheers,

Joseph

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

Joseph,

For security reasons, I think the add-on database should also store a
sha256 hash of the add-on file, which can be provided and checked by
NVDA after downloading/updating the add-on. This can avoid installing
add-ons from malicious sources.

It might help to translate the proof of concept in an object
definition or a definition of a database storage table, so we can see
a real example of how the metadata would be stored in the database.
This makes it easier for developers to give concrete feedback about
the storage structure.

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

I’m considering the following modification to add-on files
database, which is used to store links to add-on files located on
community add-ons website and used by Add-on Updater add-on to
detect new add-on releases:

Recently, there has been a growing sentiment within the NVDA
community to incorporate add-on updating functionality into NVDA
screen reader. This is more so now that more add-ons are being
added to community add-ons website, along with the urgency created
by Python 3 transition and compatibility issues surrounding it.

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.

For example, Windows 10 App Essentials is entered as “w10” in the
add-on files database. In the future, a dedicated key named
“wintenApps” might be added. And since several add-ons do have
development version links, a “-dev” suffix can be added for new
keys, which is how development version links are grouped under at
the moment (for example, “wintenApps-dev”). In the end, the new
add-on metadata database will feature a dedicated column for
update branches, with an add-on hosting at least one update branch.

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.

A few things to keep in mind:

* 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.
* This proposal is a proof of concept proposal and may change
without notice.
* 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.

Comments are appreciated.

Cheers,

Joseph



Re: Braille routing keys, which API?

mohammad suliman
 

Hello Leonard,
Thanks for this valuable info bro!! According to our observation with Firefox, no selection event is fired when the user changes the cursor position neither with arrow keys, nor with braille routing keys.
I hope that we are mistaking with this regard, and I hope to hear from someone from the browser side of things. Is Jamie still subscribed to this list, and can offer us his insight on this? This will be much appreciated!!
thanks and have a nice weekend!!
Mohammad

On Fri, 22 Nov 2019 at 08:49, Leonard de Ruijter <alderuijter@...> wrote:

Hey Mohammad,


This is interesting. Relevant code to look at in NVDA is NVDAObjects.IAccessible.IA2TextTextInfo._setCaretOffset and _setSelectionOffsets, I believe.

I assume the selection event isn't fired either when changing the caret position with arrow keys?


Regards,

Leonard

Op 21-11-2019 om 20:28 schreef mohammad suliman:
Hi Leonard,
Thanks for that info brother. So, we tried to listen for the selection change event. In Google chrome, this event is fired when the user navigates the textarea with arrow keys, or with the braille display routing keys. This is brilliant, and, behaves as one expects from the browser in those situations. However, for our surprise, Firefox doesn't do this at all!! Which is very strange actually. The only event that Firefox fires is a mousedown event when you click the routing key where the cursor is found. I am guessing that NVDA triggers this event? Not sure though.
So, if you, or someone can share a suggestion how to overcome this, it will be much appreciated!
have a grate time!
Mohammad

On Thu, 21 Nov 2019 at 12:47, Leonard de Ruijter <alderuijter@...> wrote:

Dear Mohammad,


NVDA asks the browser to change the caret position, so you probably have to listen to caret or selection events if that's possible. Communication to the browser is performed with the accessibility API of use, UIA in Edge and IE and IAccessible2 in Firefox and Chrome.


Regards,

Leonard

Op 20-11-2019 om 18:48 schreef mohammad suliman:
Hello all,
It has been a long time since I have posted here, so hope all of you are well, and doing well also!
I have a question regarding the braille routing keys. The question is as follows: Which API NVDA calls to set the cursor position when the user presses a routing key on a braille display on the web?
To clarify, here is what we are trying to achieve: we have an <input> element, and we want to track the cursor position when the user moves the cursor mainly by the braille display routing keys, and by arrows also, but this is not the issue here. So, we want to know when the user presses a routing key, and handle it appropriately in our system. We tried to listen to click and keypress events, but none of them is triggered as far as we have observed. So, in short, my question: how NVDA behaves when the user presses a routing key, while the focus is in an element with a caret, and this element is a web element.
Thanks in advance!
Mohammad


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

Noelia Ruiz
 

I am reading previous messages in this thread and mine is quite vague. WHAT I mean is that I like the idea of creating a database so that in the future NVDA can differenciate between add-ons considered secure, just it. I agree in doing proof of concept testing if this would bring some benefit. For me addonUpdater is useful to update some addons in a comfortable way without searching on the website. But if it needs to be stored by NV Access in its server, may be good to wait for his opinion before testing. I mean that they may know how to do this in a precise way, probably without using addonFiles, and in this case previous modifications for testing may not be useful. Maybe they can do this very quickly, of course consulting with the community, and in this case it could be better to wait until they are available to work on this before changing things.
Cheers

Enviado desde mi iPhone

El 23 nov 2019, a las 0:26, Luke Davis <luke@...> escribió:

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-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


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

Brian's Mail list account
 

Well as long as everyone can understand what it actually means.
Example along comes a person who has an add on that only works in 2019.2.1 or earlier. He/she wants to stay on this version of nvda for that reason. Would this system only show that person add ons that are known to be compatible with that version of nvda, i.e. either legacy ones not made to work yet, or dual function ones where they work on both.


Brian

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

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Friday, November 22, 2019 4:14 PM
Subject: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing


Hi all,



I'm considering the following modification to add-on files database, which
is used to store links to add-on files located on community add-ons website
and used by Add-on Updater add-on to detect new add-on releases:



Recently, there has been a growing sentiment within the NVDA community to
incorporate add-on updating functionality into NVDA screen reader. This is
more so now that more add-ons are being added to community add-ons website,
along with the urgency created by Python 3 transition and compatibility
issues surrounding it.



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.



For example, Windows 10 App Essentials is entered as "w10" in the add-on
files database. In the future, a dedicated key named "wintenApps" might be
added. And since several add-ons do have development version links, a "-dev"
suffix can be added for new keys, which is how development version links are
grouped under at the moment (for example, "wintenApps-dev"). In the end, the
new add-on metadata database will feature a dedicated column for update
branches, with an add-on hosting at least one update branch.



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.



A few things to keep in mind:



* 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.
* This proposal is a proof of concept proposal and may change without
notice.
* 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.



Comments are appreciated.

Cheers,

Joseph




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

Noelia Ruiz
 

Hi, though I don't have a precise way to implement this, I agree with
the general idea. Also, we have to address the fact that there are
add-ons considered secure though they aren't stored in addonFiles
repo, for example syntesizers, announced by NV Access or by the
community as secure add-ons. In the other hand, many of us have seen
reops or websites providing add-ons stored in the community, maybe
stored in their own servers or providing a link to addonFiles.
Cheers

2019-11-22 19:47 GMT+01:00, Joseph Lee <@joslee>:

Hi,

Ah yes, I forgot to mention that channel is one of the columns (string).
Sorry about that.

Cheers,

Joseph



From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de
Ruijter
Sent: Friday, November 22, 2019 10:34 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files
database to include add-on name/ID for easier comparison and for
future-proofing



Dear Joseph,



I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are
available for an add-on with the same add-on name, i.e. don't distinguish
between wintenApps and wintenApps-dev at the identifier levels, but allow
adding multiple channels/versions per add-on.



Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that's the reason why the pull request I'm working on does
have a field for it as part of the downloader class.

As for database schema, we have:

* Add-on ID/name (string)
* Friendly name (string
* Current version (string)
* New version (string)
* Minimum NVDA version (string)
* Last tested NVDA version (string)
* Hash (SHA256 minimum)
* Changelog (text)
* Download URL (URL)
* Author contact information (string and email address)





To answer James's question: yes, designing the new database should be done.
But I think there should be a way to prototype it, and using current
infrastructure gives us an avenue to do so - in the end, Add-on Updater is
really a testbed for the pull request I'm working on, so that add-on will
have everything (or almost everything) the pull request will have.

Cheers,

Joseph

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



Joseph,



For security reasons, I think the add-on database should also store a
sha256
hash of the add-on file, which can be provided and checked by NVDA after
downloading/updating the add-on. This can avoid installing add-ons from
malicious sources.

It might help to translate the proof of concept in an object definition or
a
definition of a database storage table, so we can see a real example of how
the metadata would be stored in the database. This makes it easier for
developers to give concrete feedback about the storage structure.



Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,



I'm considering the following modification to add-on files database, which
is used to store links to add-on files located on community add-ons website
and used by Add-on Updater add-on to detect new add-on releases:



Recently, there has been a growing sentiment within the NVDA community to
incorporate add-on updating functionality into NVDA screen reader. This is
more so now that more add-ons are being added to community add-ons website,
along with the urgency created by Python 3 transition and compatibility
issues surrounding it.



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.



For example, Windows 10 App Essentials is entered as "w10" in the add-on
files database. In the future, a dedicated key named "wintenApps" might be
added. And since several add-ons do have development version links, a
"-dev"
suffix can be added for new keys, which is how development version links
are
grouped under at the moment (for example, "wintenApps-dev"). In the end,
the
new add-on metadata database will feature a dedicated column for update
branches, with an add-on hosting at least one update branch.



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.



A few things to keep in mind:



* 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.
* This proposal is a proof of concept proposal and may change without
notice.
* 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.



Comments are appreciated.

Cheers,

Joseph







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

 

Hi,

Ah yes, I forgot to mention that channel is one of the columns (string). Sorry about that.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Leonard de Ruijter
Sent: Friday, November 22, 2019 10:34 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Dear Joseph,

 

I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are available for an add-on with the same add-on name, i.e. don't distinguish between wintenApps and wintenApps-dev at the identifier levels, but allow adding multiple channels/versions per add-on.

 

Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

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

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph


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

 

Dear Joseph,


I'm not sure why we need a current version and new version string.

I would also say that it would help to identify all channels that are available for an add-on with the same add-on name, i.e. don't distinguish between wintenApps and wintenApps-dev at the identifier levels, but allow adding multiple channels/versions per add-on.


Regards,

Leonard

Op 22-11-2019 om 19:05 schreef Joseph Lee:

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

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

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph


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

 

Hi,

Ah yes, hash: that’s the reason why the pull request I’m working on does have a field for it as part of the downloader class.

As for database schema, we have:

  • Add-on ID/name (string)
  • Friendly name (string
  • Current version (string)
  • New version (string)
  • Minimum NVDA version (string)
  • Last tested NVDA version (string)
  • Hash (SHA256 minimum)
  • Changelog (text)
  • Download URL (URL)
  • Author contact information (string and email address)

 

 

To answer James’s question: yes, designing the new database should be done. But I think there should be a way to prototype it, and using current infrastructure gives us an avenue to do so – in the end, Add-on Updater is really a testbed for the pull request I’m working on, so that add-on will have everything (or almost everything) the pull request will have.

Cheers,

Joseph

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

 

Joseph,

 

For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.

 

Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph


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

 

Joseph,


For security reasons, I think the add-on database should also store a sha256 hash of the add-on file, which can be provided and checked by NVDA after downloading/updating the add-on. This can avoid installing add-ons from malicious sources.

It might help to translate the proof of concept in an object definition or a definition of a database storage table, so we can see a real example of how the metadata would be stored in the database. This makes it easier for developers to give concrete feedback about the storage structure.


Regards,

Leonard

Op 22-11-2019 om 17:14 schreef Joseph Lee:

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph


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

James Scholes
 

Why would the primary key for an add-on not be visible to users? It would mean maintaining two keys for an add-on:

1. the shorthand, e.e. w10; and
2. the ID, win10apps.

I don't see the difference between these. They both serve as keys for programmatic purposes. The only differentiator is that w10 is shorter. That's literally it. I don't think human readable and writable add-on IDs should be a particular design intent.

In addition, I don't think we should be introducing keys like win10apps_dev, when specific columns for update channel-related info are planned in the future. Why introduce a solution now just to abandon it in short order? An ID-to-name mapping between win10app_dev and the dev version of Windows 10 App Essentials doesn't make sense either, because the name is shared and only the update channel differs.

Maybe I'm missing something, but to me the shorthand is already the ID and your email is only suggesting duplicating it as a longer string for no concrete reason. If we want to build an add-on metadata DB, and we absolutely should, why don't we just plan that instead? We're suggesting impactless changes even though we don't have a particular schema as yet.

Regards,

James Scholes

On 22/11/2019 at 10:14 am, Joseph Lee wrote:
Hi all,
I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:
Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.
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.
For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.
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.
A few things to keep in mind:
* 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.
* This proposal is a proof of concept proposal and may change without
notice.
* 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.
Comments are appreciated.
Cheers,
Joseph


Add-on Updater proposal: modify add-on files database to include add-on name/ID for easier comparison and for future-proofing

 

Hi all,

 

I’m considering the following modification to add-on files database, which is used to store links to add-on files located on community add-ons website and used by Add-on Updater add-on to detect new add-on releases:

 

Recently, there has been a growing sentiment within the NVDA community to incorporate add-on updating functionality into NVDA screen reader. This is more so now that more add-ons are being added to community add-ons website, along with the urgency created by Python 3 transition and compatibility issues surrounding it.

 

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.

 

For example, Windows 10 App Essentials is entered as “w10” in the add-on files database. In the future, a dedicated key named “wintenApps” might be added. And since several add-ons do have development version links, a “-dev” suffix can be added for new keys, which is how development version links are grouped under at the moment (for example, “wintenApps-dev”). In the end, the new add-on metadata database will feature a dedicated column for update branches, with an add-on hosting at least one update branch.

 

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.

 

A few things to keep in mind:

 

  • 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.
  • This proposal is a proof of concept proposal and may change without notice.
  • 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.

 

Comments are appreciated.

Cheers,

Joseph


How to detect the creation of a UI object?

Cyrille
 

Hello

I would like to be able to detect the creation of a button. Is there an associated event? How to know it? And how to let NVDA listen to this event?

Detailed context:
In Outlook 2016, when you type an e-mail address in the "To" field, an alert message is displayed if an auto-reply has been configured for this e-mail address on the Exchange server.
I would like to alert the NVDA user when this alert pops up. This alert contains a button that allows to remove the corresponding e-mail address from the "To" field.

What I have tried:
I have tried to subclass this button and to define event_NVDAObject_init. However, it seems that NVDAObjects are created only when NVDA needs it (object getting focus, navigator object, etc.). The NVDAObject is not created as soon as the object occurs.

Questions:
how to be informed that this button has been created in the UI? Does NVDA need to subscribe to an event in an accessibility API? If yes, how to do this?

Below is the dev info when I press NVDA+F1 on this button
Developer info for navigator object:
name: u'DUPONT Jean 12345'
role: ROLE_BUTTON
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
Python object: <appModules.outlook.UIARecipientButton object at 0x0DCE17B0>
Python class mro: (<class 'appModules.outlook.UIARecipientButton'>, <class 'NVDAObjects.UIA.UIA'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u"\ufeff \r\n\r\nThis is an out-of-office message. Supprimer le destinataire\xa0: Jean DUPONT 12345"
location: RectLTWH(left=67, top=221, width=143, height=20)
value: None
appModule: <'outlook' (appName u'outlook', process ID 2812) at address aa58870>
appModule.productName: u'Microsoft Outlook'
appModule.productVersion: u'16.0.4900.1000'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 3278568
windowClassName: u'NetUIHWND'
windowControlID: 0
windowStyle: 1442840576
extendedWindowStyle: 0
windowThreadID: 1892
windowText: u''
displayText: u''
UIAElement: <POINTER(IUIAutomationElement) ptr=0xa42ac00 at dae7da0>
UIA automationID: RecipientButton
UIA frameworkID:
UIA runtimeID: (42, 3278568, 3, -1265467264, 0)
UIA providerDescription: [pid:2812,providerId:0x0 Main(parent link):Unidentified Provider (unmanaged:mso40uiwin32client.dll)]
UIA className: NetUISimpleButton
UIA patterns available: LegacyIAccessiblePattern, InvokePattern, ScrollItemPattern

Any idea is welcome. Thanks in advance.
Kind regards,

Cyrille


Re: Braille routing keys, which API?

 

Hey Mohammad,


This is interesting. Relevant code to look at in NVDA is NVDAObjects.IAccessible.IA2TextTextInfo._setCaretOffset and _setSelectionOffsets, I believe.

I assume the selection event isn't fired either when changing the caret position with arrow keys?


Regards,

Leonard

Op 21-11-2019 om 20:28 schreef mohammad suliman:

Hi Leonard,
Thanks for that info brother. So, we tried to listen for the selection change event. In Google chrome, this event is fired when the user navigates the textarea with arrow keys, or with the braille display routing keys. This is brilliant, and, behaves as one expects from the browser in those situations. However, for our surprise, Firefox doesn't do this at all!! Which is very strange actually. The only event that Firefox fires is a mousedown event when you click the routing key where the cursor is found. I am guessing that NVDA triggers this event? Not sure though.
So, if you, or someone can share a suggestion how to overcome this, it will be much appreciated!
have a grate time!
Mohammad

On Thu, 21 Nov 2019 at 12:47, Leonard de Ruijter <alderuijter@...> wrote:

Dear Mohammad,


NVDA asks the browser to change the caret position, so you probably have to listen to caret or selection events if that's possible. Communication to the browser is performed with the accessibility API of use, UIA in Edge and IE and IAccessible2 in Firefox and Chrome.


Regards,

Leonard

Op 20-11-2019 om 18:48 schreef mohammad suliman:
Hello all,
It has been a long time since I have posted here, so hope all of you are well, and doing well also!
I have a question regarding the braille routing keys. The question is as follows: Which API NVDA calls to set the cursor position when the user presses a routing key on a braille display on the web?
To clarify, here is what we are trying to achieve: we have an <input> element, and we want to track the cursor position when the user moves the cursor mainly by the braille display routing keys, and by arrows also, but this is not the issue here. So, we want to know when the user presses a routing key, and handle it appropriately in our system. We tried to listen to click and keypress events, but none of them is triggered as far as we have observed. So, in short, my question: how NVDA behaves when the user presses a routing key, while the focus is in an element with a caret, and this element is a web element.
Thanks in advance!
Mohammad


Re: Small heads up about vision providers

DaVid
 

I agree with Karl-Otto.
Native features should have the highest priority. Screen curtain is a
very aclaimed feature. NVDA will get more and more features, and if
you need to avoid conflicts with add-ons then will be impossible to
assign gestures to the new NVDA's features.
The equivalent curtain feature of other screen readers like Voice Over
have a gesture asigned. I think that NVDA should have it also.
The idea propossed by Carl is good also. I always remap the NVDA's
reading commands for keyboard laptops. The original layout is
unintuitive on my opinion and causes people to have to move their
hands more, and is very unusable with some modern laptop keyboards.
But I use an add-on that conflicts with my personal layout. I need to
remap the gestures each time I install that add-on. The developer
decided to assign a very easy command, but I need that gesture for
more important things.

Regards,
DaVid.


Re: Small heads up about vision providers

Karl-Otto Rosenqvist
 

Hi!
I understand the reasoning about conflicts and naturally it’s best to do what you can to avoid them.

With that said I think that a pure NVDA installation must set the stage and then add-ons can adjust if possible. It’s always possible to manually change the input gesture for the screen curtain if the add-on is more important to you.

Just as you write there are many add-ons and there will be conflicts that must be resolved regardless of how much we try to avoid it.

Basic built-in features should have the highest priority in this situation.

One way to resolve gesture conflicts would be to show a dialog to the user where conflicts are presented and let the user select which one of the features that should have that gesture and the possibility to re-map the other ones in the same dialog.
This would of course generate need for development so as a first step NVDA could just show a dialog with text that explains that function X (native NVDA) and Y (Add-on name) uses the same gesture and in order to avoid conflict the gesture for Y has been removed. If you want to change this go to the NVDA settings and re-map gestures.


Kind regards

Karl-Otto
MAWINGU
0701-75 98 56
https://mawingu.se
Orgnr: 750804-3937

21 nov. 2019 kl. 17:57 skrev Joseph Lee <joseph.lee22590@...>:



Hi,

We’ve got conflicts to resolve, actually – with many add-ons out there, the possibility of commands clashing has gotten to a point where certain features have no commands of any kind for safety reasons (as in avoiding conflicts with more add-ons). Add to the fact that different language and keyboard layouts dictate that we move things around, and we get into battle over keys. A layer set is a possible solution, which does have disadvantages.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Travis Siegel
Sent: Thursday, November 21, 2019 8:50 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Small heads up about vision providers

 

Right, and how many users are going to know to do this?

Moreover, of those who do know, how many are going to want to perform said steps every time they want it enabled/disabled? It makes more sense to assign it a gesture, then let folks change said gesture if they don't like the default one.

 

On 11/21/2019 11:36 AM, Karl-Otto Rosenqvist wrote:

You go into the NVDA settings, choose the Vision category and then check the checkbox to activate the screen curtain. Note, this is only availible in the latest alpha snapshot.

 

Cheers!

Karl-Otto

MAWINGU

0701-75 98 56

Orgnr: 750804-3937



21 nov. 2019 kl. 17:14 skrev Travis Siegel <tsiegel@...>:



So, how does one activate the screen curtain if it doesn't have a gesture tied to it?

This is a bad decision in my opinion.

On 11/21/2019 3:14 AM, Leonard de Ruijter wrote:

Dear Karl-Otto,

 

It has been decided not to assign a default gesture for this. This can also be reconsidered, of course.

Translatable strings will show up as soon as this code is merged into a beta release.

 

Regards,

Leonards

Op 21-11-2019 om 09:02 schreef Karl-Otto Rosenqvist:

Thanks!

I downloaded and tested it. There’s no default gesture for activating the screen curtain and my initial thoughts are that there should be one. When visually impaired it’s a key feature to be sure that no one can glance at your screen without your acknowledgement.

What key combination should that be?

 

I tested my swedish translations on the alpha and there seems to be some texts missing that relates to Vision-settings. I suppose that they will show up eventually so we can translate them too.

 

 

Thanks for a very good job!

Karl-Otto

MAWINGU

0701-75 98 56

Orgnr: 750804-3937



20 nov. 2019 kl. 19:17 skrev Leonard de Ruijter <alderuijter@...>:



Dear all,

 

As you may have noticed, in Alpha there is now a gui for the vision framework, found under the Vision category in NVDA's settings dialog.

Note that, as per a merge of around an hour ago, the way how active providers are saved in the configuration has changed. Therefore, especially when you expect screen curtain to be on, expect it to be off after the most recent alpha update, and enable it again if you so desire.

 

Regards,

Leonard


Re: Braille routing keys, which API?

mohammad suliman
 

Hi Leonard,
Thanks for that info brother. So, we tried to listen for the selection change event. In Google chrome, this event is fired when the user navigates the textarea with arrow keys, or with the braille display routing keys. This is brilliant, and, behaves as one expects from the browser in those situations. However, for our surprise, Firefox doesn't do this at all!! Which is very strange actually. The only event that Firefox fires is a mousedown event when you click the routing key where the cursor is found. I am guessing that NVDA triggers this event? Not sure though.
So, if you, or someone can share a suggestion how to overcome this, it will be much appreciated!
have a grate time!
Mohammad


On Thu, 21 Nov 2019 at 12:47, Leonard de Ruijter <alderuijter@...> wrote:

Dear Mohammad,


NVDA asks the browser to change the caret position, so you probably have to listen to caret or selection events if that's possible. Communication to the browser is performed with the accessibility API of use, UIA in Edge and IE and IAccessible2 in Firefox and Chrome.


Regards,

Leonard

Op 20-11-2019 om 18:48 schreef mohammad suliman:
Hello all,
It has been a long time since I have posted here, so hope all of you are well, and doing well also!
I have a question regarding the braille routing keys. The question is as follows: Which API NVDA calls to set the cursor position when the user presses a routing key on a braille display on the web?
To clarify, here is what we are trying to achieve: we have an <input> element, and we want to track the cursor position when the user moves the cursor mainly by the braille display routing keys, and by arrows also, but this is not the issue here. So, we want to know when the user presses a routing key, and handle it appropriately in our system. We tried to listen to click and keypress events, but none of them is triggered as far as we have observed. So, in short, my question: how NVDA behaves when the user presses a routing key, while the focus is in an element with a caret, and this element is a web element.
Thanks in advance!
Mohammad


Re: Small heads up about vision providers

 

Hi,

We’ve got conflicts to resolve, actually – with many add-ons out there, the possibility of commands clashing has gotten to a point where certain features have no commands of any kind for safety reasons (as in avoiding conflicts with more add-ons). Add to the fact that different language and keyboard layouts dictate that we move things around, and we get into battle over keys. A layer set is a possible solution, which does have disadvantages.

Cheers,

Joseph

 

From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Travis Siegel
Sent: Thursday, November 21, 2019 8:50 AM
To: nvda-devel@groups.io
Subject: Re: [nvda-devel] Small heads up about vision providers

 

Right, and how many users are going to know to do this?

Moreover, of those who do know, how many are going to want to perform said steps every time they want it enabled/disabled? It makes more sense to assign it a gesture, then let folks change said gesture if they don't like the default one.

 

On 11/21/2019 11:36 AM, Karl-Otto Rosenqvist wrote:

You go into the NVDA settings, choose the Vision category and then check the checkbox to activate the screen curtain. Note, this is only availible in the latest alpha snapshot.

 

Cheers!

Karl-Otto

MAWINGU

0701-75 98 56

Orgnr: 750804-3937



21 nov. 2019 kl. 17:14 skrev Travis Siegel <tsiegel@...>:



So, how does one activate the screen curtain if it doesn't have a gesture tied to it?

This is a bad decision in my opinion.

On 11/21/2019 3:14 AM, Leonard de Ruijter wrote:

Dear Karl-Otto,

 

It has been decided not to assign a default gesture for this. This can also be reconsidered, of course.

Translatable strings will show up as soon as this code is merged into a beta release.

 

Regards,

Leonards

Op 21-11-2019 om 09:02 schreef Karl-Otto Rosenqvist:

Thanks!

I downloaded and tested it. There’s no default gesture for activating the screen curtain and my initial thoughts are that there should be one. When visually impaired it’s a key feature to be sure that no one can glance at your screen without your acknowledgement.

What key combination should that be?

 

I tested my swedish translations on the alpha and there seems to be some texts missing that relates to Vision-settings. I suppose that they will show up eventually so we can translate them too.

 

 

Thanks for a very good job!

Karl-Otto

MAWINGU

0701-75 98 56

Orgnr: 750804-3937



20 nov. 2019 kl. 19:17 skrev Leonard de Ruijter <alderuijter@...>:



Dear all,

 

As you may have noticed, in Alpha there is now a gui for the vision framework, found under the Vision category in NVDA's settings dialog.

Note that, as per a merge of around an hour ago, the way how active providers are saved in the configuration has changed. Therefore, especially when you expect screen curtain to be on, expect it to be off after the most recent alpha update, and enable it again if you so desire.

 

Regards,

Leonard