For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Joseph Lee

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Cory Samaha-2
Hi Joseph,
I definitely think, and love the idea of an object model / functions reference wiki article explaining the equivalents.  That’s not to say that an add-on wouldn’t be useful, but I wouldn’t want to get in the habit of using it too  much as a crutch.  I think if we have a document that points out all the equivalents that would be invaluable and probably my first goto document when I’m stuck.  Of course, that’s just my opinion and I’m sure others will weigh in.  Between this and the documentation you have already written this will certainly ease the transition.  Thank you for all of the hard work that you have put into this project to date.

Regards,
Cory
On May 31, 2017, at 4:39 AM, Joseph Lee <[hidden email]> wrote:

Hi all, mostly for JAWS and/or Window-Eyes scripters:
 
I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:
 
As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.
 
In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:
 
  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage
 
The ad-on version would be something like:
 
From globalPlugins.whateverTheNameWillBe.jaws import *
 
sayMessage(string)
->
Speech.speakMessage(string)
 
Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.
 
Comments are appreciated.
Cheers,
Joseph
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Kaveinthran Pulanthran
hello,

I defenetly welcome ittt with few suggestions.

1. will be convenient if it is available for both online and offline use.
2. variety of formats such as html zip, pdfs, chm and txt will suits many
3. object oriented stuff and how it differs for python should be
covered more deep and detailed,

thanks and heads up for your good work!

On 5/31/17, Cory Samaha <[hidden email]> wrote:

> Hi Joseph,
> I definitely think, and love the idea of an object model / functions
> reference wiki article explaining the equivalents.  That’s not to say that
> an add-on wouldn’t be useful, but I wouldn’t want to get in the habit of
> using it too  much as a crutch.  I think if we have a document that points
> out all the equivalents that would be invaluable and probably my first goto
> document when I’m stuck.  Of course, that’s just my opinion and I’m sure
> others will weigh in.  Between this and the documentation you have already
> written this will certainly ease the transition.  Thank you for all of the
> hard work that you have put into this project to date.
>
> Regards,
> Cory
>> On May 31, 2017, at 4:39 AM, Joseph Lee <[hidden email]>
>> wrote:
>>
>> Hi all, mostly for JAWS and/or Window-Eyes scripters:
>>
>> I’m looking at FSDN functions reference and Window-Eyes object model docs
>> at the moment, and was wondering if you have comments about the following
>> proposal:
>>
>> As part of developer side of Project Contact Lenses, I’m looking into
>> creating a functions reference wiki, a source code compatibility layer
>> add-on or both. Having a handy reference manual for those coming from
>> other screen readers could help some of you in porting your scripts easier
>> by looking at functions NVDA expects. On the other hand, having an add-on
>> (a global plugin, in fact) that lets you call familiar functions and have
>> it translate into equivalent code path in NVDA may help some in gradually
>> porting your source code.
>>
>> In case of the wiki, it’ll consist of tables that list routines you may
>> wish to do, followed by functions in other screen readers and NVDA
>> equivalent like so:
>>
>> Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage
>>
>> The ad-on version would be something like:
>>
>> From globalPlugins.whateverTheNameWillBe.jaws import *
>>
>> sayMessage(string)
>> ->
>> Speech.speakMessage(string)
>>
>> Ultimately, for best experience, it would be best to call functions and
>> use objects provided by NVDA, but in the interim, having a compatibility
>> layer add-on and/or a functions reference wiki could help. In case of an
>> add-on, I’ll host a public repository on GitHub so anyone can fork and
>> submit pull requests, and the initial version will define popular
>> functions from JAWS and/or Window-Eyes.
>>
>> Comments are appreciated.
>> Cheers,
>> Joseph
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org/>!
>> http://sdm.link/slashdot_______________________________________________
>> <http://sdm.link/slashdot_______________________________________________>
>> Nvda-devel mailing list
>> [hidden email]
>> <mailto:[hidden email]>
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>> <https://lists.sourceforge.net/lists/listinfo/nvda-devel>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Damien Sykes-Pendleton
In reply to this post by Joseph Lee
Hi,
This message is quite lengthy and possibly even rambly, but it expresses my opinions while enlightening you to my strengths and weaknesses, so bare with me.
Having previously worked on JAWS and Dolphin Supernova scripting before I switched over to NVDA, I have already started a similar system covering the two readers, along with a set of tutorials similar to those produced by FS and Dolphin to help the transition.
I mainly wrote it for me but have received popular requests to release it once completed. I felt that, having taken me approximately four years to bring my dream of making addons or, more long term, working with the core itself to life, I didn’t want new users to experience the same tripping points that I did. In fact, my tutorials give long introductions on Python, Git, SCons etc so that things are absolutely clear from the word go.
It’s by no means complete, I’ve never messed with WindowEyes in my life for a start, and I have no idea on how accurate my information is for a second, so perhaps some collaboration might be possible on the materials we already have and perhaps make a wrapper layer covering all screenreaders.
I believe it will make things a lot less intimidating. Switching from a proprietary screenreader where all your references and tutorials have to be accurate, detailed, and easily obtainable, to an open source version where all your information is scattered, perhaps incomplete, and vague, for beginners of Python and especially for programming beginners, and where reference guides have to be built manually, straight from the source code, to me, was exceptionally intimidating, hence the reason it took me so long to get to where I am now, whereas when all said and done I could have probably picked it up in two to four weeks had it been more contained and detailed.
 
Take a trip into a certain Damien’s mind from 2010 to 2017 and consider the following:
 
2010: Five steps to Jaws scripting:
1. Look at the help for the script manager.
2. Links to download the FSDN and scripting tutorial are right there. Except I don’t think it was called that back then.
3. Learn from the tutorial, which is detailed enough to where you can look at the FSDN like any other scripting tutorial and more or less know exactly what you're doing.
4. Look at the FSDN and marvel how easy it is to find what you need.
5. Reinforce and confirm your knowledge with an audio scripting tutorial.
Total time: Approx 2 months.
Granted. This is an internal, even possibly custom-built scripting language which is easy to document and doesn’t need any external godly forces to use.
 
2012: Five steps to scripting Supernova:
1. Go to the scripting engine.
2. Click on help. Believe it or not, the tutorial is right there.
3. Read a bit and feel slightly intimidated that it uses a scripting language called LUA.
4. Hang on...Read a bit further and it gives you the essential introduction to LUA right there. Even though it specifically states its function is not to teach you LUA! Theoretically the only time you need to look at LUA is if you want to make use of LUA’s standard library.
5. Again, read on, study the reference, happy days.
Total time: Approx 1 month.
An in-between. You don’t need LUA because it comes prebuilt and prepackaged in the scripting engine. They document the basics of LUA and a tutorial on using the Dolphin API, so even then you don’t have to look at the LUA docs all that much. Again, pretty easy to build your stuff.
 
2013-2017: A nightmare to scripting NVDA:
1. Download NVDA and explore.
2. In tools, you see Python Console. You might know from some conversation or other that Python is a scripting language. Automatically you might think, "Hey. NVDA's answer to scripting." Wrong.
3. The user guide mentions the Python console and refers you to the NVDA GitHub page (or in my case back in 2013, the self-hosted community page). Fumble and stumble around there aimlessly until you suddenly reach "developer guide".
4. This guide dedicates two of its six chapters to scripting addons and plugins, and from the very beginning you're asking questions. "Where is the code documentation? What are events, scripts and bindings? What on earth is class inheritance? appModuleHandler.AppModule/globalPluginHandler.GlobalPlugin?" Luckily for me I at least knew what class inheritance was, but only very vaguely. I had only used it twice, and in a different language.
5. You are fortunately told that scripts are Python files. OK. Let's look at the Python tutorial, which itself is something like 140 subsections long. Even then, in some areas, it expects some degree of advanced programming knowledge as it goes into various aspects as to how Python works internally.
6. Spend money to buy a Python basics book. OK. You now have a relative idea of how Python works. How do I make this plugin again?
7. Back to NVDA developer guide. OK, can I remember why we have dot identifiers? Ah. Objects and modules. So is this an object, or is it a module? Or even a package!
8. You think you've exhausted everything. Right. Where do we get the code documentation?
9. Back to the NVDA GitHub/community site. No link to it there.
10. Pretty much scour the repository and/or wiki pages. Hang on, we have to build the docs manually? Even worse, from the Python source code?
11. Read another in-depth tutorial, this time on Git. Most of which you probably don't need to know for this.
12. Clone NVDA and worry that you might have broken something because you've never used Git before in your life.
13. Install Python, even if you haven't and possibly won't use it as a primary development environment.
14. Make sure you have Pip. Even in Windows you sometimes have to conform to advanced Linux concepts. Bleh.
15. Install SCons. To be on the safe side, install all NVDA's dependencies, again despite the fact you'll probably never use them.
16. Break your system in the process because one of them is Visual Studio which goes through a ridiculous number of versions, support options and SDK's and you happen to have installed the wrong one and it insists that your evaluation licence has expired despite having never touched it.
17. Worry if you've broken anything else. All these development environments, you've no idea what shinanikins they're going to put in the registry or what advanced piece of skulduggery they're going to have you do, either automatically or manually by way of its rocket-scientists documentation.
18. Finally, just finally, build the relevant documentation.
19. Puzzle over the documentation because the index is showing you item after item after item that are all the same. For instance, just look at the number of functions that call themselves speak...
20. In the end you're probably best looking at the Python modules themselves because then you know what is being called from where, and there's nothing telling you how you're supposed to make use of this documentation. If you don’t know Python it takes you longer because you’re looking stuff up all the time. But at least you have more of a lead.
21. Sit there and wonder if you need the NVDAHelper documentation.
22. Screw it. Let's make my own simpler system. Growl and grin.
 
Of course not everyone has been haunted by the same frustrations. There are many people who are well trained, seasoned programmers, I’m guessing especially on this list given that it deals mainly with core development, who are used to working with fully fledged development environments, version control, automated building, package managers and dependency control, near enough every day. To me, they are the sort of complicated wizardry that I might expect to find on a Linux system, Note my own personal definition of Linux: “A system for people, mainly developers and network administrators, who are more expert than Bill Gates” (I freak out with Linux – either it never works or I blow a catastrophic accident). Needless to say, I have generally been Windows in and out and have only recently started making use of version control, and even then not to its full potential. Had it not been for an in-depth, hour long introduction to Fossil by a friend of mine, which is very similar in some ways to Git, and the very helpful concept of Git command aliasing, I probably still wouldn’t be developing and releasing addons even now. All the other systems just go way above and beyond my scope of understanding and so the only way I could expect it to work is by following the letter and praying to the heavens above that I haven’t screwed up and conked out my whole system in the process.
 
I have a feeling this is why we only have a small number of addons. Look for JAWS scripts, there are pages and pages and pages full of them. Look for NVDA addons, there are probably 50. My opinion is that this has needed to happen for quite some time, and I'm glad that it has finally become a possibility.
 
Of course working on the core is an entirely different matter – NVDA itself is a huge system and so ideally needs a structured organisation and workflow, which it has, and so you would expect to be used to working in that sort of environment before messing about with it. If it was your first time you’d have to build up. But in my opinions building addons shouldn’t be half, or even a tenth as complicated as that.
 
Cheers.
Damien.
 
 
Sent: Wednesday, May 31, 2017 9:39 AM
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?
 

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Brian's Mail list account BY
Yes the ascending tones are played as it loads, but there is nothing to stop
you altering them I suppose if you could make it  only use default sounds in
certain circumstances.  I tested the new ones in next with a person of,
ahem, older years and some they could not here so I've tweaked those that
gave problems in this zip file.

https://www.dropbox.com/s/hkkz61mwjxjsqbk/waves.zip?dl=1

I'd rather like to here the devs point of view on this one as I can see why
the new ones could be appealing but wondered if they had considered those
with less than optimal hearing.?
 Brian

[hidden email]
Sent via blueyonder.
Please address personal email to:-
[hidden email], putting 'Brian Gaff'
in the display name field.
----- Original Message -----
From: "Damien Sykes-Lindley" <[hidden email]>
To: "NVDA screen reader development" <[hidden email]>
Sent: Wednesday, May 31, 2017 12:33 PM
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you
like a source code compatibility layer add-on, functions reference wiki, or
both?


Hi,
This message is quite lengthy and possibly even rambly, but it expresses my
opinions while enlightening you to my strengths and weaknesses, so bare with
me.
Having previously worked on JAWS and Dolphin Supernova scripting before I
switched over to NVDA, I have already started a similar system covering the
two readers, along with a set of tutorials similar to those produced by FS
and Dolphin to help the transition.
I mainly wrote it for me but have received popular requests to release it
once completed. I felt that, having taken me approximately four years to
bring my dream of making addons or, more long term, working with the core
itself to life, I didn’t want new users to experience the same tripping
points that I did. In fact, my tutorials give long introductions on Python,
Git, SCons etc so that things are absolutely clear from the word go.
It’s by no means complete, I’ve never messed with WindowEyes in my life for
a start, and I have no idea on how accurate my information is for a second,
so perhaps some collaboration might be possible on the materials we already
have and perhaps make a wrapper layer covering all screenreaders.
I believe it will make things a lot less intimidating. Switching from a
proprietary screenreader where all your references and tutorials have to be
accurate, detailed, and easily obtainable, to an open source version where
all your information is scattered, perhaps incomplete, and vague, for
beginners of Python and especially for programming beginners, and where
reference guides have to be built manually, straight from the source code,
to me, was exceptionally intimidating, hence the reason it took me so long
to get to where I am now, whereas when all said and done I could have
probably picked it up in two to four weeks had it been more contained and
detailed.

Take a trip into a certain Damien’s mind from 2010 to 2017 and consider the
following:

2010: Five steps to Jaws scripting:
1. Look at the help for the script manager.
2. Links to download the FSDN and scripting tutorial are right there. Except
I don’t think it was called that back then.
3. Learn from the tutorial, which is detailed enough to where you can look
at the FSDN like any other scripting tutorial and more or less know exactly
what you're doing.
4. Look at the FSDN and marvel how easy it is to find what you need.
5. Reinforce and confirm your knowledge with an audio scripting tutorial.
Total time: Approx 2 months.
Granted. This is an internal, even possibly custom-built scripting language
which is easy to document and doesn’t need any external godly forces to use.

2012: Five steps to scripting Supernova:
1. Go to the scripting engine.
2. Click on help. Believe it or not, the tutorial is right there.
3. Read a bit and feel slightly intimidated that it uses a scripting
language called LUA.
4. Hang on...Read a bit further and it gives you the essential introduction
to LUA right there. Even though it specifically states its function is not
to teach you LUA! Theoretically the only time you need to look at LUA is if
you want to make use of LUA’s standard library.
5. Again, read on, study the reference, happy days.
Total time: Approx 1 month.
An in-between. You don’t need LUA because it comes prebuilt and prepackaged
in the scripting engine. They document the basics of LUA and a tutorial on
using the Dolphin API, so even then you don’t have to look at the LUA docs
all that much. Again, pretty easy to build your stuff.

2013-2017: A nightmare to scripting NVDA:
1. Download NVDA and explore.
2. In tools, you see Python Console. You might know from some conversation
or other that Python is a scripting language. Automatically you might think,
"Hey. NVDA's answer to scripting." Wrong.
3. The user guide mentions the Python console and refers you to the NVDA
GitHub page (or in my case back in 2013, the self-hosted community page).
Fumble and stumble around there aimlessly until you suddenly reach
"developer guide".
4. This guide dedicates two of its six chapters to scripting addons and
plugins, and from the very beginning you're asking questions. "Where is the
code documentation? What are events, scripts and bindings? What on earth is
class inheritance?
appModuleHandler.AppModule/globalPluginHandler.GlobalPlugin?" Luckily for me
I at least knew what class inheritance was, but only very vaguely. I had
only used it twice, and in a different language.
5. You are fortunately told that scripts are Python files. OK. Let's look at
the Python tutorial, which itself is something like 140 subsections long.
Even then, in some areas, it expects some degree of advanced programming
knowledge as it goes into various aspects as to how Python works internally.
6. Spend money to buy a Python basics book. OK. You now have a relative idea
of how Python works. How do I make this plugin again?
7. Back to NVDA developer guide. OK, can I remember why we have dot
identifiers? Ah. Objects and modules. So is this an object, or is it a
module? Or even a package!
8. You think you've exhausted everything. Right. Where do we get the code
documentation?
9. Back to the NVDA GitHub/community site. No link to it there.
10. Pretty much scour the repository and/or wiki pages. Hang on, we have to
build the docs manually? Even worse, from the Python source code?
11. Read another in-depth tutorial, this time on Git. Most of which you
probably don't need to know for this.
12. Clone NVDA and worry that you might have broken something because you've
never used Git before in your life.
13. Install Python, even if you haven't and possibly won't use it as a
primary development environment.
14. Make sure you have Pip. Even in Windows you sometimes have to conform to
advanced Linux concepts. Bleh.
15. Install SCons. To be on the safe side, install all NVDA's dependencies,
again despite the fact you'll probably never use them.
16. Break your system in the process because one of them is Visual Studio
which goes through a ridiculous number of versions, support options and
SDK's and you happen to have installed the wrong one and it insists that
your evaluation licence has expired despite having never touched it.
17. Worry if you've broken anything else. All these development
environments, you've no idea what shinanikins they're going to put in the
registry or what advanced piece of skulduggery they're going to have you do,
either automatically or manually by way of its rocket-scientists
documentation.
18. Finally, just finally, build the relevant documentation.
19. Puzzle over the documentation because the index is showing you item
after item after item that are all the same. For instance, just look at the
number of functions that call themselves speak...
20. In the end you're probably best looking at the Python modules themselves
because then you know what is being called from where, and there's nothing
telling you how you're supposed to make use of this documentation. If you
don’t know Python it takes you longer because you’re looking stuff up all
the time. But at least you have more of a lead.
21. Sit there and wonder if you need the NVDAHelper documentation.
22. Screw it. Let's make my own simpler system. Growl and grin.

Of course not everyone has been haunted by the same frustrations. There are
many people who are well trained, seasoned programmers, I’m guessing
especially on this list given that it deals mainly with core development,
who are used to working with fully fledged development environments, version
control, automated building, package managers and dependency control, near
enough every day. To me, they are the sort of complicated wizardry that I
might expect to find on a Linux system, Note my own personal definition of
Linux: “A system for people, mainly developers and network administrators,
who are more expert than Bill Gates” (I freak out with Linux – either it
never works or I blow a catastrophic accident). Needless to say, I have
generally been Windows in and out and have only recently started making use
of version control, and even then not to its full potential. Had it not been
for an in-depth, hour long introduction to Fossil by a friend of mine, which
is very similar in some ways to Git, and the very helpful concept of Git
command aliasing, I probably still wouldn’t be developing and releasing
addons even now. All the other systems just go way above and beyond my scope
of understanding and so the only way I could expect it to work is by
following the letter and praying to the heavens above that I haven’t screwed
up and conked out my whole system in the process.

I have a feeling this is why we only have a small number of addons. Look for
JAWS scripts, there are pages and pages and pages full of them. Look for
NVDA addons, there are probably 50. My opinion is that this has needed to
happen for quite some time, and I'm glad that it has finally become a
possibility.

Of course working on the core is an entirely different matter – NVDA itself
is a huge system and so ideally needs a structured organisation and
workflow, which it has, and so you would expect to be used to working in
that sort of environment before messing about with it. If it was your first
time you’d have to build up. But in my opinions building addons shouldn’t be
half, or even a tenth as complicated as that.

Cheers.
Damien.


From: Joseph Lee
Sent: Wednesday, May 31, 2017 9:39 AM
To: 'NVDA screen reader development'
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like
a source code compatibility layer add-on, functions reference wiki, or both?

Hi all, mostly for JAWS and/or Window-Eyes scripters:



I’m looking at FSDN functions reference and Window-Eyes object model docs at
the moment, and was wondering if you have comments about the following
proposal:



As part of developer side of Project Contact Lenses, I’m looking into
creating a functions reference wiki, a source code compatibility layer
add-on or both. Having a handy reference manual for those coming from other
screen readers could help some of you in porting your scripts easier by
looking at functions NVDA expects. On the other hand, having an add-on (a
global plugin, in fact) that lets you call familiar functions and have it
translate into equivalent code path in NVDA may help some in gradually
porting your source code.



In case of the wiki, it’ll consist of tables that list routines you may wish
to do, followed by functions in other screen readers and NVDA equivalent
like so:



  a.. Say something: JAWS: SayMessage; NVDA: ui.message or
speech.speakMessage


The ad-on version would be something like:



From globalPlugins.whateverTheNameWillBe.jaws import *



sayMessage(string)

->

Speech.speakMessage(string)



Ultimately, for best experience, it would be best to call functions and use
objects provided by NVDA, but in the interim, having a compatibility layer
add-on and/or a functions reference wiki could help. In case of an add-on, I’ll
host a public repository on GitHub so anyone can fork and submit pull
requests, and the initial version will define popular functions from JAWS
and/or Window-Eyes.



Comments are appreciated.

Cheers,

Joseph



--------------------------------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


--------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel



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


> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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


> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Travis Roth
In reply to this post by Joseph Lee

Hi,

 

Add-on compatibility layer comment: I’d say no to this because if have to rewrite/adapt a script anyways I’d just as well use the time to learn the NVDA way. Plus this seems like a maintenance nightmare long-term.

 

Wiki comments: Yes. As you describe could help. Possibly an extension to this which would be equally valuable for me is showing the “NVDA way” to accomplish something. Possibly all the ways to do it.

I will give an example to hopefully try to explain…

The best way to make something accessible is to use the accessibility API where available, MSAA, UIA, etc. Other ways though are more hacking-style if you will, e.g., screen scrape and grab what is needed. I feel a lot of JAWS scripts in the past use this approach for example.

It would appear to me both of these methods are available with NVDA, but only the object way is at all documented. When an API does not exist, or the scripter just lacks familiarity, the API is not going to work though.

Case in point, I was recently looking at the NVDA bug #5068 which is NVDA does not read the number of unread messages in the Outlook folder list. NVDA can read this number when screen review is used, but does not in its normal object mode/focus navigation mode. Ideally the number could be gotten from an accessibility object. Poking around the focus object using the Python console, it does not appear to be in there. This gives me a question: where does screen review come up with the answer? And since it does have it, and I need the number more than I need a perfect OOO piece of code, how do I get it?

In the JAWS world my quick fix for this would end up being something like grabbing the text from the screen by the JAWS (mouse) cursor, and announcing it when the treeItem should be announced possibly using one of the SayOjbect functions, basically whatever function JAWS ends up triggering to speak treeItems in the app. At some later date perhaps I’d rewrite this to use an accessibility API if I ever found the source object if it exists.

Considering both of these approaches, the screen scraping I consider a hack and/or the quick scripter-style, and the API way the more core screen reader developer style, it’d be good to know how to do these with NVDA. The API way I feel has a good start on documentation in the current developer guide, though possibly some examples of accessing UIA and MSAA may be helpful.

 

Module template: Another thought I have, and I am not sure if I can describe this accurately, is would there e a way to make a module template that defines the various events that a typical object may receive, e.g., event_gotFocus? For the various APIs? Not only a template but could this be set up in a way that a scripter could deploy it to a subject application, run the application and have the template module log/show the objects and events being triggered/followed by NVDA? For example back tto the Outlook scenario above, what events is NVDA using to read the folder tree? This is probably obvious to a core developer, but less so to a scripter. Perhaps NVDA is more consistent than other screen readers so this is not as big a deal, my previous experience is part of the fun is finding what will get a screen reader to read, and then what is available to read. (The NVDA overlay classes approach is more elegant than other scripting I’ve seen so this may make life easier long-term.) Part of the question I want to solve quickly is: should I be screen scraping, should I be using MSAA, should I be using UIA? Some combination?

Hope that makes some sense.

 

Anyways thanks for the work.

 

Travis Roth

 

From: Joseph Lee [mailto:[hidden email]]
Sent: Wednesday, May 31, 2017 3:40 AM
To: 'NVDA screen reader development' <[hidden email]>
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Joseph Lee

Hi Travis and others,

 

Regarding documentation: my own add-on development guide should have examples of using accessibility API’s and have some exercises you can try. At the same time, I’m editing the current NVDA Core developer guide to broaden the coverage and include more examples of using diverse API’s (I’ll be posting these drafts on a public wiki soon to gather feedback before sending it in as a pull request to NV Access).

 

Event tracking: I use a combination of my own tracker code and Accessibility Event Tracker (accevent), the latter available as part of Windows SDK. You can ask accevent to give you info on specific events, on specific objects and what not, as well as control information gathered. In case of IAccessible, you can control scope and whether it should be in-process or out of process code. For UIA, you can ask accevent to track specific events only.

 

In case of my own event tracker code, a rudimentary version is available as part of Windows 10 App Essentials add-on. Basically, whenever an event is fired by a UIA control, it logs info about the object, the event fired and additional information such as UIA automation ID, class name and so on. I added this code this year in order to track down controller for event inconsistencies (the UIA controller for property event is fired when an object notices changes to another object it depends on, such as appearance of search suggestions).

 

As for Outlook folder navigation problem: as you pointed out, sometimes screen scraping doesn’t help. There are alternatives out there, including accessibility API’s, Windows API, and Component Object Model (COM; yes, you can let NVDA become a COM client, and this is done in Outlook app module). One possible solution might be to locate number of messages in a folder via COM (Outlook.Application.something), and it is something that should be done in NVDA Core.

 

As for quick versus thorough scripting: Personally, I prefer both approaches and have flexibility, although I tend to lean more towards thorough scripting. Quick scripting would be things such as screen scraping, using a timer to monitor changes in an object (sometimes this is considered thorough scripting) and solutions that gets the job done for now. Thorough scripting would include tracking down events, using overlay classes to represent controls in an app, using API’s provided by the app and so on. For those coming from procedural or imperative languages, object-oriented programming is something that requires some practices, and there are developers here who have experience with functional programming such as use of anonymous (lambda) functions, container (list/dictionary/set) comprehensions, generators, iterators and so on (these are also found in some add-on code). Ultimately, it would be a utopic world if app developers took accessibility feedback seriously, thus negating for a need for scripting for certain cases (more app vendors are starting to take accessibility feedback seriously; a good recent example is TeamTalk conferencing system).

 

As for approaches people should take and code optimizations: personally, I think it is best to let users have access to something sooner than later, with room in your code for future extensions. When I review community add-ons and see code idiom issues, I usually tell authors to not worry about those for version 1.0 release, as premature optimization is root of all evil (Donald Knuth); regarding optimizations, I personally don’t optimize code until a feature has been in the market for several months (I do optimize to some extent during development, but I do leave room for future enhancements). In short, what’s important is user satisfaction and gathering feedback so you can improve your code and its quality in the future (provided that you’re willing to learn more and dive into making things better).

 

In case of one example sent here: the best solution for getting info from a chat program is tracking events and making parts of apps become overlay classes (an overlay class is a class that includes scripts, events and what not for a particular object or control). Timers are useful if you need to monitor an object that does not raise useful events (such as name change, value change, state change and what not), and you need to balance between speed and accuracy (speed as in how frequently the timer runs, accuracy as in making sure important information is spoken and/or brailled). Personally, I’m not in favor of scripters using Windows key in their gestures (someday, your script gestures and Windows 10 commands may conflict), but if that’s the only way of doing it, then sure.

Cheers,

Joseph

 

From: Travis Roth [mailto:[hidden email]]
Sent: Wednesday, May 31, 2017 6:45 AM
To: 'NVDA screen reader development' <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hi,

 

Add-on compatibility layer comment: I’d say no to this because if have to rewrite/adapt a script anyways I’d just as well use the time to learn the NVDA way. Plus this seems like a maintenance nightmare long-term.

 

Wiki comments: Yes. As you describe could help. Possibly an extension to this which would be equally valuable for me is showing the “NVDA way” to accomplish something. Possibly all the ways to do it.

I will give an example to hopefully try to explain…

The best way to make something accessible is to use the accessibility API where available, MSAA, UIA, etc. Other ways though are more hacking-style if you will, e.g., screen scrape and grab what is needed. I feel a lot of JAWS scripts in the past use this approach for example.

It would appear to me both of these methods are available with NVDA, but only the object way is at all documented. When an API does not exist, or the scripter just lacks familiarity, the API is not going to work though.

Case in point, I was recently looking at the NVDA bug #5068 which is NVDA does not read the number of unread messages in the Outlook folder list. NVDA can read this number when screen review is used, but does not in its normal object mode/focus navigation mode. Ideally the number could be gotten from an accessibility object. Poking around the focus object using the Python console, it does not appear to be in there. This gives me a question: where does screen review come up with the answer? And since it does have it, and I need the number more than I need a perfect OOO piece of code, how do I get it?

In the JAWS world my quick fix for this would end up being something like grabbing the text from the screen by the JAWS (mouse) cursor, and announcing it when the treeItem should be announced possibly using one of the SayOjbect functions, basically whatever function JAWS ends up triggering to speak treeItems in the app. At some later date perhaps I’d rewrite this to use an accessibility API if I ever found the source object if it exists.

Considering both of these approaches, the screen scraping I consider a hack and/or the quick scripter-style, and the API way the more core screen reader developer style, it’d be good to know how to do these with NVDA. The API way I feel has a good start on documentation in the current developer guide, though possibly some examples of accessing UIA and MSAA may be helpful.

 

Module template: Another thought I have, and I am not sure if I can describe this accurately, is would there e a way to make a module template that defines the various events that a typical object may receive, e.g., event_gotFocus? For the various APIs? Not only a template but could this be set up in a way that a scripter could deploy it to a subject application, run the application and have the template module log/show the objects and events being triggered/followed by NVDA? For example back tto the Outlook scenario above, what events is NVDA using to read the folder tree? This is probably obvious to a core developer, but less so to a scripter. Perhaps NVDA is more consistent than other screen readers so this is not as big a deal, my previous experience is part of the fun is finding what will get a screen reader to read, and then what is available to read. (The NVDA overlay classes approach is more elegant than other scripting I’ve seen so this may make life easier long-term.) Part of the question I want to solve quickly is: should I be screen scraping, should I be using MSAA, should I be using UIA? Some combination?

Hope that makes some sense.

 

Anyways thanks for the work.

 

Travis Roth

 

From: Joseph Lee [[hidden email]]
Sent: Wednesday, May 31, 2017 3:40 AM
To: 'NVDA screen reader development' <[hidden email]>
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Marlon Brandão de Sousa
There are two issues here that need to be addressed.

One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.

Another one is the following : most scripters will screen scrap either because they have no time to study software API or because they just have not knowledge to do it. If the problem is solved, then it is OK. But how do we screen scrap when scripting for NVTA for example?

Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong. I am a strong supporter of a higher level API set up for an VDA. Window eyes is the reader which has definitely the best example of A similar API. 

Obrigado,
Marlon Brandão de Sousa

Em 31 de mai de 2017, às 13:26, Joseph Lee <[hidden email]> escreveu:

Hi Travis and others,

 

Regarding documentation: my own add-on development guide should have examples of using accessibility API’s and have some exercises you can try. At the same time, I’m editing the current NVDA Core developer guide to broaden the coverage and include more examples of using diverse API’s (I’ll be posting these drafts on a public wiki soon to gather feedback before sending it in as a pull request to NV Access).

 

Event tracking: I use a combination of my own tracker code and Accessibility Event Tracker (accevent), the latter available as part of Windows SDK. You can ask accevent to give you info on specific events, on specific objects and what not, as well as control information gathered. In case of IAccessible, you can control scope and whether it should be in-process or out of process code. For UIA, you can ask accevent to track specific events only.

 

In case of my own event tracker code, a rudimentary version is available as part of Windows 10 App Essentials add-on. Basically, whenever an event is fired by a UIA control, it logs info about the object, the event fired and additional information such as UIA automation ID, class name and so on. I added this code this year in order to track down controller for event inconsistencies (the UIA controller for property event is fired when an object notices changes to another object it depends on, such as appearance of search suggestions).

 

As for Outlook folder navigation problem: as you pointed out, sometimes screen scraping doesn’t help. There are alternatives out there, including accessibility API’s, Windows API, and Component Object Model (COM; yes, you can let NVDA become a COM client, and this is done in Outlook app module). One possible solution might be to locate number of messages in a folder via COM (Outlook.Application.something), and it is something that should be done in NVDA Core.

 

As for quick versus thorough scripting: Personally, I prefer both approaches and have flexibility, although I tend to lean more towards thorough scripting. Quick scripting would be things such as screen scraping, using a timer to monitor changes in an object (sometimes this is considered thorough scripting) and solutions that gets the job done for now. Thorough scripting would include tracking down events, using overlay classes to represent controls in an app, using API’s provided by the app and so on. For those coming from procedural or imperative languages, object-oriented programming is something that requires some practices, and there are developers here who have experience with functional programming such as use of anonymous (lambda) functions, container (list/dictionary/set) comprehensions, generators, iterators and so on (these are also found in some add-on code). Ultimately, it would be a utopic world if app developers took accessibility feedback seriously, thus negating for a need for scripting for certain cases (more app vendors are starting to take accessibility feedback seriously; a good recent example is TeamTalk conferencing system).

 

As for approaches people should take and code optimizations: personally, I think it is best to let users have access to something sooner than later, with room in your code for future extensions. When I review community add-ons and see code idiom issues, I usually tell authors to not worry about those for version 1.0 release, as premature optimization is root of all evil (Donald Knuth); regarding optimizations, I personally don’t optimize code until a feature has been in the market for several months (I do optimize to some extent during development, but I do leave room for future enhancements). In short, what’s important is user satisfaction and gathering feedback so you can improve your code and its quality in the future (provided that you’re willing to learn more and dive into making things better).

 

In case of one example sent here: the best solution for getting info from a chat program is tracking events and making parts of apps become overlay classes (an overlay class is a class that includes scripts, events and what not for a particular object or control). Timers are useful if you need to monitor an object that does not raise useful events (such as name change, value change, state change and what not), and you need to balance between speed and accuracy (speed as in how frequently the timer runs, accuracy as in making sure important information is spoken and/or brailled). Personally, I’m not in favor of scripters using Windows key in their gestures (someday, your script gestures and Windows 10 commands may conflict), but if that’s the only way of doing it, then sure.

Cheers,

Joseph

 

From: Travis Roth [[hidden email]]
Sent: Wednesday, May 31, 2017 6:45 AM
To: 'NVDA screen reader development' <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hi,

 

Add-on compatibility layer comment: I’d say no to this because if have to rewrite/adapt a script anyways I’d just as well use the time to learn the NVDA way. Plus this seems like a maintenance nightmare long-term.

 

Wiki comments: Yes. As you describe could help. Possibly an extension to this which would be equally valuable for me is showing the “NVDA way” to accomplish something. Possibly all the ways to do it.

I will give an example to hopefully try to explain…

The best way to make something accessible is to use the accessibility API where available, MSAA, UIA, etc. Other ways though are more hacking-style if you will, e.g., screen scrape and grab what is needed. I feel a lot of JAWS scripts in the past use this approach for example.

It would appear to me both of these methods are available with NVDA, but only the object way is at all documented. When an API does not exist, or the scripter just lacks familiarity, the API is not going to work though.

Case in point, I was recently looking at the NVDA bug #5068 which is NVDA does not read the number of unread messages in the Outlook folder list. NVDA can read this number when screen review is used, but does not in its normal object mode/focus navigation mode. Ideally the number could be gotten from an accessibility object. Poking around the focus object using the Python console, it does not appear to be in there. This gives me a question: where does screen review come up with the answer? And since it does have it, and I need the number more than I need a perfect OOO piece of code, how do I get it?

In the JAWS world my quick fix for this would end up being something like grabbing the text from the screen by the JAWS (mouse) cursor, and announcing it when the treeItem should be announced possibly using one of the SayOjbect functions, basically whatever function JAWS ends up triggering to speak treeItems in the app. At some later date perhaps I’d rewrite this to use an accessibility API if I ever found the source object if it exists.

Considering both of these approaches, the screen scraping I consider a hack and/or the quick scripter-style, and the API way the more core screen reader developer style, it’d be good to know how to do these with NVDA. The API way I feel has a good start on documentation in the current developer guide, though possibly some examples of accessing UIA and MSAA may be helpful.

 

Module template: Another thought I have, and I am not sure if I can describe this accurately, is would there e a way to make a module template that defines the various events that a typical object may receive, e.g., event_gotFocus? For the various APIs? Not only a template but could this be set up in a way that a scripter could deploy it to a subject application, run the application and have the template module log/show the objects and events being triggered/followed by NVDA? For example back tto the Outlook scenario above, what events is NVDA using to read the folder tree? This is probably obvious to a core developer, but less so to a scripter. Perhaps NVDA is more consistent than other screen readers so this is not as big a deal, my previous experience is part of the fun is finding what will get a screen reader to read, and then what is available to read. (The NVDA overlay classes approach is more elegant than other scripting I’ve seen so this may make life easier long-term.) Part of the question I want to solve quickly is: should I be screen scraping, should I be using MSAA, should I be using UIA? Some combination?

Hope that makes some sense.

 

Anyways thanks for the work.

 

Travis Roth

 

From: Joseph Lee [[hidden email]]
Sent: Wednesday, May 31, 2017 3:40 AM
To: 'NVDA screen reader development' <[hidden email]>
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

James Teh
On Thu, Jun 1, 2017 at 5:41 AM, Marlon Brandão de Sousa <[hidden email]> wrote:
One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.
I think everyone agrees on this point. It needs to be done; it's just going to take time.


Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong.
Not sure what you mean by Windows SDK here. If you mean installing Visual Studio, then sure, I agree... and if we solve the first problem (the API documentation not being online), you will never have to. If you mean MSDN, things get blurrier for me.

What I find interesting about the JAWS/Window-Eyes screen reader scripting landscape is that it is very different to plugin expectations for other products, even popular ones. Many other products don't teach you the language they're coded in when you want to write a plugin; they tell you about the API, but you're expected to know concepts about the language (e.g. object oriented programming, etc.). Similarly, if you're calling on stuff from elsewhere, they might give you a brief introduction, but for the most part, they expect you to refer to the documentation on how to use those things. If I'm writing a plugin for foobar2000, Winamp or Cakewalk Sonar, I'm expected to know how to code in C++ and, in the case of Sonar, I'm expected to know COM. But the message I'm seeing here is that screen reader scripters want all of this in one place (even how to code in Python and Win32 concepts, all of which are already well documented elsewhere). I guess that's just how it has been for years, so it's not something we can expect to change, but this is not really how things work elsewhere in the scripting and software development worlds.

There's also a limit to how far we can "slim down" the API without majorly limiting the kinds of things you can achieve in NVDA that you just can't achieve elsewhere. For example, you could implement support for an entirely custom editable text control with its own API, including support for font information, spelling errors, etc. It's true that the majority of basic scripting tasks don't require this kind of advanced work, but it also seems silly to intentionally limit that ability.

Jamie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Marlon Brandão de Sousa
Hello James,

I referred to the windows SDK because of Joseph's response when he said that in order to better understand what is going on on applications he uses accevent which is, accordingly to him, a part of windows SDK… see, I disagree with folks wanting us to teach Python  to them. The same way they had to learn vbs or jaws scripting language they will need to learn python. Every software happens to be written in some language and you have to learn the language the authors have chosen to write it in order to maintain it. I personally do not like python but expecting that I can script NVDA without knowing it just doesn't make sense at all… however, expecting that one simply knows that there is a tool hidden somewhere on windows SDK that will help one to track events on objects without letting them know is also not fair. I don't know if such tool requires one to install the full windows SDK but, if not, a link to download this diagnosis tool needs to be in the developer documentation somewhere. Currently what I miss the most is the kind of autonomy that a feature like home row brings me on NVDA. What I miss the most is I always sit in front at software to be scripted and feel a little bit lost on how to track what is going on on to find our starting point where I can hook myself and start analyzing it. I'm not complaining by no means, I'm only thinking like a typical scripter and trying to see the kind of things one would find Commonli in oder products.

If Joseph could write about how he tracks events and inspect the internals of apps to be scripted it would be very very helpful. If he or anybody else could develop an internal feature most like home row Applied to the NVDA context it would be awesome. Who knows maybe I can try to build a msaa and uia navigator from the window one is currently focused on but not now because I'm not skilled enough to do it… But we should definitely join efforts and think on how to build some utilities that would help scripters from all the products to find Their way.

Obrigado,
Marlon Brandão de Sousa

Em 31 de mai de 2017, às 20:37, James Teh <[hidden email]> escreveu:

On Thu, Jun 1, 2017 at 5:41 AM, Marlon Brandão de Sousa <[hidden email]> wrote:
One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.
I think everyone agrees on this point. It needs to be done; it's just going to take time.


Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong.
Not sure what you mean by Windows SDK here. If you mean installing Visual Studio, then sure, I agree... and if we solve the first problem (the API documentation not being online), you will never have to. If you mean MSDN, things get blurrier for me.

What I find interesting about the JAWS/Window-Eyes screen reader scripting landscape is that it is very different to plugin expectations for other products, even popular ones. Many other products don't teach you the language they're coded in when you want to write a plugin; they tell you about the API, but you're expected to know concepts about the language (e.g. object oriented programming, etc.). Similarly, if you're calling on stuff from elsewhere, they might give you a brief introduction, but for the most part, they expect you to refer to the documentation on how to use those things. If I'm writing a plugin for foobar2000, Winamp or Cakewalk Sonar, I'm expected to know how to code in C++ and, in the case of Sonar, I'm expected to know COM. But the message I'm seeing here is that screen reader scripters want all of this in one place (even how to code in Python and Win32 concepts, all of which are already well documented elsewhere). I guess that's just how it has been for years, so it's not something we can expect to change, but this is not really how things work elsewhere in the scripting and software development worlds.

There's also a limit to how far we can "slim down" the API without majorly limiting the kinds of things you can achieve in NVDA that you just can't achieve elsewhere. For example, you could implement support for an entirely custom editable text control with its own API, including support for font information, spelling errors, etc. It's true that the majority of basic scripting tasks don't require this kind of advanced work, but it also seems silly to intentionally limit that ability.

Jamie
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Joseph Lee

Hi,

I didn’t know about accevent until a few years ago when Mick and Jamie mentioned it. Back then, I was a novice, learning about operating systems and compiler design as part of my computer science coursework, and didn’t know the ins and outs of native NVDA API set nor some inner details of Windows internals (this was back in 2013). After experimenting with this tool (yes, part of Windows SDK, which is included with Visual studio), sending in some NVDA patches and reading Windows Internals (Microsoft Press, 2013), I was sort of hooked (as in became somewhat of a frequent user of that tool).

As for how I and others examine programs and what not, that’ll require a lengthy discussion and your participation: exercises. Scripting is programming, and for some, the best way might be to expose you to some things via exercises. But in a nutshell, I don’t use screen scraping techniques for the most part (sometimes, I use screen review to see how an app is laid out); I usually start with reading manuals instead of doing focus.next and what not (at least to immerse myself with questions that users could ask). Then I look at what kind of graphical toolkit was used (api.getForegroundObject().windowClassName), then I’d look at accessibility API’s in use (via navigator object developer info or nvDA+F1 command), then finally I write app modules. This is only a small part when it comes to making app modules, the bigger part being actual testing.

As for the other matter at hand (in reply to another person): looks like we’ll put a stop sign on compatibility layer add-on for a while, as documentation seems to be a better idea. I’ll talk about things I personally do when writing add-ons in the next post.

Cheers,

Joseph

 

 

From: Marlon Brandão de Sousa [mailto:[hidden email]]
Sent: Wednesday, May 31, 2017 6:07 PM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hello James,

I referred to the windows SDK because of Joseph's response when he said that in order to better understand what is going on on applications he uses accevent which is, accordingly to him, a part of windows SDK… see, I disagree with folks wanting us to teach Python  to them. The same way they had to learn vbs or jaws scripting language they will need to learn python. Every software happens to be written in some language and you have to learn the language the authors have chosen to write it in order to maintain it. I personally do not like python but expecting that I can script NVDA without knowing it just doesn't make sense at all… however, expecting that one simply knows that there is a tool hidden somewhere on windows SDK that will help one to track events on objects without letting them know is also not fair. I don't know if such tool requires one to install the full windows SDK but, if not, a link to download this diagnosis tool needs to be in the developer documentation somewhere. Currently what I miss the most is the kind of autonomy that a feature like home row brings me on NVDA. What I miss the most is I always sit in front at software to be scripted and feel a little bit lost on how to track what is going on on to find our starting point where I can hook myself and start analyzing it. I'm not complaining by no means, I'm only thinking like a typical scripter and trying to see the kind of things one would find Commonli in oder products.

 

If Joseph could write about how he tracks events and inspect the internals of apps to be scripted it would be very very helpful. If he or anybody else could develop an internal feature most like home row Applied to the NVDA context it would be awesome. Who knows maybe I can try to build a msaa and uia navigator from the window one is currently focused on but not now because I'm not skilled enough to do it… But we should definitely join efforts and think on how to build some utilities that would help scripters from all the products to find Their way.

 

Obrigado,
Marlon Brandão de Sousa


Em 31 de mai de 2017, às 20:37, James Teh <[hidden email]> escreveu:

On Thu, Jun 1, 2017 at 5:41 AM, Marlon Brandão de Sousa <[hidden email]> wrote:

One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.

I think everyone agrees on this point. It needs to be done; it's just going to take time.

 

 

Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong.

Not sure what you mean by Windows SDK here. If you mean installing Visual Studio, then sure, I agree... and if we solve the first problem (the API documentation not being online), you will never have to. If you mean MSDN, things get blurrier for me.

 

What I find interesting about the JAWS/Window-Eyes screen reader scripting landscape is that it is very different to plugin expectations for other products, even popular ones. Many other products don't teach you the language they're coded in when you want to write a plugin; they tell you about the API, but you're expected to know concepts about the language (e.g. object oriented programming, etc.). Similarly, if you're calling on stuff from elsewhere, they might give you a brief introduction, but for the most part, they expect you to refer to the documentation on how to use those things. If I'm writing a plugin for foobar2000, Winamp or Cakewalk Sonar, I'm expected to know how to code in C++ and, in the case of Sonar, I'm expected to know COM. But the message I'm seeing here is that screen reader scripters want all of this in one place (even how to code in Python and Win32 concepts, all of which are already well documented elsewhere). I guess that's just how it has been for years, so it's not something we can expect to change, but this is not really how things work elsewhere in the scripting and software development worlds.

 

There's also a limit to how far we can "slim down" the API without majorly limiting the kinds of things you can achieve in NVDA that you just can't achieve elsewhere. For example, you could implement support for an entirely custom editable text control with its own API, including support for font information, spelling errors, etc. It's true that the majority of basic scripting tasks don't require this kind of advanced work, but it also seems silly to intentionally limit that ability.


Jamie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

derek riemer
In reply to this post by Damien Sykes-Pendleton
eI felt this way when I started. I really don't know how to improve it best now, because I was being formally trained in computer science while doing this.

On Wed, May 31, 2017 at 5:33 AM, Damien Sykes-Lindley <[hidden email]> wrote:
Hi,
This message is quite lengthy and possibly even rambly, but it expresses my opinions while enlightening you to my strengths and weaknesses, so bare with me.
Having previously worked on JAWS and Dolphin Supernova scripting before I switched over to NVDA, I have already started a similar system covering the two readers, along with a set of tutorials similar to those produced by FS and Dolphin to help the transition.
I mainly wrote it for me but have received popular requests to release it once completed. I felt that, having taken me approximately four years to bring my dream of making addons or, more long term, working with the core itself to life, I didn’t want new users to experience the same tripping points that I did. In fact, my tutorials give long introductions on Python, Git, SCons etc so that things are absolutely clear from the word go.
It’s by no means complete, I’ve never messed with WindowEyes in my life for a start, and I have no idea on how accurate my information is for a second, so perhaps some collaboration might be possible on the materials we already have and perhaps make a wrapper layer covering all screenreaders.
I believe it will make things a lot less intimidating. Switching from a proprietary screenreader where all your references and tutorials have to be accurate, detailed, and easily obtainable, to an open source version where all your information is scattered, perhaps incomplete, and vague, for beginners of Python and especially for programming beginners, and where reference guides have to be built manually, straight from the source code, to me, was exceptionally intimidating, hence the reason it took me so long to get to where I am now, whereas when all said and done I could have probably picked it up in two to four weeks had it been more contained and detailed.
 
Take a trip into a certain Damien’s mind from 2010 to 2017 and consider the following:
 
2010: Five steps to Jaws scripting:
1. Look at the help for the script manager.
2. Links to download the FSDN and scripting tutorial are right there. Except I don’t think it was called that back then.
3. Learn from the tutorial, which is detailed enough to where you can look at the FSDN like any other scripting tutorial and more or less know exactly what you're doing.
4. Look at the FSDN and marvel how easy it is to find what you need.
5. Reinforce and confirm your knowledge with an audio scripting tutorial.
Total time: Approx 2 months.
Granted. This is an internal, even possibly custom-built scripting language which is easy to document and doesn’t need any external godly forces to use.
 
2012: Five steps to scripting Supernova:
1. Go to the scripting engine.
2. Click on help. Believe it or not, the tutorial is right there.
3. Read a bit and feel slightly intimidated that it uses a scripting language called LUA.
4. Hang on...Read a bit further and it gives you the essential introduction to LUA right there. Even though it specifically states its function is not to teach you LUA! Theoretically the only time you need to look at LUA is if you want to make use of LUA’s standard library.
5. Again, read on, study the reference, happy days.
Total time: Approx 1 month.
An in-between. You don’t need LUA because it comes prebuilt and prepackaged in the scripting engine. They document the basics of LUA and a tutorial on using the Dolphin API, so even then you don’t have to look at the LUA docs all that much. Again, pretty easy to build your stuff.
 
2013-2017: A nightmare to scripting NVDA:
1. Download NVDA and explore.
2. In tools, you see Python Console. You might know from some conversation or other that Python is a scripting language. Automatically you might think, "Hey. NVDA's answer to scripting." Wrong.
3. The user guide mentions the Python console and refers you to the NVDA GitHub page (or in my case back in 2013, the self-hosted community page). Fumble and stumble around there aimlessly until you suddenly reach "developer guide".
4. This guide dedicates two of its six chapters to scripting addons and plugins, and from the very beginning you're asking questions. "Where is the code documentation? What are events, scripts and bindings? What on earth is class inheritance? appModuleHandler.AppModule/globalPluginHandler.GlobalPlugin?" Luckily for me I at least knew what class inheritance was, but only very vaguely. I had only used it twice, and in a different language.
5. You are fortunately told that scripts are Python files. OK. Let's look at the Python tutorial, which itself is something like 140 subsections long. Even then, in some areas, it expects some degree of advanced programming knowledge as it goes into various aspects as to how Python works internally.
6. Spend money to buy a Python basics book. OK. You now have a relative idea of how Python works. How do I make this plugin again?
7. Back to NVDA developer guide. OK, can I remember why we have dot identifiers? Ah. Objects and modules. So is this an object, or is it a module? Or even a package!
8. You think you've exhausted everything. Right. Where do we get the code documentation?
9. Back to the NVDA GitHub/community site. No link to it there.
10. Pretty much scour the repository and/or wiki pages. Hang on, we have to build the docs manually? Even worse, from the Python source code?
11. Read another in-depth tutorial, this time on Git. Most of which you probably don't need to know for this.
12. Clone NVDA and worry that you might have broken something because you've never used Git before in your life.
13. Install Python, even if you haven't and possibly won't use it as a primary development environment.
14. Make sure you have Pip. Even in Windows you sometimes have to conform to advanced Linux concepts. Bleh.
15. Install SCons. To be on the safe side, install all NVDA's dependencies, again despite the fact you'll probably never use them.
16. Break your system in the process because one of them is Visual Studio which goes through a ridiculous number of versions, support options and SDK's and you happen to have installed the wrong one and it insists that your evaluation licence has expired despite having never touched it.
17. Worry if you've broken anything else. All these development environments, you've no idea what shinanikins they're going to put in the registry or what advanced piece of skulduggery they're going to have you do, either automatically or manually by way of its rocket-scientists documentation.
18. Finally, just finally, build the relevant documentation.
19. Puzzle over the documentation because the index is showing you item after item after item that are all the same. For instance, just look at the number of functions that call themselves speak...
20. In the end you're probably best looking at the Python modules themselves because then you know what is being called from where, and there's nothing telling you how you're supposed to make use of this documentation. If you don’t know Python it takes you longer because you’re looking stuff up all the time. But at least you have more of a lead.
21. Sit there and wonder if you need the NVDAHelper documentation.
22. Screw it. Let's make my own simpler system. Growl and grin.
 
Of course not everyone has been haunted by the same frustrations. There are many people who are well trained, seasoned programmers, I’m guessing especially on this list given that it deals mainly with core development, who are used to working with fully fledged development environments, version control, automated building, package managers and dependency control, near enough every day. To me, they are the sort of complicated wizardry that I might expect to find on a Linux system, Note my own personal definition of Linux: “A system for people, mainly developers and network administrators, who are more expert than Bill Gates” (I freak out with Linux – either it never works or I blow a catastrophic accident). Needless to say, I have generally been Windows in and out and have only recently started making use of version control, and even then not to its full potential. Had it not been for an in-depth, hour long introduction to Fossil by a friend of mine, which is very similar in some ways to Git, and the very helpful concept of Git command aliasing, I probably still wouldn’t be developing and releasing addons even now. All the other systems just go way above and beyond my scope of understanding and so the only way I could expect it to work is by following the letter and praying to the heavens above that I haven’t screwed up and conked out my whole system in the process.
 
I have a feeling this is why we only have a small number of addons. Look for JAWS scripts, there are pages and pages and pages full of them. Look for NVDA addons, there are probably 50. My opinion is that this has needed to happen for quite some time, and I'm glad that it has finally become a possibility.
 
Of course working on the core is an entirely different matter – NVDA itself is a huge system and so ideally needs a structured organisation and workflow, which it has, and so you would expect to be used to working in that sort of environment before messing about with it. If it was your first time you’d have to build up. But in my opinions building addons shouldn’t be half, or even a tenth as complicated as that.
 
Cheers.
Damien.
 
 
Sent: Wednesday, May 31, 2017 9:39 AM
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?
 

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel




--

Derek Riemer: Improving the world one byte at a time!

  • University of Colorado Boulder Department of computer science, 4th year undergraduate student.
  • Accessibility enthusiast.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Skier.

Personal website



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Cory Samaha-2
In reply to this post by Joseph Lee
Hi Joseph and all,
I have heard of AccEvent.  There was a script that GW Micro wrote back when scripting for Window-Eyes was first being released called WEEvent, which I believe was very much inspired by AccEvent.  However, since WEEvent existed as a Window-Eyes script I never had the need to use AccEvent when I was scripting an app, but I found WEEvent an invaluable tool when I was first looking at a program to script and trying to figure out which events were being fired that I could hook onto.  I’m not suggesting that a similar add-on for NVDA be written since we can get this information through AccEvent, but just thought I’d throw it out there.

I also agree with Jamie - I wouldn’t want to dumb something down or exclude some crucial modules that could be useful.  I rarely ever use screen scraping techniques as I find, at least with the Window-Eyes off screen model it can be a bit buggy.  But knowing that something can be scripted that way as a last resort is nice to know.  I feel this is becoming less of an issue anyway, as the off screen model is being used less and less in favor of accessibility APIs.  Regarding documentation, I find that learning Python is the easy part.  Indeed, in the Window-Eyes scripting manual they do not teach VBScript which is what the overwhelming majority of Window-Eyes scripts have been written in, but all of the examples throughout the scripting manual use VBScript with the assumption that you are familiar with it already.  I find the Python tutorials are sufficient for this task.  Anyway, just thought I’d add my $0.02 to the conversation.

Regards,
Cory
On May 31, 2017, at 9:29 PM, Joseph Lee <[hidden email]> wrote:

Hi,
I didn’t know about accevent until a few years ago when Mick and Jamie mentioned it. Back then, I was a novice, learning about operating systems and compiler design as part of my computer science coursework, and didn’t know the ins and outs of native NVDA API set nor some inner details of Windows internals (this was back in 2013). After experimenting with this tool (yes, part of Windows SDK, which is included with Visual studio), sending in some NVDA patches and reading Windows Internals (Microsoft Press, 2013), I was sort of hooked (as in became somewhat of a frequent user of that tool).
As for how I and others examine programs and what not, that’ll require a lengthy discussion and your participation: exercises. Scripting is programming, and for some, the best way might be to expose you to some things via exercises. But in a nutshell, I don’t use screen scraping techniques for the most part (sometimes, I use screen review to see how an app is laid out); I usually start with reading manuals instead of doing focus.next and what not (at least to immerse myself with questions that users could ask). Then I look at what kind of graphical toolkit was used (api.getForegroundObject().windowClassName), then I’d look at accessibility API’s in use (via navigator object developer info or nvDA+F1 command), then finally I write app modules. This is only a small part when it comes to making app modules, the bigger part being actual testing.
As for the other matter at hand (in reply to another person): looks like we’ll put a stop sign on compatibility layer add-on for a while, as documentation seems to be a better idea. I’ll talk about things I personally do when writing add-ons in the next post.
Cheers,
Joseph
 
 
From: Marlon Brandão de Sousa [[hidden email]]
Sent: Wednesday, May 31, 2017 6:07 PM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?
 
Hello James,

I referred to the windows SDK because of Joseph's response when he said that in order to better understand what is going on on applications he uses accevent which is, accordingly to him, a part of windows SDK… see, I disagree with folks wanting us to teach Python  to them. The same way they had to learn vbs or jaws scripting language they will need to learn python. Every software happens to be written in some language and you have to learn the language the authors have chosen to write it in order to maintain it. I personally do not like python but expecting that I can script NVDA without knowing it just doesn't make sense at all… however, expecting that one simply knows that there is a tool hidden somewhere on windows SDK that will help one to track events on objects without letting them know is also not fair. I don't know if such tool requires one to install the full windows SDK but, if not, a link to download this diagnosis tool needs to be in the developer documentation somewhere. Currently what I miss the most is the kind of autonomy that a feature like home row brings me on NVDA. What I miss the most is I always sit in front at software to be scripted and feel a little bit lost on how to track what is going on on to find our starting point where I can hook myself and start analyzing it. I'm not complaining by no means, I'm only thinking like a typical scripter and trying to see the kind of things one would find Commonli in oder products.
 
If Joseph could write about how he tracks events and inspect the internals of apps to be scripted it would be very very helpful. If he or anybody else could develop an internal feature most like home row Applied to the NVDA context it would be awesome. Who knows maybe I can try to build a msaa and uia navigator from the window one is currently focused on but not now because I'm not skilled enough to do it… But we should definitely join efforts and think on how to build some utilities that would help scripters from all the products to find Their way.
 
Obrigado,
Marlon Brandão de Sousa


Em 31 de mai de 2017, às 20:37, James Teh <[hidden email]> escreveu:

On Thu, Jun 1, 2017 at 5:41 AM, Marlon Brandão de Sousa <[hidden email]> wrote:
One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.
I think everyone agrees on this point. It needs to be done; it's just going to take time.
 
 
Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong.
Not sure what you mean by Windows SDK here. If you mean installing Visual Studio, then sure, I agree... and if we solve the first problem (the API documentation not being online), you will never have to. If you mean MSDN, things get blurrier for me.
 
What I find interesting about the JAWS/Window-Eyes screen reader scripting landscape is that it is very different to plugin expectations for other products, even popular ones. Many other products don't teach you the language they're coded in when you want to write a plugin; they tell you about the API, but you're expected to know concepts about the language (e.g. object oriented programming, etc.). Similarly, if you're calling on stuff from elsewhere, they might give you a brief introduction, but for the most part, they expect you to refer to the documentation on how to use those things. If I'm writing a plugin for foobar2000, Winamp or Cakewalk Sonar, I'm expected to know how to code in C++ and, in the case of Sonar, I'm expected to know COM. But the message I'm seeing here is that screen reader scripters want all of this in one place (even how to code in Python and Win32 concepts, all of which are already well documented elsewhere). I guess that's just how it has been for years, so it's not something we can expect to change, but this is not really how things work elsewhere in the scripting and software development worlds.
 
There's also a limit to how far we can "slim down" the API without majorly limiting the kinds of things you can achieve in NVDA that you just can't achieve elsewhere. For example, you could implement support for an entirely custom editable text control with its own API, including support for font information, spelling errors, etc. It's true that the majority of basic scripting tasks don't require this kind of advanced work, but it also seems silly to intentionally limit that ability.

Jamie
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Cory Samaha-2
In reply to this post by derek riemer
Derek,
I don’t know if this has anything to do with formal Computer Science training.  I too was a computer science major so concepts such as classes, inheritance, binding and version control were not foreign to me.  What is frustrating, and what I think Damien expressed so well is the frustration when you actually do get to look at the NVDA code documentation which you do in fact have to build manually.  As he said, there are so many methods with same or similar names.  How do I know which one I should use?  How do I know what is part of core and therefore I should stay away from it until I become more familiar with more simple NVDA scripting concepts, and how do I know which parts are supposed to be public?  And I think this is the part that needs to be cleaned up.  Not just something that will turn docstrings into a “scripting manual,” but a document that is maintained over time, with each release of NVDA which can help computer scientists as well as beginners feel less intimidated.  I remember the first time I looked at the NVDA developer guide and thinking ok, where’s the guide?  Yes, it mentions certain events, but you can tell it was not a full list of modules in a hierarchical form which one could reference.  I believe that is the good that is coming out of this dialog that we are now having.  Cheers to Joseph for starting this initiative and for the material he has put together thus far.

