[nvda-addons] Re: Developing Addons - The best way to get started?

  • From: driemer.riemer@xxxxxxxxx
  • To: nvda-addons@xxxxxxxxxxxxx
  • Date: Wed, 13 Apr 2016 17:48:56 -0600

Sweet. I have been nipped buy it that way too many times for my own benefit and 
I have definitely hopefully learned lesson I think.

Sent from my heavily encrypted iPhone.
Please disregard errors as this is a smaller device.

On Apr 13, 2016, at 16:40, Damien Sykes-Pendleton 
<damien@xxxxxxxxxxxxxxxxxxxx> wrote:

Hi Derek,
Oh don’t worry, I do. The only thing I don’t have set up yet is an offsite 
backup. Other than that, I back up to six drives now.
Kind regards,
Damien.
 
From: derek riemer
Sent: Wednesday, April 13, 2016 11:29 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Developing Addons - The best way to get started?
 
Hi,
You should make a regular backup so that you don't loose work.
Cheers.

On 4/12/2016 11:27 AM, Damien Sykes-Pendleton wrote:
Hi Derek,
A long time ago, I tried to make an addon that would speak information that 
was not being read out automatically. I think I used another addon as a 
starting point but I had no idea as to what the problem was or what my 
particular circumstances were. For instance, to the computer controls are 
physical graphical objects with coordinates, dimensions, events, states, and 
all these different identifying factors that make it what it is. I know 
nothing about this – all I know is what information isn’t being read out. 
I’m not even sure if it is a control that is at fault here, since all it is 
is text.
It’s not like I can even go back and refer to it, since my computer crashed 
since then, so I’d have to more or less write it from scratch.
Cheers.
Kind regards,
Damien.
 
From: derek riemer
Sent: Tuesday, April 12, 2016 5:59 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Developing Addons - The best way to get started?
 
Hi,
It really depends what you intend your add-on to do. Do you think some code 
should execute? Test it by either importing logHandler, and logging with one 
of the methods there, or use tones.beep to beep as the first thing that 
happens in that function. Also, it shouldn't play the error sound unless you 
are running master or next. Look for errors in your log, test your add-on 
with master or next, or go to the NVDA python console and run >>> import 
versionInfo
versionInfo.isTestVersion = True
Then the sound should happen. You could write an add-on to set this to true 
at NVDA Startup (Hint) just putting that in a python file in the 
globalPlugins folder should do it. Do not be afraid to ask us questions if 
you have a hypothesis about some control, and a way in which you are trying 
to make it work. I promise you, there are no dumb questions here. If it is a 
script, be sure to bind it to a gesture. If it is one of the meriad of 
events, then you may very well just have to play with trying multiple events 
until you find the right one. That's where making NVDA play different tones 
for different events is super helpful.
HTH

On 4/12/2016 10:32 AM, Damien Sykes-Pendleton wrote:
Hi there,
OK. So I now have a fair grasp of the Python language. Luckily because I’ve 
tried so many times before and failed it was just a case of refreshing my 
memory as to what different things meant, and reading more in-depth those 
things that I didn’t understand. I think it kind of helped that the easy 
stuff was, well, easy, and the harder stuff I have covered before in other 
languages, but they are termed or written differently. I think one thing 
that confused me a lot when I started out is how all classes inherit from 
object, when an instance of a class is also called an object. Wow...Deep 
stuff.
Also, this time, I have seen Python code in action, having installed Python 
itself. It’s odd, but I think that helped me more than I realised it would. 
Reading code and then seeing it work seems to impress things more firmly 
into memory (Human, that is).
Now that I’ve done that, it seems when I tried this before that the thing I 
was struggling with most were NVDA concepts. There were no errors triggered 
(At least I don’t think), but the addon itself that I created didn’t work.
Is there anything else I need to look at? The development guide has become 
a little easier in some respects but I’m still in the dark about others, 
for instance application controls, accessing them, reading them, event 
triggers,      etc.
Thanks.
Kind regards,
Damien.
 
From: derek riemer
Sent: Friday, April 08, 2016 6:17 PM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: Developing Addons - The best way to get started?
 
Hi,
Please feel free to ask us (especially me) anyy development questions you 
have. I can try to help. Please believe me when I say I know where you are 
coming from, I had to learn all this myself, and it is damn hard. Even if 
you ask "This button is not speaking, How should I try to make it speak?" I 
will try to walk you in the right direction.

On 4/8/2016 5:56 AM, Damien Sykes-Pendleton wrote:
Hi James, 
Again. This proves just how much, or little, knowledge I have on this 
subject. I always assumed that the information that NVDA uses to evaluate 
the functionality or purpose of a control was through the Windows API. 
When I wrote my first addon that didn't involve copying and pasting from 
an example, it was to read content that NVDA didn't recognise on its own 
for whatever reason, that other screen readers did. This didn't work. My 
theory for this is that I was pretty much guessing what I had to do to get 
it to work, and of course that is not the way to understand your own code. 
It helps to understand what your code needs to do, something of which I 
understood very little, if not nothing at all. If you can't understand 
that, you need to be able to understand what you want to do. Although I 
know what I want to do in terms of functionality, translating that into 
code is very difficult, given that I don't know about all the underlying 
structures such as in-depth control information (ID, handle, class etc), 
NVDA objects, accessibility platforms, the list goes on and on. 
As for learning Python itself, this is not so much the problem as 
remembering every single thing I'm reading. When I look at a Python 
tutorial, I'm thinking, yes this makes sense. Sounds good to me. Oh wow, 
I've finished the tutorial. Let's go back to addons. Oh wait, what did the 
tutorial say about this? I don't remember that part...Look back at the 
tutorial. Oh, it's not in here. This must be an NVDA specific reference. 
Either that, or, Ah yes, I remember this now. Now how was the addon guide 
referencing this? 
I'm trying to explain it the best way I can, because there isn't one 
specific example or situation that I can pinpoint without referencing 
something else, it's all linked, hence the massive confusion which, if 
we're talking code, is making my brain go into an infinite loop. 
Kind regards, 
Damien. 
-----Original Message----- From: James Scholes 
Sent: Friday, April 08, 2016 12:25 PM 
To: nvda-addons@xxxxxxxxxxxxx 
Subject: [nvda-addons] Re: Developing Addons - The best way to get 
started? 

