Date   

Re: Bluetooth Audio Addon Not Functioning?

Gene
 

Try Silenzio. It’s a small utility that generates inaudible signals to keep speakers sound cards from timing out when there is no signal, as some do. It will probably solve the Blue Tooth time out problem as well.
Silenzio.
http://www.stefankiss.sk/modules.php?name=Downloads&d_op=getit&lid=112

Try running the setup file and then if there is anything else to do, such as run the installed utility, do so. Let us know if there are problems or if you have questions.
To read a little about it, perhaps containing mor exact instructions, I haven't read the material, go to this page and you will see a discussion of the timeout problems and various solutions, including this one.
https://mosen.org/blog/

Gene

-----Original Message-----
From: Jesse Farquharson
Sent: Sunday, August 02, 2020 9:17 AM
To: nvda@nvda.groups.io
Subject: [nvda] Bluetooth Audio Addon Not Functioning?



Hello folks,

I normally don't write to the list here but I am running across something that is driving me mad.

So, I use hearing aides by Phonak. I have the Phonak CommPilot, a bluetooth audio device that transmits audio from say, my iPhone, directly into my hearing aides, connected to the laptop.

To be blunt, if I want to use my computer, at all, I have to have something streaming, be in a music file or something else. Otherwise, my bluetooth device kicks in... irratically. For some reason, it seems to start,, then stop sending audio immediately after I press a key, kick in again, then cut out as soon as NVDA stops speaking. I have Tony's Bluettoth addon on and running, and I have its standby time at a minute, but is having no affect whatsoever.

Can anyone help?


Community add-ons notice: Image Describer by Oliver Edholm is hereby deprecated and will be removed from community add-ons website this week

 

Hello everyone,

 

Attention all Image Describer add-on users: if you are using Image Describer developed by Oliver Edholm, this is to inform you that this add-on is hereby declared “deprecated” by the NVDA add-ons community. Efforts by users to contact Oliver was unsuccessful, and the payment service which allowed image recognition (the core of the add-on) to work isn’t working anymore.

Therefore Image Describer add-on is hereby deprecated. Please uninstall this add-on, and sometime this week, Image Describer add-on itself will be removed from community add-ons website. The next version of Add-on updater will not check for Image Describer updates and will tell you to uninstall the add-on (all coming with the next version of Add-on Updater).

Cheers,

Joseph


Re: How can I copy, keeping the format of the document in Chrome?

Gene
 

Not if browse mode is on. If you turn browse mode off, the formatting of the web page will be retained. Use NVDA space bar to turn off browse mode, then use control a. then turn browse mode on again with NVDA a.

-----Original Message-----
From: Brian Vogel
Sent: Sunday, August 02, 2020 9:49 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] How can I copy, keeping the format of the document in Chrome?

"Select all and Copy" in Firefox is just an implementation of CTRL+A followed by CTRL+C.

I just used the "manual way" in Chrome, pasted the result into MS-Word, and all formatting is retained.
--


Brian - Windows 10 Pro, 64-Bit, Version 1909, Build 18363

Science has become just another voice in the room; it has lost its platform. Now, you simply declare your own truth.

~ Dr. Paul A. Offit, in New York Times article, How Anti-Vaccine Sentiment Took Hold in the United States, September 23, 2019


Re: Reading Graphics with NVDA

Aravind R
 

in chrome browser settings, enable image description.

On 02/08/2020, Albert Peters <albertjpeters@...> wrote:
Good Day


Please forgive me if this question has been asked and answered previously.


I've received an e-mail newsletter with a graph in the body which, I
suppose, may be the contents.  NVDA simply announces "blank".-


Kindly advise me as to how I may convert this graphic so that NVDA can
read it to me, please.


Thanks in advance for all advice  offered.


Warm regards.



Albert

South Africa






--


--
--
nothing is difficult unless you make it appear so.

r. aravind,

manager
Department of sales
bank of baroda specialised mortgage store, Chennai.
mobile no: +91 9940369593,
email id : aravind_069@..., aravind.andhrabank@....
aravind.rajendran@....


Re: Reading Graphics with NVDA

 

At the moment, I don't know if you can.  There had been an NVDA Add-On for this purpose that "went dead" a couple of months ago.  I have e-mailed its developer and never heard back.

There was also the hope that an improved version which was in the works might appear on the Add-Ons page once it went through the necessary vetting process.  That has not, as of yet, occurred.

--

Brian - Windows 10 Pro, 64-Bit, Version 1909, Build 18363  

Science has become just another voice in the room; it has lost its platform.  Now, you simply declare your own truth.

      ~ Dr. Paul A. Offit, in New York Times article, How Anti-Vaccine Sentiment Took Hold in the United States, September 23, 2019

 

 


Re: NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

 

Hi,

Until recently it was a bit hard to generate code documentation. We switched to Sphinx for generating code docs, which should make it easier to look up NVDA’s source code documentation in a more accessible place in the future.

Regarding toast notifications and Action Center, that part lives in NVDAObjects/UIA/__init__.py.

Cheers,

Joseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Sean
Sent: Sunday, August 2, 2020 4:39 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

 

Joseph, this is a great mail or article :) . I read it with all my attention. Thank you so much.

Here writes a lot of thought about NVDA’s code database.
I’m just curious about one thing:
NVDA’s code database is big.
I’m looking for a document describing NVDA’s folder layout.

  • For example, which module of NVDA is processing notifications to Action Center?

I’m very new to NVDA. I have been using it for years and now I want to support coding.
Do you know any documents or methods on this subject?
How should we consider the NVDA’s folder hierarchy?

On 02/08/2020 05:42, Joseph Lee wrote:

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

  • Some of the things I wrote are rough at times (my apologies for these).
  • The biggest takeaway is that coding is not for everyone.
  • Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

  • Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
  • I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
  • I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

  • You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
  • You are writing an essay. After all, coding is responding to an essay prompt (or two).
  • You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
  • Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
  • You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

--

Sean

👨🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.


Re: NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

 

Hi,

Either way is fine.

Cheers,

Joseph

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Cuong Dang Manh
Sent: Sunday, August 2, 2020 5:34 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

 

Hi, and thanks for the article

One thing maybe off topic but I'd like to ask. If I see misspell in NVDA's documentations or interface, and I just a translater, should I fix, and submit pull request, or I should report it in NVDA translation mailing list for other people in NVDA developer to fix it? Right now I'm a translater, and I could contribute that way if I see any.

Appreciated your help.
Cuong

On 8/2/2020 6:38 PM, Sean wrote:

Joseph, this is a great mail or article :) . I read it with all my attention. Thank you so much.

Here writes a lot of thought about NVDA’s code database.
I’m just curious about one thing:
NVDA’s code database is big.
I’m looking for a document describing NVDA’s folder layout.

  • For example, which module of NVDA is processing notifications to Action Center?

I’m very new to NVDA. I have been using it for years and now I want to support coding.
Do you know any documents or methods on this subject?
How should we consider the NVDA’s folder hierarchy?

On 02/08/2020 05:42, Joseph Lee wrote:

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

  • Some of the things I wrote are rough at times (my apologies for these).
  • The biggest takeaway is that coding is not for everyone.
  • Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

  • Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
  • I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
  • I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

  • You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
  • You are writing an essay. After all, coding is responding to an essay prompt (or two).
  • You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
  • Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
  • You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

--

Sean

👨🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.


Re: How can I copy, keeping the format of the document in Chrome?

 

"Select all and Copy" in Firefox is just an implementation of CTRL+A followed by CTRL+C.

I just used the "manual way" in Chrome, pasted the result into MS-Word, and all formatting is retained.
--

Brian - Windows 10 Pro, 64-Bit, Version 1909, Build 18363  

Science has become just another voice in the room; it has lost its platform.  Now, you simply declare your own truth.

      ~ Dr. Paul A. Offit, in New York Times article, How Anti-Vaccine Sentiment Took Hold in the United States, September 23, 2019

 

 


Reading Graphics with NVDA

Albert Peters
 

Good Day


Please forgive me if this question has been asked and answered previously.


I've received an e-mail newsletter with a graph in the body which, I suppose, may be the contents.  NVDA simply announces "blank".-


Kindly advise me as to how I may convert this graphic so that NVDA can read it to me, please.


Thanks in advance for all advice  offered.


Warm regards.



Albert

South Africa


Re: Free Tutorials for using NVDA with MS Office Word, PowerPoint and Excel

Tony Ballou
 

On 8/1/2020 5:38 AM, soloman s wrote:
Hello all,

Could someone share tutorials for Word, Excel and PowerPoint using NVDA? It will be helpful if you could direct me to links/resources.
I am looking for free resources.
Hi,


Go to http://www.accessibilitycentral.net there are all kinds of materials on NVDA available for free.  Hope this helps.


Tony


Bluetooth Audio Addon Not Functioning?

Jesse Farquharson
 

Hello folks,

I normally don't write to the list here but I am running across something that is driving me mad.

So, I use hearing aides by Phonak. I have the Phonak CommPilot, a bluetooth audio device that transmits audio from say, my iPhone, directly into my hearing aides, connected to the laptop.

To be blunt, if I want to use my computer, at all, I have to have something streaming, be in a music file or something else. Otherwise, my bluetooth device kicks in... irratically. For some reason, it seems to start,, then stop sending audio immediately after I press a key, kick in again, then cut out as soon as NVDA stops speaking. I have Tony's Bluettoth addon on and running, and I have its standby time at a minute, but is having no affect whatsoever.

Can anyone help?


Avanquest - SoftMaker Office 2018 Professional and NVDA

Don H
 

Does anyone have any experiences with using Avanquest - SoftMaker Office 2018 Professional  with NVDA on a Win 10 system.  Just noticed this office suite on sale at Best Buy for $74.  You tube says it is very similar to Microsoft Office but that doesn't mean it would work with NVDA.  So if you have any experiences using this software please give your opinion as to its usefullness with NVDA.

Thanks


Re: NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

 

Hi, and thanks for the article

One thing maybe off topic but I'd like to ask. If I see misspell in NVDA's documentations or interface, and I just a translater, should I fix, and submit pull request, or I should report it in NVDA translation mailing list for other people in NVDA developer to fix it? Right now I'm a translater, and I could contribute that way if I see any.

Appreciated your help.
Cuong

On 8/2/2020 6:38 PM, Sean wrote:

Joseph, this is a great mail or article :) . I read it with all my attention. Thank you so much.

Here writes a lot of thought about NVDA’s code database.
I’m just curious about one thing:
NVDA’s code database is big.
I’m looking for a document describing NVDA’s folder layout.

  • For example, which module of NVDA is processing notifications to Action Center?

I’m very new to NVDA. I have been using it for years and now I want to support coding.
Do you know any documents or methods on this subject?
How should we consider the NVDA’s folder hierarchy?

On 02/08/2020 05:42, Joseph Lee wrote:

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

  • Some of the things I wrote are rough at times (my apologies for these).
  • The biggest takeaway is that coding is not for everyone.
  • Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

  • Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
  • I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
  • I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

  • You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
  • You are writing an essay. After all, coding is responding to an essay prompt (or two).
  • You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
  • Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
  • You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

--

Sean

👨‍🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.


How can I copy, keeping the format of the document in Chrome?

Sean
 

Hello NVDA community,
I hope you are healthy. We should wear a mask on Espeak :) .

Chrome for the web is my favorite.

When I open any HTML document in Chrome, I want to copy the document to the clipboard, keeping the format properties of the document.
So headers, underlined words, lists…

This happens when I do Alt > Edit > Select all & Copy in Firefox.
But there is no menu called Edit in Chrome.
Ctrl+a & ctrl+c copy only plain text.

  • How can I copy, keeping the format of the document in Chrome?


Sean

👨‍🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.


Re: NVDA and web buttons

Hettie
 

Thanks for the information. Will try that in future when I'm stuck.


Hettie

On 2020/08/01 8:44 pm, Jackie wrote:
Just press NVDA spacebar again, Hettie. A lower beep tone is what you
want to hear.

So I suspect I'm gonna get in trouble for saying this, but I'm just
sharing my experience. Sometimes, it appears like NVDA has trouble
activating some web elements, & I often have to use a variety of
techniques if enter or spacebar doesn't work, including the NVDA f7
key, using object navigation, NVDA backspace/shift backspace to ensure
the element is in focus & then enter/spacebar/click, etc. I think some
of it just has to do w/the element not actually being in focus,
although NVDA indicates that it is.

On 8/1/20, Hettie <woehler.hettie@...> wrote:
Hi all

I used the NVDA key + spacebar to activate an unsubscribe button on my
AVG account web page. I was able to tab to the wanted button but unable
to activate it. After this it was also not possible to read the screen
with the arrow keys. When my son came to assist me he saw that there was
a message on the screen asking whether I really want to unsubscribe.
That message wasn't read to me and as I douldn't navigate the screen I
didn't knew that I was supposed to react on a yes/no question.

How do I return to the normal screen after pressing the NVDA key +
spacebar?


Thanks for any help.


Hettie



--
This email has been checked for viruses by AVG.
https://www.avg.com




--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

Sean
 

Joseph, this is a great mail or article :) . I read it with all my attention. Thank you so much.

Here writes a lot of thought about NVDA’s code database.
I’m just curious about one thing:
NVDA’s code database is big.
I’m looking for a document describing NVDA’s folder layout.

  • For example, which module of NVDA is processing notifications to Action Center?

I’m very new to NVDA. I have been using it for years and now I want to support coding.
Do you know any documents or methods on this subject?
How should we consider the NVDA’s folder hierarchy?

On 02/08/2020 05:42, Joseph Lee wrote:

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

  • Some of the things I wrote are rough at times (my apologies for these).
  • The biggest takeaway is that coding is not for everyone.
  • Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

  • Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
  • I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
  • I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

  • You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
  • You are writing an essay. After all, coding is responding to an essay prompt (or two).
  • You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
  • Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
  • You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph

--

Sean

👨‍🦯 I’m programmer. I coding often Python, sometimes Go and rarely C++.


NVDA contribution guide (users edition): so you want to write and submit pull requests for NVDA...

 

Hi NVDA users,

The below post was sent to NVDA developers (including code contributors outside of NV Access) and add-on authors, but figured it would be a good idea to let you (users) see what it takes to propose, develop, and submit changes to NVDA through code. Before we get into that, a few things to note:

  • Some of the things I wrote are rough at times (my apologies for these).
  • The biggest takeaway is that coding is not for everyone.
  • Although I produced various NVDA tutorials (including tutorials on add-on development), I do not work for NV Access nor my views represent that of the organization.

 

With that out of the way:

 

Hi all,

 

While editing the latest edition of NVDA Add-on Dev Guide and in the midst of planning a pull request strategy, I thought about something that was nagging at the back of my mind and I’m sure many are wondering about: submitting pull requests. This stems from a discussion on NVDA add-ons list several weeks ago regarding add-on development strategies such as code layout and such. I hope the following serves as sort of a rough map as to how to navigate the complex landscape of pull requests for any project, specifically for NVDA.

 

One of the reasons why NVDA is popular is because people can suggest and submit changes publicly. Sometimes this is needed to keep up with technology and accessibility standards. Sometimes a braille display manufacturer would like to see drivers for their products integrated into NVDA. Sometimes people submit spelling and grammar fixes for documentation. Whatever the suggestion might be, they go through a review process – the moment a pull request is submitted, it goes through several checks, culminating in improving your work based on feedback from stable version users (I’ll talk about this phrasing later, as that is going to be important).

 

Some of you might be wondering what a pull request is. A pull request is the act of submitting changes you made to a piece of software for inclusion in the original product. It starts with you thinking about an idea, a change, or a bug, then you go through researching, coding, and testing your idea, and if you believe your idea is ready for the world, publish a pull request. The maintainer of the product you are sending a pull request for would review your idea, suggest improvements if any, and if things are looking fine, integrate it into the original product.

 

No, forget the above definition. In truth, a pull request is a collection of your thought process, research and coding skills, test cases, real-world (and sometimes hypothetical) justifications, user impact, empathy and communication, refinements, feedback, and life-long learning. A successful pull request contains ALL of these. For example, a pull request is not complete without impactful justifications, code without tests will come back to haunt you years later, and your brilliant fix becomes meaningless when you don’t show empathy and effective communication skills.

 

So I guess some of you might insist on writing pull requests. There is one more thing that makes or breaks a pull request: do you understand the project itself? I don’t want you to think that code is everything – beginning computer science and software engineering students may think that coding is all there is to it. A project, as a complete system, contains not only code, but personnel, history, culture, assumptions, norms, expectations, and impact. This is more so for a specialized project such as NVDA: screen reader users have different expectations about what it means to use computers and using software. For instance, one of the cultural artifacts of NVDA is keyboard accessibility, which is different than say, a touch-based user interface. After these warnings, if you are not willing to or not comfortable with learning to appreciate screen reading, cultural assumptions about disability, and accessibility norms, then I’m afraid that writing pull requests for NVDA might not be a good idea for you at this time.

 

I’m saying all these (in a long way) to give you this solemn warning: without understanding the context in which NVDA operates (computer accessibility and usability for people with disabilities), writing effective NVDA pull requests is impossible. Sure, we (NVDA developers and code contributors) look for coding style, test cases, and good justifications when reviewing pull requests. But what we are after is your willingness to understand the culture in which NVDA is used. Do not give us a brilliant algorithm that can solve hundreds of different IAccessible2 issues at once. Rather, let us know that you are learning the NVDA source code and culture.

 

So how do you write an effective NVDA pull request? Well, the second step is thinking carefully (the first step was the above warning). After being part of NVDA community and culture for a while (obviously you need to be familiar with bits of NVDA source code and coding style), you may come across an interesting idea, a user suggestion or two, or perhaps you found an ancient bug. Do not be tempted to start coding right away – sit down, get a drink (not alcohol please), and think about what you just heard or discovered (the latter in case you found a bug). Depending on what’s bothering you, you can think about the following:

 

  • Someone suggested something. How can I better understand what this person is talking about? If you want, start talking to the person who suggested such and such change.
  • I discovered a bug. Do I understand what this bug might be (or what the bug is), or is this something wrong with my NVDA settings? If it is truly an ancient bug, how can I reproduce it, and are there potential causes, impact, and solutions?
  • I have this brilliant idea I want to test. Can I articulate it to NVDA beginners? How can I test this idea? What will its impact be for users? What potential issues can it cause?

 

But don’t just think aloud to yourself: talk to someone. The best way to do so is searching GitHub, and if you know the idea you have (or a bug you found) wasn’t found, file a new issue. Chances are that someone will talk to you through various means (including commenting on the issue you filed); after all, humans are social beings.

 

So you talked to someone, and either you know you’re going to work on this idea or may get help from someone (or perhaps artificial intelligence might come to the rescue). If you are comfortable (and confident) enough to work on researching, coding, testing, explaining, and justifying your idea, go ahead with research, coding, and testing. Do not spend all night coding (trust me, I and many others have gone through countless all-night hackathons and regretted afterwards).

 

When you research, code, and test your idea (which may or may not become your dream pull request), keep the following in mind:

 

  • You need to read a lot. You need to prepare your mind so that when it comes time to code and test, you will know what you are up to.
  • You are writing an essay. After all, coding is responding to an essay prompt (or two).
  • You are teaching a machine to think differently. You are a movie director, an architect, a tutor, a politician (maybe that’s going too far), or any job that requires you to teach someone (or something) new skills.
  • Don’t forget to “taste your wine”. An effective software is not complete without extensive tests. And no, just compiling and running your changes does not constitute a complete test – you MUST try your best to comply with pull request expectations (including, yes, linting BEFORE you commit).
  • You are a user, after all. In other words, perform tests as though you are the person who suggested the idea you are “talking” about in your code.

 

After you think, research, code, and test your idea (or a pull request), and verifying that it is ready to be sent to NV Access for review (via GitHub), prepare to explain and justify your changes. An effective pull request is more subjective than objective. That is, how you explain and justify your changes will have great impact on acceptance of your pull request. For example, if you just tell NVDA Developers that you fixed an ancient bug without specifying what it is or how you did it, reviewers might say, “hmmm, tell us more.” Or you come up with a brilliant algorithm for fixing hundreds of IAccessible2 issues at once but do not justify the impact of your algorithm on users. The overwhelming response will be, “how will your idea affect users as they use NVDA in hundreds of different scenarios?” Or in some cases, you submit a pull request based on a user’s suggestion, thinking that it is in scope for screen reading. How reviewers react to that pull request will depend on how effective your justifications are going to be (after all, persuasion matters).

 

At some point, reviewers will review your work and either approve your idea, suggest changes, or direct you elsewhere. Do not worry if reviewers tell you that your idea does not fit NVDA and its culture; think of that decision as a way for you to reflect on your thought process. If reviewers suggest changes, think about what these are and respond accordingly (perhaps make suggested changes, discuss changes, or something else).

 

Now your pull request has been approved and integrated into NVDA. This is not the time to pop open that champagne bottle you kept for this purpose. Rather, prepare to receive feedback from users, even when your idea makes it to the next public release of NVDA. This is so that you can learn and refine your work. Also, if you are willing, take some time to help others with their pull requests (reviewing, suggesting things, researching on behalf of others if asked, or drop some occasional joke or two (joking)).

 

I did briefly mention humor as an interesting way to help others. I included it to highlight the serious and rigorous nature of writing and submitting NVDA pull requests. NVDA development through pull requests is a serious and rigorous process, as a small change you make will be used in many scenarios by thousands of users around the world. More importantly, as a seasoned code contributor (I joined NVDA community in 2012), the most important thing you should learn is understanding the culture (disability culture) in which NVDA operates – I want you to become advocates, not just programmers.

 

Before I forget: some of you might be wondering about NVDA add-on development. Although not as rigorous as NVDA itself, you should take that process seriously, as your add-on(s) will be used by many people.

 

For me, among recent pull requests I wrote, the one I’m proud of is introducing foundations to support UIA notification event. It took me days to understand the scope of the problem and work on a stable solution. The pull request that brought you UIA notification event support was merged in 2018, and we have seen refinements since.

 

Perhaps the most intriguing pull request I submitted was ability to enable and disable individual add-ons. I spent days trying to understand the internal logic required to support this scenario. I received feedback from many people on this regard, including from several core NVDA developers. Ever since this pull request was merged in 2016, many improvements were made, some of which I provided feedback on.

 

I’m sure many of you would like to contribute to NVDA for months and years to come (including for the eventual new developer hired by NV Access). But remember my warning above: coding, specifically writing and submitting pull requests is not for everyone. Writing and submitting pull requests is a serious and rigorous task, and if you are not willing to learn the culture surrounding NVDA, your pull requests will not be effective. I and other developers can teach you the inner workings of NVDA for weeks to months (or years), but it is up to potential pull request writers themselves to show willingness to make an impactful difference for a community who must now rely on the double-edged sword that is technological progress, especially given the era we live in.

 

To those writing pull requests, good luck. To those contributing in other ways, keep up the good work. Please stay safe and healthy.

Cheers,

Joseph


Re: NVDA and web buttons

Jackie
 

Just press NVDA spacebar again, Hettie. A lower beep tone is what you
want to hear.

So I suspect I'm gonna get in trouble for saying this, but I'm just
sharing my experience. Sometimes, it appears like NVDA has trouble
activating some web elements, & I often have to use a variety of
techniques if enter or spacebar doesn't work, including the NVDA f7
key, using object navigation, NVDA backspace/shift backspace to ensure
the element is in focus & then enter/spacebar/click, etc. I think some
of it just has to do w/the element not actually being in focus,
although NVDA indicates that it is.

On 8/1/20, Hettie <woehler.hettie@...> wrote:
Hi all

I used the NVDA key + spacebar to activate an unsubscribe button on my
AVG account web page. I was able to tab to the wanted button but unable
to activate it. After this it was also not possible to read the screen
with the arrow keys. When my son came to assist me he saw that there was
a message on the screen asking whether I really want to unsubscribe.
That message wasn't read to me and as I douldn't navigate the screen I
didn't knew that I was supposed to react on a yes/no question.

How do I return to the normal screen after pressing the NVDA key +
spacebar?


Thanks for any help.


Hettie



--
This email has been checked for viruses by AVG.
https://www.avg.com




--
Subscribe to a WordPress for Newbies Mailing List by sending a message to:
wp4newbs-request@... with 'subscribe' in the Subject field OR by
visiting the list page at http://www.freelists.org/list/wp4newbs
& check out my sites at www.brightstarsweb.com & www.mysitesbeenhacked.com


NVDA and web buttons

Hettie
 

Hi all

I used the NVDA key + spacebar to activate an unsubscribe button on my AVG account web page. I was able to tab to the wanted button but unable to activate it. After this it was also not possible to read the screen with the arrow keys. When my son came to assist me he saw that there was a message on the screen asking whether I really want to unsubscribe. That message wasn't read to me and as I douldn't navigate the screen I didn't knew that I was supposed to react on a yes/no question.

How do I return to the normal screen after pressing the NVDA key + spacebar?


Thanks for any help.


Hettie



--
This email has been checked for viruses by AVG.
https://www.avg.com


Re: Outlook 2016 - Cannot Open Certain Messages When NVDA is Active

Christo Vorster <christo.vorster.klavierstem@...>
 

Hi Quentin

 

It seems as if there was some kind of problem with the mail I receveid. After I installed NVDA 2020.2 and deleted the email, then requesting a re-send of the message, everything worked well.

 

Thank you, if I experience something similar, I’ll be in touch again.

 

Regards

 

Christo Vorster (Worcester, South Africa)

 

From: nvda@nvda.groups.io [mailto:nvda@nvda.groups.io] On Behalf Of Quentin Christensen
Sent: Friday, 31 July 2020 06:07
To: nvda@nvda.groups.io
Subject: Re: [nvda] NVDA PROBLEM

 

Hi Christo,

 

Could you get me a copy of your NVDA log to have a look at please, ideally at debug level?
Please send it attached to an email to info@....  Include a description of what you have done and what isn't working as it should (so I know what it's about in case I don't get to investigate today).

First of all, your NVDA key is either INSERT or CAPS LOCK, depending on how you have NVDA setup.  So, to set your log level:
1) Press NVDA+control+g to open the general settings
2) Press TAB until the focus is on 'Log level'
3) Press DOWN ARROW to get to 'Debug'
4) Press ENTER to close settings
5) Press NVDA+control+c to save settings.

To restart NVDA with add-ons disabled:
1) Press NVDA+Q
2) Down arrow to 'Restart with add-ons disabled'
3) Press ENTER

Next, recreate the issue - do whatever causes problems.

To get NVDA's log after that, there are several ways:

If NVDA is still running and usable:
1) Press NVDA+F1 to open the log viewer
2) Press CONTROL+A to select all.
3) Press CONTROL+C to copy.
4) Open your email and start a message to info@..., type a little about what you have done and what has happened in the body of the message, then leave a space and:
5) Press CONTROL+V to paste the copied log.

Instead of using the log viewer, or if NVDA has stopped and you needed to restart it or the computer:
1) Press WINDOWS+R to open Windows' Run dialog
2) Type %temp% and press ENTER (that's the percent sign, the letter t e m p and another percent sign).  Windows Explorer should open to the temporary folder.
3) Press TAB to move to the file list
4) Press N and move down to find up to three files:  nvda.log (the log file for the current or most recent NVDA session), nvda-old.og (the log from the previous session) and nvda-crash.dmp (a crash dump with more information created if NVDA itself crashes).
5) Depending on what email program you use, the steps will be different, but attach as many of those three files to an email to info@... as will be useful, and again in the body of the message describe a bit about what has happened.

 

If possible, could you please also forward a message which causes problems to me so that I can endeavour to replicate myself?  Ideally, instead of forwarding as you normally would, could you please forward as attachment?  In Outlook you can move to the message in the list, then press ALT+H, 0, 0, then F.

 

Sometimes when forwarding a message normally, the email client can alter the structure enough so that even though it looks the same, it might not cause exactly the same effects, (such as crashing NVDA).

 

Kind regards

 

Quentin.

 

On Wed, Jul 29, 2020 at 7:21 PM Christo Vorster <christo.vorster.klavierstem@...> wrote:

GAood Morning list

Please help!!

Regards

 

Christo Vorster (Worcester, south Africa)

 

This is the copy of the log:

 

INFO - __main__ (10:54:35.500) - MainThread (9268):

Starting NVDA version 2020.1

INFO - core.main (10:54:36.897) - MainThread (9268):

Config dir: C:\Users\Christo Vorster\AppData\Roaming\nvda

INFO - config.ConfigManager._loadConfig (10:54:36.897) - MainThread (9268):

Loading config: C:\Users\Christo Vorster\AppData\Roaming\nvda\nvda.ini

INFO - core.main (10:54:40.442) - MainThread (9268):

Using Windows version 10.0.19041 workstation

INFO - core.main (10:54:40.442) - MainThread (9268):

Using Python version 3.7.7 (tags/v3.7.7:d7c567b08f, Mar 10 2020, 09:44:33) [MSC v.1900 32 bit (Intel)]

INFO - core.main (10:54:40.442) - MainThread (9268):

Using comtypes version 1.1.7

INFO - core.main (10:54:40.442) - MainThread (9268):

Using configobj version 5.1.0 with validate version 1.0.1

INFO - synthDriverHandler.setSynth (10:54:48.280) - MainThread (9268):

Loaded synthDriver ibmeci

INFO - core.main (10:54:49.218) - MainThread (9268):

Using wx version 4.0.3 msw (phoenix) wxWidgets 3.0.5 with six version 1.12.0

INFO - brailleInput.initialize (10:54:49.220) - MainThread (9268):

Braille input initialized

INFO - braille.initialize (10:54:49.228) - MainThread (9268):

Using liblouis version 3.12.0

INFO - braille.initialize (10:54:49.241) - MainThread (9268):

Using pySerial version 3.4

INFO - braille.BrailleHandler.setDisplayByName (10:54:51.145) - MainThread (9268):

Loaded braille display driver noBraille, current display has 0 cells.

INFO - core.main (10:54:53.007) - MainThread (9268):

Java Access Bridge support initialized

INFO - _UIAHandler.UIAHandler.MTAThreadFunc (10:54:53.272) - _UIAHandler.UIAHandler.MTAThread (7440):

UIAutomation: IUIAutomation6

INFO - core.main (10:55:00.063) - MainThread (9268):

NVDA initialized

ERROR - eventHandler.executeEvent (11:07:11.977) - MainThread (9268):

error executing event: gainFocus on <appModules.outlook.UIAGridRow object at 0x079A43B0> with extra args of {}

Traceback (most recent call last):

  File "eventHandler.pyc", line 155, in executeEvent

  File "eventHandler.pyc", line 92, in __init__

  File "eventHandler.pyc", line 100, in next

  File "NVDAObjects\__init__.pyc", line 1102, in event_gainFocus

  File "NVDAObjects\behaviors.pyc", line 611, in reportFocus

  File "NVDAObjects\__init__.pyc", line 988, in reportFocus

  File "speech\__init__.pyc", line 469, in speakObject

  File "speech\__init__.pyc", line 506, in getObjectSpeech

  File "speech\__init__.pyc", line 377, in getObjectPropertiesSpeech

  File "baseObject.pyc", line 42, in __get__

  File "baseObject.pyc", line 145, in _getPropertyViaCache

  File "appModules\outlook.pyc", line 445, in _get_name

  File "comtypesMonkeyPatches.pyc", line 26, in __call__

_ctypes.COMError: (-2146233083, None, (None, None, None, 0, None))

ERROR - eventHandler.executeEvent (11:07:46.564) - MainThread (9268):

error executing event: gainFocus on <appModules.outlook.OutlookWordDocument object at 0x0708E250> with extra args of {}

Traceback (most recent call last):

  File "speech\__init__.pyc", line 512, in getObjectSpeech

  File "documentBase.pyc", line 24, in makeTextInfo

  File "NVDAObjects\window\winword.pyc", line 673, in __init__

AttributeError: 'NoneType' object has no attribute 'range'

 

During handling of the above exception, another exception occurred:

 

Traceback (most recent call last):

  File "eventHandler.pyc", line 155, in executeEvent

  File "eventHandler.pyc", line 92, in __init__

  File "eventHandler.pyc", line 100, in next

  File "NVDAObjects\__init__.pyc", line 1102, in event_gainFocus

  File "NVDAObjects\__init__.pyc", line 988, in reportFocus

  File "speech\__init__.pyc", line 469, in speakObject

  File "speech\__init__.pyc", line 527, in getObjectSpeech

  File "documentBase.pyc", line 24, in makeTextInfo

  File "NVDAObjects\window\winword.pyc", line 678, in __init__

AttributeError: 'NoneType' object has no attribute 'range'

ERROR - eventHandler.executeEvent (11:07:46.574) - MainThread (9268):

error executing event: caret on <appModules.outlook.OutlookWordDocument object at 0x0708E250> with extra args of {}

Traceback (most recent call last):

  File "eventHandler.pyc", line 155, in executeEvent

  File "eventHandler.pyc", line 92, in __init__

  File "eventHandler.pyc", line 100, in next

  File "NVDAObjects\IAccessible\winword.pyc", line 47, in event_caret

  File "documentBase.pyc", line 24, in makeTextInfo

  File "NVDAObjects\window\winword.pyc", line 673, in __init__

AttributeError: 'NoneType' object has no attribute 'range'

ERROR - eventHandler.executeEvent (11:07:46.595) - MainThread (9268):

error executing event: caret on <appModules.outlook.OutlookWordDocument object at 0x0708E250> with extra args of {}

Traceback (most recent call last):

  File "eventHandler.pyc", line 155, in executeEvent

  File "eventHandler.pyc", line 92, in __init__

  File "eventHandler.pyc", line 100, in next

  File "NVDAObjects\IAccessible\winword.pyc", line 47, in event_caret

  File "documentBase.pyc", line 24, in makeTextInfo

  File "NVDAObjects\window\winword.pyc", line 673, in __init__

AttributeError: 'NoneType' object has no attribute 'range'

 

 

 

I have a problem opening certain emails in Outlook 2016.

 

If NVDA is turned off, the specific mails can be opened.

 

I copied the View Log after I experienced the problem.

 

Would it help if I uninstall, and then re-install NVDA?

 

 


 

--

Quentin Christensen
Training and Support Manager