Regards,
Cory
On May 31, 2017, at 10:32 PM, Derek Riemer <[hidden email]> wrote:

eI felt this way when I started. I really don't know how to improve it best now, because I was being formally trained in computer science while doing this.

On Wed, May 31, 2017 at 5:33 AM, Damien Sykes-Lindley <[hidden email]> wrote:
Hi,
This message is quite lengthy and possibly even rambly, but it expresses my opinions while enlightening you to my strengths and weaknesses, so bare with me.
Having previously worked on JAWS and Dolphin Supernova scripting before I switched over to NVDA, I have already started a similar system covering the two readers, along with a set of tutorials similar to those produced by FS and Dolphin to help the transition.
I mainly wrote it for me but have received popular requests to release it once completed. I felt that, having taken me approximately four years to bring my dream of making addons or, more long term, working with the core itself to life, I didn’t want new users to experience the same tripping points that I did. In fact, my tutorials give long introductions on Python, Git, SCons etc so that things are absolutely clear from the word go.
It’s by no means complete, I’ve never messed with WindowEyes in my life for a start, and I have no idea on how accurate my information is for a second, so perhaps some collaboration might be possible on the materials we already have and perhaps make a wrapper layer covering all screenreaders.
I believe it will make things a lot less intimidating. Switching from a proprietary screenreader where all your references and tutorials have to be accurate, detailed, and easily obtainable, to an open source version where all your information is scattered, perhaps incomplete, and vague, for beginners of Python and especially for programming beginners, and where reference guides have to be built manually, straight from the source code, to me, was exceptionally intimidating, hence the reason it took me so long to get to where I am now, whereas when all said and done I could have probably picked it up in two to four weeks had it been more contained and detailed.
 
Take a trip into a certain Damien’s mind from 2010 to 2017 and consider the following:
 
2010: Five steps to Jaws scripting:
1. Look at the help for the script manager.
2. Links to download the FSDN and scripting tutorial are right there. Except I don’t think it was called that back then.
3. Learn from the tutorial, which is detailed enough to where you can look at the FSDN like any other scripting tutorial and more or less know exactly what you're doing.
4. Look at the FSDN and marvel how easy it is to find what you need.
5. Reinforce and confirm your knowledge with an audio scripting tutorial.
Total time: Approx 2 months.
Granted. This is an internal, even possibly custom-built scripting language which is easy to document and doesn’t need any external godly forces to use.
 
2012: Five steps to scripting Supernova:
1. Go to the scripting engine.
2. Click on help. Believe it or not, the tutorial is right there.
3. Read a bit and feel slightly intimidated that it uses a scripting language called LUA.
4. Hang on...Read a bit further and it gives you the essential introduction to LUA right there. Even though it specifically states its function is not to teach you LUA! Theoretically the only time you need to look at LUA is if you want to make use of LUA’s standard library.
5. Again, read on, study the reference, happy days.
Total time: Approx 1 month.
An in-between. You don’t need LUA because it comes prebuilt and prepackaged in the scripting engine. They document the basics of LUA and a tutorial on using the Dolphin API, so even then you don’t have to look at the LUA docs all that much. Again, pretty easy to build your stuff.
 
2013-2017: A nightmare to scripting NVDA:
1. Download NVDA and explore.
2. In tools, you see Python Console. You might know from some conversation or other that Python is a scripting language. Automatically you might think, "Hey. NVDA's answer to scripting." Wrong.
3. The user guide mentions the Python console and refers you to the NVDA GitHub page (or in my case back in 2013, the self-hosted community page). Fumble and stumble around there aimlessly until you suddenly reach "developer guide".
4. This guide dedicates two of its six chapters to scripting addons and plugins, and from the very beginning you're asking questions. "Where is the code documentation? What are events, scripts and bindings? What on earth is class inheritance? appModuleHandler.AppModule/globalPluginHandler.GlobalPlugin?" Luckily for me I at least knew what class inheritance was, but only very vaguely. I had only used it twice, and in a different language.
5. You are fortunately told that scripts are Python files. OK. Let's look at the Python tutorial, which itself is something like 140 subsections long. Even then, in some areas, it expects some degree of advanced programming knowledge as it goes into various aspects as to how Python works internally.
6. Spend money to buy a Python basics book. OK. You now have a relative idea of how Python works. How do I make this plugin again?
7. Back to NVDA developer guide. OK, can I remember why we have dot identifiers? Ah. Objects and modules. So is this an object, or is it a module? Or even a package!
8. You think you've exhausted everything. Right. Where do we get the code documentation?
9. Back to the NVDA GitHub/community site. No link to it there.
10. Pretty much scour the repository and/or wiki pages. Hang on, we have to build the docs manually? Even worse, from the Python source code?
11. Read another in-depth tutorial, this time on Git. Most of which you probably don't need to know for this.
12. Clone NVDA and worry that you might have broken something because you've never used Git before in your life.
13. Install Python, even if you haven't and possibly won't use it as a primary development environment.
14. Make sure you have Pip. Even in Windows you sometimes have to conform to advanced Linux concepts. Bleh.
15. Install SCons. To be on the safe side, install all NVDA's dependencies, again despite the fact you'll probably never use them.
16. Break your system in the process because one of them is Visual Studio which goes through a ridiculous number of versions, support options and SDK's and you happen to have installed the wrong one and it insists that your evaluation licence has expired despite having never touched it.
17. Worry if you've broken anything else. All these development environments, you've no idea what shinanikins they're going to put in the registry or what advanced piece of skulduggery they're going to have you do, either automatically or manually by way of its rocket-scientists documentation.
18. Finally, just finally, build the relevant documentation.
19. Puzzle over the documentation because the index is showing you item after item after item that are all the same. For instance, just look at the number of functions that call themselves speak...
20. In the end you're probably best looking at the Python modules themselves because then you know what is being called from where, and there's nothing telling you how you're supposed to make use of this documentation. If you don’t know Python it takes you longer because you’re looking stuff up all the time. But at least you have more of a lead.
21. Sit there and wonder if you need the NVDAHelper documentation.
22. Screw it. Let's make my own simpler system. Growl and grin.
 
Of course not everyone has been haunted by the same frustrations. There are many people who are well trained, seasoned programmers, I’m guessing especially on this list given that it deals mainly with core development, who are used to working with fully fledged development environments, version control, automated building, package managers and dependency control, near enough every day. To me, they are the sort of complicated wizardry that I might expect to find on a Linux system, Note my own personal definition of Linux: “A system for people, mainly developers and network administrators, who are more expert than Bill Gates” (I freak out with Linux – either it never works or I blow a catastrophic accident). Needless to say, I have generally been Windows in and out and have only recently started making use of version control, and even then not to its full potential. Had it not been for an in-depth, hour long introduction to Fossil by a friend of mine, which is very similar in some ways to Git, and the very helpful concept of Git command aliasing, I probably still wouldn’t be developing and releasing addons even now. All the other systems just go way above and beyond my scope of understanding and so the only way I could expect it to work is by following the letter and praying to the heavens above that I haven’t screwed up and conked out my whole system in the process.
 
I have a feeling this is why we only have a small number of addons. Look for JAWS scripts, there are pages and pages and pages full of them. Look for NVDA addons, there are probably 50. My opinion is that this has needed to happen for quite some time, and I'm glad that it has finally become a possibility.
 
Of course working on the core is an entirely different matter – NVDA itself is a huge system and so ideally needs a structured organisation and workflow, which it has, and so you would expect to be used to working in that sort of environment before messing about with it. If it was your first time you’d have to build up. But in my opinions building addons shouldn’t be half, or even a tenth as complicated as that.
 
Cheers.
Damien.
 
 
Sent: Wednesday, May 31, 2017 9:39 AM
Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?
 

Hi all, mostly for JAWS and/or Window-Eyes scripters:

 

I’m looking at FSDN functions reference and Window-Eyes object model docs at the moment, and was wondering if you have comments about the following proposal:

 

As part of developer side of Project Contact Lenses, I’m looking into creating a functions reference wiki, a source code compatibility layer add-on or both. Having a handy reference manual for those coming from other screen readers could help some of you in porting your scripts easier by looking at functions NVDA expects. On the other hand, having an add-on (a global plugin, in fact) that lets you call familiar functions and have it translate into equivalent code path in NVDA may help some in gradually porting your source code.

 

In case of the wiki, it’ll consist of tables that list routines you may wish to do, followed by functions in other screen readers and NVDA equivalent like so:

 

  • Say something: JAWS: SayMessage; NVDA: ui.message or speech.speakMessage

 

The ad-on version would be something like:

 

From globalPlugins.whateverTheNameWillBe.jaws import *

 

sayMessage(string)

->

Speech.speakMessage(string)

 

Ultimately, for best experience, it would be best to call functions and use objects provided by NVDA, but in the interim, having a compatibility layer add-on and/or a functions reference wiki could help. In case of an add-on, I’ll host a public repository on GitHub so anyone can fork and submit pull requests, and the initial version will define popular functions from JAWS and/or Window-Eyes.

 

Comments are appreciated.

Cheers,

Joseph



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel




--

Derek Riemer: Improving the world one byte at a time!

  • University of Colorado Boulder Department of computer science, 4th year undergraduate student.
  • Accessibility enthusiast.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Skier.

Personal website


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Cory Samaha-2
In reply to this post by Cory Samaha-2
Oh yeah I forgot to mention, WEEvent had the advantage of, not just showing you the IAccessible or UIA events that were being fired, but you could also see which events specific to Window-Eyes were being fired.  For example, if I wanted to see when Window-Eyes was sending something to my synthesizer to be spoken I could select the Speech.OnSpeak event.  I could select various Window events to see if / when their class name, module name or title changed, as well as all of the braille events.  It was a great script for Window-Eyes developers.

Cory
On Jun 1, 2017, at 1:10 AM, Cory Samaha <[hidden email]> wrote:

Hi Joseph and all,
I have heard of AccEvent.  There was a script that GW Micro wrote back when scripting for Window-Eyes was first being released called WEEvent, which I believe was very much inspired by AccEvent.  However, since WEEvent existed as a Window-Eyes script I never had the need to use AccEvent when I was scripting an app, but I found WEEvent an invaluable tool when I was first looking at a program to script and trying to figure out which events were being fired that I could hook onto.  I’m not suggesting that a similar add-on for NVDA be written since we can get this information through AccEvent, but just thought I’d throw it out there.

I also agree with Jamie - I wouldn’t want to dumb something down or exclude some crucial modules that could be useful.  I rarely ever use screen scraping techniques as I find, at least with the Window-Eyes off screen model it can be a bit buggy.  But knowing that something can be scripted that way as a last resort is nice to know.  I feel this is becoming less of an issue anyway, as the off screen model is being used less and less in favor of accessibility APIs.  Regarding documentation, I find that learning Python is the easy part.  Indeed, in the Window-Eyes scripting manual they do not teach VBScript which is what the overwhelming majority of Window-Eyes scripts have been written in, but all of the examples throughout the scripting manual use VBScript with the assumption that you are familiar with it already.  I find the Python tutorials are sufficient for this task.  Anyway, just thought I’d add my $0.02 to the conversation.

Regards,
Cory
On May 31, 2017, at 9:29 PM, Joseph Lee <[hidden email]> wrote:

Hi,
I didn’t know about accevent until a few years ago when Mick and Jamie mentioned it. Back then, I was a novice, learning about operating systems and compiler design as part of my computer science coursework, and didn’t know the ins and outs of native NVDA API set nor some inner details of Windows internals (this was back in 2013). After experimenting with this tool (yes, part of Windows SDK, which is included with Visual studio), sending in some NVDA patches and reading Windows Internals (Microsoft Press, 2013), I was sort of hooked (as in became somewhat of a frequent user of that tool).
As for how I and others examine programs and what not, that’ll require a lengthy discussion and your participation: exercises. Scripting is programming, and for some, the best way might be to expose you to some things via exercises. But in a nutshell, I don’t use screen scraping techniques for the most part (sometimes, I use screen review to see how an app is laid out); I usually start with reading manuals instead of doing focus.next and what not (at least to immerse myself with questions that users could ask). Then I look at what kind of graphical toolkit was used (api.getForegroundObject().windowClassName), then I’d look at accessibility API’s in use (via navigator object developer info or nvDA+F1 command), then finally I write app modules. This is only a small part when it comes to making app modules, the bigger part being actual testing.
As for the other matter at hand (in reply to another person): looks like we’ll put a stop sign on compatibility layer add-on for a while, as documentation seems to be a better idea. I’ll talk about things I personally do when writing add-ons in the next post.
Cheers,
Joseph
 
 
From: Marlon Brandão de Sousa [[hidden email]]
Sent: Wednesday, May 31, 2017 6:07 PM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?
 
Hello James,

I referred to the windows SDK because of Joseph's response when he said that in order to better understand what is going on on applications he uses accevent which is, accordingly to him, a part of windows SDK… see, I disagree with folks wanting us to teach Python  to them. The same way they had to learn vbs or jaws scripting language they will need to learn python. Every software happens to be written in some language and you have to learn the language the authors have chosen to write it in order to maintain it. I personally do not like python but expecting that I can script NVDA without knowing it just doesn't make sense at all… however, expecting that one simply knows that there is a tool hidden somewhere on windows SDK that will help one to track events on objects without letting them know is also not fair. I don't know if such tool requires one to install the full windows SDK but, if not, a link to download this diagnosis tool needs to be in the developer documentation somewhere. Currently what I miss the most is the kind of autonomy that a feature like home row brings me on NVDA. What I miss the most is I always sit in front at software to be scripted and feel a little bit lost on how to track what is going on on to find our starting point where I can hook myself and start analyzing it. I'm not complaining by no means, I'm only thinking like a typical scripter and trying to see the kind of things one would find Commonli in oder products.
 
If Joseph could write about how he tracks events and inspect the internals of apps to be scripted it would be very very helpful. If he or anybody else could develop an internal feature most like home row Applied to the NVDA context it would be awesome. Who knows maybe I can try to build a msaa and uia navigator from the window one is currently focused on but not now because I'm not skilled enough to do it… But we should definitely join efforts and think on how to build some utilities that would help scripters from all the products to find Their way.
 
Obrigado,
Marlon Brandão de Sousa


Em 31 de mai de 2017, às 20:37, James Teh <[hidden email]> escreveu:

On Thu, Jun 1, 2017 at 5:41 AM, Marlon Brandão de Sousa <[hidden email]> wrote:
One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.
I think everyone agrees on this point. It needs to be done; it's just going to take time.
 
 
Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong.
Not sure what you mean by Windows SDK here. If you mean installing Visual Studio, then sure, I agree... and if we solve the first problem (the API documentation not being online), you will never have to. If you mean MSDN, things get blurrier for me.
 
What I find interesting about the JAWS/Window-Eyes screen reader scripting landscape is that it is very different to plugin expectations for other products, even popular ones. Many other products don't teach you the language they're coded in when you want to write a plugin; they tell you about the API, but you're expected to know concepts about the language (e.g. object oriented programming, etc.). Similarly, if you're calling on stuff from elsewhere, they might give you a brief introduction, but for the most part, they expect you to refer to the documentation on how to use those things. If I'm writing a plugin for foobar2000, Winamp or Cakewalk Sonar, I'm expected to know how to code in C++ and, in the case of Sonar, I'm expected to know COM. But the message I'm seeing here is that screen reader scripters want all of this in one place (even how to code in Python and Win32 concepts, all of which are already well documented elsewhere). I guess that's just how it has been for years, so it's not something we can expect to change, but this is not really how things work elsewhere in the scripting and software development worlds.
 
There's also a limit to how far we can "slim down" the API without majorly limiting the kinds of things you can achieve in NVDA that you just can't achieve elsewhere. For example, you could implement support for an entirely custom editable text control with its own API, including support for font information, spelling errors, etc. It's true that the majority of basic scripting tasks don't require this kind of advanced work, but it also seems silly to intentionally limit that ability.

Jamie
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

Joseph Lee

Hi,

As for an NVDA-specific event tracker and reporter, this can be done with a little hack. Unfortunately, this will break some add-ons, including an add-on of mine that’ll go live very soon.

I think what could help some folks out is a way for seasoned devs to explain the fact that we’re now dealing more with object hierarchy and ways of locating various objects on screen (see a post I sent a few hours ago).

Cheers,

Joseph

 

From: Cory Samaha [mailto:[hidden email]]
Sent: Wednesday, May 31, 2017 10:48 PM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Oh yeah I forgot to mention, WEEvent had the advantage of, not just showing you the IAccessible or UIA events that were being fired, but you could also see which events specific to Window-Eyes were being fired.  For example, if I wanted to see when Window-Eyes was sending something to my synthesizer to be spoken I could select the Speech.OnSpeak event.  I could select various Window events to see if / when their class name, module name or title changed, as well as all of the braille events.  It was a great script for Window-Eyes developers.

 

Cory

On Jun 1, 2017, at 1:10 AM, Cory Samaha <[hidden email]> wrote:

 

Hi Joseph and all,

I have heard of AccEvent.  There was a script that GW Micro wrote back when scripting for Window-Eyes was first being released called WEEvent, which I believe was very much inspired by AccEvent.  However, since WEEvent existed as a Window-Eyes script I never had the need to use AccEvent when I was scripting an app, but I found WEEvent an invaluable tool when I was first looking at a program to script and trying to figure out which events were being fired that I could hook onto.  I’m not suggesting that a similar add-on for NVDA be written since we can get this information through AccEvent, but just thought I’d throw it out there.

 

I also agree with Jamie - I wouldn’t want to dumb something down or exclude some crucial modules that could be useful.  I rarely ever use screen scraping techniques as I find, at least with the Window-Eyes off screen model it can be a bit buggy.  But knowing that something can be scripted that way as a last resort is nice to know.  I feel this is becoming less of an issue anyway, as the off screen model is being used less and less in favor of accessibility APIs.  Regarding documentation, I find that learning Python is the easy part.  Indeed, in the Window-Eyes scripting manual they do not teach VBScript which is what the overwhelming majority of Window-Eyes scripts have been written in, but all of the examples throughout the scripting manual use VBScript with the assumption that you are familiar with it already.  I find the Python tutorials are sufficient for this task.  Anyway, just thought I’d add my $0.02 to the conversation.

 

Regards,

Cory

On May 31, 2017, at 9:29 PM, Joseph Lee <[hidden email]> wrote:

 

Hi,

I didn’t know about accevent until a few years ago when Mick and Jamie mentioned it. Back then, I was a novice, learning about operating systems and compiler design as part of my computer science coursework, and didn’t know the ins and outs of native NVDA API set nor some inner details of Windows internals (this was back in 2013). After experimenting with this tool (yes, part of Windows SDK, which is included with Visual studio), sending in some NVDA patches and reading Windows Internals (Microsoft Press, 2013), I was sort of hooked (as in became somewhat of a frequent user of that tool).

As for how I and others examine programs and what not, that’ll require a lengthy discussion and your participation: exercises. Scripting is programming, and for some, the best way might be to expose you to some things via exercises. But in a nutshell, I don’t use screen scraping techniques for the most part (sometimes, I use screen review to see how an app is laid out); I usually start with reading manuals instead of doing focus.next and what not (at least to immerse myself with questions that users could ask). Then I look at what kind of graphical toolkit was used (api.getForegroundObject().windowClassName), then I’d look at accessibility API’s in use (via navigator object developer info or nvDA+F1 command), then finally I write app modules. This is only a small part when it comes to making app modules, the bigger part being actual testing.

As for the other matter at hand (in reply to another person): looks like we’ll put a stop sign on compatibility layer add-on for a while, as documentation seems to be a better idea. I’ll talk about things I personally do when writing add-ons in the next post.

Cheers,

Joseph

 

 

From: Marlon Brandão de Sousa [[hidden email]]
Sent: Wednesday, May 31, 2017 6:07 PM
To: NVDA screen reader development <[hidden email]>
Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

 

Hello James,

I referred to the windows SDK because of Joseph's response when he said that in order to better understand what is going on on applications he uses accevent which is, accordingly to him, a part of windows SDK… see, I disagree with folks wanting us to teach Python  to them. The same way they had to learn vbs or jaws scripting language they will need to learn python. Every software happens to be written in some language and you have to learn the language the authors have chosen to write it in order to maintain it. I personally do not like python but expecting that I can script NVDA without knowing it just doesn't make sense at all… however, expecting that one simply knows that there is a tool hidden somewhere on windows SDK that will help one to track events on objects without letting them know is also not fair. I don't know if such tool requires one to install the full windows SDK but, if not, a link to download this diagnosis tool needs to be in the developer documentation somewhere. Currently what I miss the most is the kind of autonomy that a feature like home row brings me on NVDA. What I miss the most is I always sit in front at software to be scripted and feel a little bit lost on how to track what is going on on to find our starting point where I can hook myself and start analyzing it. I'm not complaining by no means, I'm only thinking like a typical scripter and trying to see the kind of things one would find Commonli in oder products.

 

If Joseph could write about how he tracks events and inspect the internals of apps to be scripted it would be very very helpful. If he or anybody else could develop an internal feature most like home row Applied to the NVDA context it would be awesome. Who knows maybe I can try to build a msaa and uia navigator from the window one is currently focused on but not now because I'm not skilled enough to do it… But we should definitely join efforts and think on how to build some utilities that would help scripters from all the products to find Their way.

 

Obrigado,
Marlon Brandão de Sousa


Em 31 de mai de 2017, às 20:37, James Teh <[hidden email]> escreveu:

On Thu, Jun 1, 2017 at 5:41 AM, Marlon Brandão de Sousa <[hidden email]> wrote:

One is the following: on a strict scripting vision, if you need to download the source code off watch you are scripting in order to script it then something is definitely wrong.

I think everyone agrees on this point. It needs to be done; it's just going to take time.

 

 

Scripters are not regular nor Advanced developers. They Canby but they don't have to be.  If they have to use windows SDK tools, then something is wrong. If they have even to know what windows SDK is then something is wrong.

Not sure what you mean by Windows SDK here. If you mean installing Visual Studio, then sure, I agree... and if we solve the first problem (the API documentation not being online), you will never have to. If you mean MSDN, things get blurrier for me.

 

What I find interesting about the JAWS/Window-Eyes screen reader scripting landscape is that it is very different to plugin expectations for other products, even popular ones. Many other products don't teach you the language they're coded in when you want to write a plugin; they tell you about the API, but you're expected to know concepts about the language (e.g. object oriented programming, etc.). Similarly, if you're calling on stuff from elsewhere, they might give you a brief introduction, but for the most part, they expect you to refer to the documentation on how to use those things. If I'm writing a plugin for foobar2000, Winamp or Cakewalk Sonar, I'm expected to know how to code in C++ and, in the case of Sonar, I'm expected to know COM. But the message I'm seeing here is that screen reader scripters want all of this in one place (even how to code in Python and Win32 concepts, all of which are already well documented elsewhere). I guess that's just how it has been for years, so it's not something we can expect to change, but this is not really how things work elsewhere in the scripting and software development worlds.

 

There's also a limit to how far we can "slim down" the API without majorly limiting the kinds of things you can achieve in NVDA that you just can't achieve elsewhere. For example, you could implement support for an entirely custom editable text control with its own API, including support for font information, spelling errors, etc. It's true that the majority of basic scripting tasks don't require this kind of advanced work, but it also seems silly to intentionally limit that ability.


Jamie

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, 
Slashdot.org! http://sdm.link/slashdot_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

 

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

James Scholes
In reply to this post by Cory Samaha-2
For what it's worth, I don't think it helps that the project uses
Epydoc, the default output of which is, to me at least, ugly and not
very user-friendly.  Other Python projects use Sphinx, including CPython
itself if I'm not mistaken, to great effect.  I'm aware that switching
the documentation generation and docstring conventions would be a lot of
work, but off the top of my head there are a few advantages to Sphinx:

1. It generates build scripts for Windows and Unix out of the box, which
can be incorporated into an SCons workflow or used on their own without
requiring all of NVDA's dependencies be installed first.

2. Adding those build scripts to continuous integration to update the
development docs every time new code is pushed is trivial.

3. If NVAccess don't want to host the docs themselves, an external
system like Read the Docs can easily be hooked in.

4. And finally, the big one for me.  Sphinx doesn't just emphasise API
documentation, it's an all-round tool for creating good sets of docs for
a project.  Naturally, it can automatically generate markup based on
module, class, method and function docstrings, but the community could
also contribute pages to house examples, tutorials and other
introductory material.  All via the git-based workflow which everyone is
already familiar with.

As I say the effort to move to Sphinx-style docstrings might be more
effort than it's worth at this point.  On the other hand, maybe there is
already a Sphinx extension to interpret Epydod-style ones.
--
James Scholes
http://twitter.com/JamesScholes

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