Replies inline. 

Damien Sykes-Pendleton wrote: 
Well if we're constraining ourselves to the facts, I can only really 
say what I have said before, in that the developer guide assumes a 
good working knowledge of Python and NVDA's internal workings, 
neither of which I feel I have enough of to really get going.

First, tackle Python.  You need a good, working knowledge of the 
language to write NVDA add-ons.  This will never change, no matter how 
much documentation is written.  Create some small Python projects which 
make use of object-oriented programming, inheritance, wxPython. 

It is incredibly important to understand that creating NVDA add-ons is 
not at all like writing JAWS scripts.  With JAWS scripting, the language 
is proprietary and the creators of that language decide in advance what 
functionality you have access to.  NVDA not only gives you the full 
power of the Python language, but also lets you write code which runs in 
the same environment as NVDA's core, meaning that you can literally do 
whatever you like, only constrained by your imagination and knowledge. 
Naturally, this provides a lot of room for error, so NVDA add-on writing 
often comes with a  lot of responsibility.  That is why there is a 
higher barrier to entry.  It's up to you to decide whether that barrier 
is worth scaling or not.  But nobody, on this list or otherwise, 
will ever be able to create documentation that explains every possible 
aspect of creating NVDA add-ons.  Having said that, the community has 
created some extra documentation, which I will leave it up to them to 
share. 

I have looked into Python, both on the official language tutorial 
and from Learn Python the Hard Way. Although these are both good 
resources, they are also very extensive to the point that by the 
time I have read them and gone back to the developer guide, I'm 
trying to conceptualise everything else into Python terms rather than 
NVDA terms

I'm not entirely sure what you mean here.  NVDA is Python.  Granted, to 
write a good add-on, you have to be aware of some of NVDA's internals, 
but really, you need to give us examples of what you're trying to do and 
why it's posing a problem.  If you have a good understanding of Python 
as I said above, writing NVDA add-on boilerplate will be easy. 

some of which can be done but easily forgotten, or others which can't 
be done at all.

Again, I have no idea what you mean.  What Python features, 
functionality or concepts are you having difficulty translating into 
valid concepts to be used in an NVDA add-on? 

Then, as I have also said before, there 
is the vagueness of references, such as "Refer to the NVDA code 
documentation". I cannot find this documentation anywhere, even in 
the NVDA source code.

If you check out the NVDA source code and read the accompanying readme 
files, you will see instructions on generating the NVDA code 
documentation.  You can also browse an online copy, although I don't 
think it's updated on a regular basis, at: 
https://files.derekriemer.com/nvda/module-tree.html ;

Honestly though, I think most NVDA developers will tell you that reading 
the code itself is usually better than the documentation.  If you're 
hoping that the code documentation will shine a light on everything that 
has hitherto seemed confusing, you'll be seriously disappointed.  The 
code documentation is constructed from Python docstrings.  It's a terse 
reference, not a guide. 

Even so, I doubt I'd be able to glean much 
from it, since NVDA has a lot of in-depth interaction with the 
operating system which, when it comes to development, I know hardly 
anything about the workings of. This then also adds the Windows API 
to my reference list, and now I feel like I am on a road of 
information overload.

Any portions of the Windows API that are used by NVDA have already been 
wrapped as simple Python functions for use in higher level abstractions. 
Unless you need to use a part of it that hasn't already been defined as 
such, you don't need to understand the ins and outs of that. 
Additionally, it's highly unlikely that, for your first add-ons, you'll 
even need to use such functionality.  Rather, you'll interact with the 
abstractions that NVDA provides. 

To sum up: 
1. Learn Python.  If you don't know the language, if you can't write 
scripts or small programs in it, you will have a hard time writing code 
for NVDA. 
2. Get familiar with reading other people's Python code.  You'll be 
doing a lot of that if you want to create high quality add-ons. 
3. Give us examples of things you're finding hard.  We don't need an 
article, we just need you to explain what you don't understand so we can 
point you in the right direction. 
4. Don't run before you can walk.  If you're struggling with how to 
create the most basic of add-ons, the Windows API isn't even a distant 
concern.

-- 
Derek Riemer

Department of computer science, third year undergraduate student.
Proud user of the NVDA screen reader.
Open source enthusiast.
Member of Bridge Cu
Avid skiier.
Websites: 
Honors portfolio 
Awesome little hand built weather app! 

mailto:derek.riemer@xxxxxxxxxxxx ;
Phone: (303) 906-2194


-- 
Derek Riemer

Department of computer science, third year undergraduate student.
Proud user of the NVDA screen reader.
Open source enthusiast.
Member of Bridge Cu
Avid skiier.
Websites: 
Honors portfolio 
Awesome little hand built weather app! 

mailto:derek.riemer@xxxxxxxxxxxx ;
Phone: (303) 906-2194


-- 
Derek Riemer

Department of computer science, third year undergraduate student.    
Proud user of the NVDA screen reader.
Open source enthusiast.
Member of Bridge Cu
Avid skiier.
Websites: 
Honors portfolio 
Awesome little hand built weather app! 

mailto:derek.riemer@xxxxxxxxxxxx ;
Phone: (303) 906-2194

Other related posts: