A set of tutorials like Chip did would be great. The problem is there's
virtually no documentation for NVDA scripting. Although I understand
they plan on working on this and may already have something going. I
haven't checked recently.
Next it will be quite a trek for us to transition because we'll have to
learn Python as well as the scripting capabilities of NVDA, which
circles back to my point of there being no documentation. Right now you
have to plow through the source code to see what you can do. And to me,
that's the million dollar question. Without any documentation it's hard
for me to find the time and energy to plow through endless code blocks
in order to figure out what I can do with it when it may or may not meet
my needs.
There's also the question of whether Python 3.x can be used or if 2.x
must be used because it's what NVDA was written in. I say this because
there are some quirks in Python 2.x that are substantial enough that the
original developer of it came back and essentially rewrote it because
there was no other way around that would make it compatible with 2.x.
I'm sure I could get the answer to this easily, but it only adds to the
feeling of being thrown into the sea in order to see if I can swim or not.
As for user windows? It's just another dangling question due to the lack
of documentation.
Regards,
Tom
On 5/30/2017 10:52 AM, Jonathan Cohn via Scripting wrote:
Mr Lee of NVAccess / NVDA proposed on twitter yesterday having a one day
class on scripting NVDA. I guess it is time to learn Python. Anybody
interested in doing a set of regular discussions like Chip did way back to
migrate our common knowledge into NVDA scripting knowledge? I wonder how
difficult it would be to have an NVDA that emulates the favorite parts of
WindowEyes. I expect the hardest part considering that NVDA doesn't appear
to have a virtual mode would be the User Windows functions but then it
seems that WindowEyes wasn't supporting that very aggressively.
Best Wishes,
Jonathan Cohn
On Fri, May 26, 2017 at 7:01 PM Chip Orange via Scripting <
scripting@lists.window-eyes.com> wrote:
Hi David,
You could look at the possibility of running your app as a Windows VBScript
rather than a Window-Eyes VBScript. You'd have to do without the WE
dialogs
and all the other WE features of scripting which we all used, but if you
don't make use of these features very much, you might be able to get a
Windows VBScript version to run. If you could, this would be the easiest
way to get some apps converted away from WE.
VBScript does have some very basic input and output commands (you can
display a dialog and get a string response from the user), this could
possibly be enough for your needs. It has no equivalents to MSAA or
Windows
etc., so nothing which assisted you with accessibility is likely to run.
Of course, Window-Eyes will continue to run for some indefinite amount of
time ... and I'd be glad to share the source code to Remind Me Where with
anyone who'd like to try tinkering with it while it does. If you wanted to
keep something big like it is running, I would guess learning VB.net might
be the closest to what you're used to.
Like Richard, I feel something like the end of Animal Farm as well.
Take care,
Chip
-----Original Message-----
From: Scripting
[mailto:scripting-bounces+lists3717=comcast....@lists.window-eyes.com] On
Behalf Of David via Scripting
Sent: Monday, May 15, 2017 11:49 AM
To: Aaron Smith; Window-Eyes Scripting List
Subject: migrating apps
I do understand that an app that has been developed under the great
scripting capability of WineEyes, will not be possible to simply plug in
under Jaws. At least, it is my understanding, that Jaws has its own
dedicated scripting system.
Still, a number of apps, both officially released and many that I have
developed for my personal usage, would be a great miss when migrating.
Whenever the migrating will be. Smile.
Now, is there a way for me, to make my apps become stand-alone, in the
sense that they could be run under any screen reader? That they still
would be using features like the UI capabilities and other functionality
of for instance GWToolkit? I do understand, that apps that make great
usage of, or directly works with internal features of WinEyes, may not
be possible to run under any other screen readers, since they won't have
any functionality to hook on to. But an app like for instance the
"remind me where", that Chip Orange developed, and which base its main
functionality on information from the net, and greatly on the UI
environment of WinEyes scripting, sould such a program be possible to
make go general? Sure I could have thought of a good number of other
apps that I have come to rely on, and which would have been great to see
under other screen readers.
Guess my basic question is, what would I need to do in my app code, to
make it possible to run outside the WinEyes environment, if that is at
all possible? And if realistic, does there exist any sample code that I
can look at, so as to see it done in practicality?
Thanks,
_______________________________________________
Any views or opinions presented in this email are solely those of the
author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/lists3717
%40comcast.net
<http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/lists3717%40comcast.net>
.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
_______________________________________________
Any views or opinions presented in this email are solely those of the
author and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/jon.c.cohn%40gmail.com
.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com/attachments/20170530/13d902d4/attachment.htm>
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/tom.kingston%40charter.net.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