James Teh
I did a bit of looking into Sphinx this week. On one hand, it incurs a certain amount of redundancy; it's not possible to keep all documentation about the code with the code and so there are concerns about needing to double up in some cases or it not getting updated. On the other hand, it does allow for logical grouping of the content rather than just more or less arbitrary ordering of the methods, etc., as well as allowing explanitory sections to be mixed in with the reference stuff, which I think would really help for something like NVDA.

Aside from converting the existing documentation (or rewriting it from scratch), there is a technical challenge that needs to be considered. Sphinx needs to be able to fully import modules in order for any code doc to be extracted. James, this means you actually can't build on any OS; it has to be Windows, since many of our modules won't import on any other OS. Beyond that, though, there are quite a few NVDA modules that (right or wrong) can't be imported outside of NVDA due to other stuff needing to be initialised. This will improve in time and I've already found ways to hack around some of this for unit testing, but it's nevertheless something we need to account for.

Btw, one other concern I have is that Sphinx uses Restructured Text. If I'm not mistaken, headings in ReST require you to use symbols which match the length of the text you're making into a heading, which is something that turned me right off ReST and IMO is a pretty serious concern for blind devs. However, maybe it's not so strict after all; I haven't checked.

Jamie

Sent from a mobile device

> On 1 Jun 2017, at 8:22 pm, James Scholes <[hidden email]> wrote:
>
> For what it's worth, I don't think it helps that the project uses Epydoc, the default output of which is, to me at least, ugly and not very user-friendly.  Other Python projects use Sphinx, including CPython itself if I'm not mistaken, to great effect.  I'm aware that switching the documentation generation and docstring conventions would be a lot of work, but off the top of my head there are a few advantages to Sphinx:
>
> 1. It generates build scripts for Windows and Unix out of the box, which can be incorporated into an SCons workflow or used on their own without requiring all of NVDA's dependencies be installed first.
>
> 2. Adding those build scripts to continuous integration to update the development docs every time new code is pushed is trivial.
>
> 3. If NVAccess don't want to host the docs themselves, an external system like Read the Docs can easily be hooked in.
>
> 4. And finally, the big one for me.  Sphinx doesn't just emphasise API documentation, it's an all-round tool for creating good sets of docs for a project.  Naturally, it can automatically generate markup based on module, class, method and function docstrings, but the community could also contribute pages to house examples, tutorials and other introductory material.  All via the git-based workflow which everyone is already familiar with.
>
> As I say the effort to move to Sphinx-style docstrings might be more effort than it's worth at this point.  On the other hand, maybe there is already a Sphinx extension to interpret Epydod-style ones.
> --
> James Scholes
> http://twitter.com/JamesScholes
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: For JAWS and/or Window-Eyes scripters: would you like a source code compatibility layer add-on, functions reference wiki, or both?

DaVid
In reply to this post by Joseph Lee
It is interesting. I had never read about accEvent. How can I install this tool?
Well I know, windows sdk includes it.
i read in this thread that is included with visual studio also. I have
visual studio 2015 and I don't see anything related with accEvent.

I tried to install windows SDk on windows 7, but always something
happen and I can't install it. The framework is the problem. I can't
get the correct framework version for this tool.

I'll try on windows 10 later. But i'd like to have this tool in
windows 7, because I currently use both systems.

2017-05-31 10:26 GMT-06:00, Joseph Lee <[hidden email]>:

> Hi Travis and others,
>
>
>
> Regarding documentation: my own add-on development guide should have
> examples of using accessibility API's and have some exercises you can try.
> At the same time, I'm editing the current NVDA Core developer guide to
> broaden the coverage and include more examples of using diverse API's (I'll
> be posting these drafts on a public wiki soon to gather feedback before
> sending it in as a pull request to NV Access).
>
>
>
> Event tracking: I use a combination of my own tracker code and
> Accessibility
> Event Tracker (accevent), the latter available as part of Windows SDK. You
> can ask accevent to give you info on specific events, on specific objects
> and what not, as well as control information gathered. In case of
> IAccessible, you can control scope and whether it should be in-process or
> out of process code. For UIA, you can ask accevent to track specific events
> only.
>
>
>
> In case of my own event tracker code, a rudimentary version is available as
> part of Windows 10 App Essentials add-on. Basically, whenever an event is
> fired by a UIA control, it logs info about the object, the event fired and
> additional information such as UIA automation ID, class name and so on. I
> added this code this year in order to track down controller for event
> inconsistencies (the UIA controller for property event is fired when an
> object notices changes to another object it depends on, such as appearance
> of search suggestions).
>
>
>
> As for Outlook folder navigation problem: as you pointed out, sometimes
> screen scraping doesn't help. There are alternatives out there, including
> accessibility API's, Windows API, and Component Object Model (COM; yes, you
> can let NVDA become a COM client, and this is done in Outlook app module).
> One possible solution might be to locate number of messages in a folder via
> COM (Outlook.Application.something), and it is something that should be
> done
> in NVDA Core.
>
>
>
> As for quick versus thorough scripting: Personally, I prefer both
> approaches
> and have flexibility, although I tend to lean more towards thorough
> scripting. Quick scripting would be things such as screen scraping, using a
> timer to monitor changes in an object (sometimes this is considered
> thorough
> scripting) and solutions that gets the job done for now. Thorough scripting
> would include tracking down events, using overlay classes to represent
> controls in an app, using API's provided by the app and so on. For those
> coming from procedural or imperative languages, object-oriented programming
> is something that requires some practices, and there are developers here
> who
> have experience with functional programming such as use of anonymous
> (lambda) functions, container (list/dictionary/set) comprehensions,
> generators, iterators and so on (these are also found in some add-on code).
> Ultimately, it would be a utopic world if app developers took accessibility
> feedback seriously, thus negating for a need for scripting for certain
> cases
> (more app vendors are starting to take accessibility feedback seriously; a
> good recent example is TeamTalk conferencing system).
>
>
>
> As for approaches people should take and code optimizations: personally, I
> think it is best to let users have access to something sooner than later,
> with room in your code for future extensions. When I review community
> add-ons and see code idiom issues, I usually tell authors to not worry
> about
> those for version 1.0 release, as premature optimization is root of all
> evil
> (Donald Knuth); regarding optimizations, I personally don't optimize code
> until a feature has been in the market for several months (I do optimize to
> some extent during development, but I do leave room for future
> enhancements). In short, what's important is user satisfaction and
> gathering
> feedback so you can improve your code and its quality in the future
> (provided that you're willing to learn more and dive into making things
> better).
>
>
>
> In case of one example sent here: the best solution for getting info from a
> chat program is tracking events and making parts of apps become overlay
> classes (an overlay class is a class that includes scripts, events and what
> not for a particular object or control). Timers are useful if you need to
> monitor an object that does not raise useful events (such as name change,
> value change, state change and what not), and you need to balance between
> speed and accuracy (speed as in how frequently the timer runs, accuracy as
> in making sure important information is spoken and/or brailled).
> Personally,
> I'm not in favor of scripters using Windows key in their gestures (someday,
> your script gestures and Windows 10 commands may conflict), but if that's
> the only way of doing it, then sure.
>
> Cheers,
>
> Joseph
>
>
>
> From: Travis Roth [mailto:[hidden email]]
> Sent: Wednesday, May 31, 2017 6:45 AM
> To: 'NVDA screen reader development' <[hidden email]>
> Subject: Re: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you
> like a source code compatibility layer add-on, functions reference wiki, or
> both?
>
>
>
> Hi,
>
>
>
> Add-on compatibility layer comment: I'd say no to this because if have to
> rewrite/adapt a script anyways I'd just as well use the time to learn the
> NVDA way. Plus this seems like a maintenance nightmare long-term.
>
>
>
> Wiki comments: Yes. As you describe could help. Possibly an extension to
> this which would be equally valuable for me is showing the "NVDA way" to
> accomplish something. Possibly all the ways to do it.
>
> I will give an example to hopefully try to explain.
>
> The best way to make something accessible is to use the accessibility API
> where available, MSAA, UIA, etc. Other ways though are more hacking-style
> if
> you will, e.g., screen scrape and grab what is needed. I feel a lot of JAWS
> scripts in the past use this approach for example.
>
> It would appear to me both of these methods are available with NVDA, but
> only the object way is at all documented. When an API does not exist, or
> the
> scripter just lacks familiarity, the API is not going to work though.
>
> Case in point, I was recently looking at the NVDA bug #5068 which is NVDA
> does not read the number of unread messages in the Outlook folder list.
> NVDA
> can read this number when screen review is used, but does not in its normal
> object mode/focus navigation mode. Ideally the number could be gotten from
> an accessibility object. Poking around the focus object using the Python
> console, it does not appear to be in there. This gives me a question: where
> does screen review come up with the answer? And since it does have it, and
> I
> need the number more than I need a perfect OOO piece of code, how do I get
> it?
>
> In the JAWS world my quick fix for this would end up being something like
> grabbing the text from the screen by the JAWS (mouse) cursor, and
> announcing
> it when the treeItem should be announced possibly using one of the
> SayOjbect
> functions, basically whatever function JAWS ends up triggering to speak
> treeItems in the app. At some later date perhaps I'd rewrite this to use an
> accessibility API if I ever found the source object if it exists.
>
> Considering both of these approaches, the screen scraping I consider a hack
> and/or the quick scripter-style, and the API way the more core screen
> reader
> developer style, it'd be good to know how to do these with NVDA. The API
> way
> I feel has a good start on documentation in the current developer guide,
> though possibly some examples of accessing UIA and MSAA may be helpful.
>
>
>
> Module template: Another thought I have, and I am not sure if I can
> describe
> this accurately, is would there e a way to make a module template that
> defines the various events that a typical object may receive, e.g.,
> event_gotFocus? For the various APIs? Not only a template but could this be
> set up in a way that a scripter could deploy it to a subject application,
> run the application and have the template module log/show the objects and
> events being triggered/followed by NVDA? For example back tto the Outlook
> scenario above, what events is NVDA using to read the folder tree? This is
> probably obvious to a core developer, but less so to a scripter. Perhaps
> NVDA is more consistent than other screen readers so this is not as big a
> deal, my previous experience is part of the fun is finding what will get a
> screen reader to read, and then what is available to read. (The NVDA
> overlay
> classes approach is more elegant than other scripting I've seen so this may
> make life easier long-term.) Part of the question I want to solve quickly
> is: should I be screen scraping, should I be using MSAA, should I be using
> UIA? Some combination?
>
> Hope that makes some sense.
>
>
>
> Anyways thanks for the work.
>
>
>
> Travis Roth
>
>
>
> From: Joseph Lee [mailto:[hidden email]]
> Sent: Wednesday, May 31, 2017 3:40 AM
> To: 'NVDA screen reader development' <[hidden email]
> <mailto:[hidden email]> >
> Subject: [Nvda-devel] For JAWS and/or Window-Eyes scripters: would you like
> a source code compatibility layer add-on, functions reference wiki, or
> both?
>
>
>
> Hi all, mostly for JAWS and/or Window-Eyes scripters:
>
>
>
> I'm looking at FSDN functions reference and Window-Eyes object model docs
> at
> the moment, and was wondering if you have comments about the following
> proposal:
>
>
>
> As part of developer side of Project Contact Lenses, I'm looking into
> creating a functions reference wiki, a source code compatibility layer
> add-on or both. Having a handy reference manual for those coming from other
> screen readers could help some of you in porting your scripts easier by
> looking at functions NVDA expects. On the other hand, having an add-on (a
> global plugin, in fact) that lets you call familiar functions and have it
> translate into equivalent code path in NVDA may help some in gradually
> porting your source code.
>
>
>
> In case of the wiki, it'll consist of tables that list routines you may
> wish
> to do, followed by functions in other screen readers and NVDA equivalent
> like so:
>
>
>
> * Say something: JAWS: SayMessage; NVDA: ui.message or
> speech.speakMessage
>
>
>
> The ad-on version would be something like:
>
>
>
> From globalPlugins.whateverTheNameWillBe.jaws import *
>
>
>
> sayMessage(string)
>
> ->
>
> Speech.speakMessage(string)
>
>
>
> Ultimately, for best experience, it would be best to call functions and use
> objects provided by NVDA, but in the interim, having a compatibility layer
> add-on and/or a functions reference wiki could help. In case of an add-on,
> I'll host a public repository on GitHub so anyone can fork and submit pull
> requests, and the initial version will define popular functions from JAWS
> and/or Window-Eyes.
>
>
>
> Comments are appreciated.
>
> Cheers,
>
> Joseph
>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel