Re: Excel charts - next round

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

Re: Excel charts - next round

Dinesh Kaushal

Hi All,

Please review the branch in-t1987-temp at
https://manish_agrawal@.../manish_agrawal/nvda.git

I have restructured the code to add objects for each element of excel chart. I have only created object for excel series and for all other elements there is only 1 object. If overall structure is good, creating objects for other elements is not difficult.

I have also added an appModule for excel. This modules controls connection and disconnection for com events that we are capturing from excel charts.

Regards
Dinesh

------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Testing the new javaw.exe handling in appModule

Isaac Porat
Hi Jamie

I noticed in one of the latest master branch the new ability to launch
appModule correctly for different Java applications which could be
identified before only collectively as Java.exe. - I would like to test
and use this welcomed feature.
I have difficulties finding
the latest code documentation for appModuleHandler.AppModule that you
said describes  this.

Can you please either point me to the right code page or describe in one
line  the code to add to a app module to facilitates this?

For example my code starts a Java class called Launcher in a package
called main (main.Launcher.class)
What would the python code look like?

Thanks
Isaac






------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Teh
On 11/11/2014 4:26 PM, Isaac Porat wrote:
> I noticed in one of the latest master branch the new ability to launch
> appModule correctly for different Java applications which could be
> identified before only collectively as Java.exe.
Currently, this is only done for javaw.exe, not java.exe, since as I
understand it, java.exe is normally for command line applications.
Command line applications are always identified as cmd.exe. I don't
think there's any way we can change this.

> I have difficulties finding
> the latest code documentation for appModuleHandler.AppModule that you
> said describes  this.
That's if you want to implement support for a different launcher; i.e.
something that isn't javaw.exe. The code documentation is the docstring
at the top of the class (appModuleHandler.AppModule):
> Some executables host many different applications; e.g. javaw.exe.
> In this case, it is desirable that a specific app module be loaded for each
> actual application, rather than the one for the hosting executable.
> To support this, the module for the hosting executable
> (not the C{AppModule} class within it) can implement the function
> C{getAppNameFromHost(processId)}, where C{processId} is the id of the host process.
> It should return a unicode string specifying the name that should be used.
> Alternatively, it can raise C{LookupError} if a name couldn't be determined.

See appModules/javaw.py in the NVDA source for the implementation for
javaw.exe.

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

Isaac Porat
Hi Jamie

Thanks for the info.
First my mistake I meant javaw.exe not java.exe

To be absolutely clear if I have an executable launcher called
MyLauncher.exe which in turn calls javaw.exe with say a class
main.JavaApp.class

I return in the function you mentioned the string 'MyLauncher'?

Thanks
Isaac


On 11/11/2014 06:33, James Teh wrote:

> On 11/11/2014 4:26 PM, Isaac Porat wrote:
>> I noticed in one of the latest master branch the new ability to launch
>> appModule correctly for different Java applications which could be
>> identified before only collectively as Java.exe.
> Currently, this is only done for javaw.exe, not java.exe, since as I
> understand it, java.exe is normally for command line applications.
> Command line applications are always identified as cmd.exe. I don't
> think there's any way we can change this.
>
>> I have difficulties finding
>> the latest code documentation for appModuleHandler.AppModule that you
>> said describes  this.
> That's if you want to implement support for a different launcher; i.e.
> something that isn't javaw.exe. The code documentation is the docstring
> at the top of the class (appModuleHandler.AppModule):
>> Some executables host many different applications; e.g. javaw.exe.
>> In this case, it is desirable that a specific app module be loaded for each
>> actual application, rather than the one for the hosting executable.
>> To support this, the module for the hosting executable
>> (not the C{AppModule} class within it) can implement the function
>> C{getAppNameFromHost(processId)}, where C{processId} is the id of the host process.
>> It should return a unicode string specifying the name that should be used.
>> Alternatively, it can raise C{LookupError} if a name couldn't be determined.
> See appModules/javaw.py in the NVDA source for the implementation for
> javaw.exe.
>
> Jamie
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Teh
If you're using javaw.exe, you shouldn't have to do anything. NVDA
master should already use a specific app module for your app.

Jamie

On 11/11/2014 4:58 PM, Isaac Porat wrote:

> Hi Jamie
>
> Thanks for the info.
> First my mistake I meant javaw.exe not java.exe
>
> To be absolutely clear if I have an executable launcher called
> MyLauncher.exe which in turn calls javaw.exe with say a class
> main.JavaApp.class
>
> I return in the function you mentioned the string 'MyLauncher'?
>
> Thanks
> Isaac
>
>
> On 11/11/2014 06:33, James Teh wrote:
>> On 11/11/2014 4:26 PM, Isaac Porat wrote:
>>> I noticed in one of the latest master branch the new ability to launch
>>> appModule correctly for different Java applications which could be
>>> identified before only collectively as Java.exe.
>> Currently, this is only done for javaw.exe, not java.exe, since as I
>> understand it, java.exe is normally for command line applications.
>> Command line applications are always identified as cmd.exe. I don't
>> think there's any way we can change this.
>>
>>> I have difficulties finding
>>> the latest code documentation for appModuleHandler.AppModule that you
>>> said describes  this.
>> That's if you want to implement support for a different launcher; i.e.
>> something that isn't javaw.exe. The code documentation is the docstring
>> at the top of the class (appModuleHandler.AppModule):
>>> Some executables host many different applications; e.g. javaw.exe.
>>> In this case, it is desirable that a specific app module be loaded for each
>>> actual application, rather than the one for the hosting executable.
>>> To support this, the module for the hosting executable
>>> (not the C{AppModule} class within it) can implement the function
>>> C{getAppNameFromHost(processId)}, where C{processId} is the id of the host process.
>>> It should return a unicode string specifying the name that should be used.
>>> Alternatively, it can raise C{LookupError} if a name couldn't be determined.
>> See appModules/javaw.py in the NVDA source for the implementation for
>> javaw.exe.
>>
>> Jamie
>>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

Isaac Porat
Hi again

Let me explain myself better (I am a Java programmer not a python one
but I am happy to learn whatever I need to make this work.

Until the latest javaw.exe handling, I used a simple app module which I
placed in the NVDA user setting under appModules.  It is called javaw.py
and it sent NVDA to sleep as my Java application is self voicing.
Of course until now it would do the same for any javaw.exe which is not
desirable.

So I am trying to write instead a simple app module specific to my Java
application.

To try to find out what NVDA thinks my application name is when it has
the focus (I disabled the app module mentioned above) I brought up the
profile dialog > New and found that it thinks that it is:
Current application (javaw_"-XX:+UseConcMarkSweepGC")

So my question is what do I call my app module?
I tried some variations of the above name it does not seem to work - of
course I might have got it wrong again.

Thanks
Isaac


On 11/11/2014 07:09, James Teh wrote:

> If you're using javaw.exe, you shouldn't have to do anything. NVDA
> master should already use a specific app module for your app.
>
> Jamie
>
> On 11/11/2014 4:58 PM, Isaac Porat wrote:
>> Hi Jamie
>>
>> Thanks for the info.
>> First my mistake I meant javaw.exe not java.exe
>>
>> To be absolutely clear if I have an executable launcher called
>> MyLauncher.exe which in turn calls javaw.exe with say a class
>> main.JavaApp.class
>>
>> I return in the function you mentioned the string 'MyLauncher'?
>>
>> Thanks
>> Isaac
>>
>>
>> On 11/11/2014 06:33, James Teh wrote:
>>> On 11/11/2014 4:26 PM, Isaac Porat wrote:
>>>> I noticed in one of the latest master branch the new ability to launch
>>>> appModule correctly for different Java applications which could be
>>>> identified before only collectively as Java.exe.
>>> Currently, this is only done for javaw.exe, not java.exe, since as I
>>> understand it, java.exe is normally for command line applications.
>>> Command line applications are always identified as cmd.exe. I don't
>>> think there's any way we can change this.
>>>
>>>> I have difficulties finding
>>>> the latest code documentation for appModuleHandler.AppModule that you
>>>> said describes  this.
>>> That's if you want to implement support for a different launcher; i.e.
>>> something that isn't javaw.exe. The code documentation is the docstring
>>> at the top of the class (appModuleHandler.AppModule):
>>>> Some executables host many different applications; e.g. javaw.exe.
>>>> In this case, it is desirable that a specific app module be loaded for each
>>>> actual application, rather than the one for the hosting executable.
>>>> To support this, the module for the hosting executable
>>>> (not the C{AppModule} class within it) can implement the function
>>>> C{getAppNameFromHost(processId)}, where C{processId} is the id of the host process.
>>>> It should return a unicode string specifying the name that should be used.
>>>> Alternatively, it can raise C{LookupError} if a name couldn't be determined.
>>> See appModules/javaw.py in the NVDA source for the implementation for
>>> javaw.exe.
>>>
>>> Jamie
>>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Teh
On 11/11/2014 6:17 PM, Isaac Porat wrote:
> To try to find out what NVDA thinks my application name is when it has
> the focus (I disabled the app module mentioned above) I brought up the
> profile dialog > New and found that it thinks that it is:
> Current application (javaw_"-XX:+UseConcMarkSweepGC")
Oh dear. NVDA is definitely getting that wrong. Are you able to give me
the exact command line your launcher launches javaw.exe with?

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

Isaac Porat
Hi Jamie

In reply to your question the command line my launcher (called
MediaSuite.exe) uses is:
javaw -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -cp
lib/ext/*;lib/felix.jar;TCLauncher.jar main.TCLauncher %*
(the %* at the end indicate various optional variables)

The self voicing Java based application I distribute is used by the
blind community and is called SpeakOn MediaSuite
You can install it in a minute from:
http://www.speakon.org.uk/SpeakOn/install/SpeakOn-MediaSuiteInstall.exe
You don't have to learn how to use it, just launch it from the shortcut
on the desktop and see what NVDA detects.
The SpeakOn MediaSuite home page if you need more info  is at:
http://www.speakon.org.uk/SpeakOn.html

If you need more information about the launcher etc you might want to
contact me directly at:
[hidden email]

Thanks
Isaac





On 11/11/2014 10:02, James Teh wrote:

> On 11/11/2014 6:17 PM, Isaac Porat wrote:
>> To try to find out what NVDA thinks my application name is when it has
>> the focus (I disabled the app module mentioned above) I brought up the
>> profile dialog > New and found that it thinks that it is:
>> Current application (javaw_"-XX:+UseConcMarkSweepGC")
> Oh dear. NVDA is definitely getting that wrong. Are you able to give me
> the exact command line your launcher launches javaw.exe with?
>
> Jamie
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Teh
On 12/11/2014 12:13 AM, Isaac Porat wrote:
> In reply to your question the command line my launcher (called
> MediaSuite.exe)
Strange. If that is the executable of the parent process, NVDA should
have used that as the app module name. Does it use ShellExecute or
something to run javaw?

> javaw -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -cp
> lib/ext/*;lib/felix.jar;TCLauncher.jar main.TCLauncher %*
Based on the app name NVDA is deriving
(javaw_"-XX:+UseConcMarkSweepGC"), it looks like some of those options
ahve quotes around them, which NVDA isn't currently expecting. However,
the command line you provided above doesn't have quotes. Do you have any
idea where the quotes are getting added?

Even once we resolve that, there is another problem, which is that -cp
uses a space instead of a colon to separate its argument. Again, NVDA
isn't expecting this; I initially thought Java always used a colon
because that's all I had ever seen.

We need to be able to parse the Java command line to extract the launch
class (in this case, main.TCLauncher). The aim is that NVDA would derive
an app module name of javaw_main_TCLauncher. Do you know the rules
concerning the Java command line? For example, are there only specific
options that can use a space to separate their arguments or is this
possible for all options which accept arguments?

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Teh
In reply to this post by Isaac Porat
Hi Isaac,

I made some significant fixes to this code in commit 4f696962. These
should be available to test in today's (12 November) master snapshot.
This should result in an app module name of javaw_main_TCLauncher for
your app. Please test and report.

Thanks,
Jamie

On 12/11/2014 12:13 AM, Isaac Porat wrote:

> Hi Jamie
>
> In reply to your question the command line my launcher (called
> MediaSuite.exe) uses is:
> javaw -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -cp
> lib/ext/*;lib/felix.jar;TCLauncher.jar main.TCLauncher %*
> (the %* at the end indicate various optional variables)
>
> The self voicing Java based application I distribute is used by the
> blind community and is called SpeakOn MediaSuite
> You can install it in a minute from:
> http://www.speakon.org.uk/SpeakOn/install/SpeakOn-MediaSuiteInstall.exe
> You don't have to learn how to use it, just launch it from the shortcut
> on the desktop and see what NVDA detects.
> The SpeakOn MediaSuite home page if you need more info  is at:
> http://www.speakon.org.uk/SpeakOn.html
>
> If you need more information about the launcher etc you might want to
> contact me directly at:
> [hidden email]
>
> Thanks
> Isaac
>
>
>
>
>
> On 11/11/2014 10:02, James Teh wrote:
>> On 11/11/2014 6:17 PM, Isaac Porat wrote:
>>> To try to find out what NVDA thinks my application name is when it has
>>> the focus (I disabled the app module mentioned above) I brought up the
>>> profile dialog > New and found that it thinks that it is:
>>> Current application (javaw_"-XX:+UseConcMarkSweepGC")
>> Oh dear. NVDA is definitely getting that wrong. Are you able to give me
>> the exact command line your launcher launches javaw.exe with?
>>
>> Jamie
>>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

Isaac Porat
In reply to this post by James Teh
Hi

I wrote the launcher in NSIS script This in turn might be using shell, I
don't know.
   While the name of the executable for the app module is desirable, it
is perhaps not essential  as long as it is unique and the characters are
legal for file names.

It is not clear to me, did you actually run my program or are you
referring only to the info in my email?

As you can see from the command line supplied the arguments in the
classpath are separated by semicolon which is used in Windows, colon is
used I think in Linux - I can check.

Regards
Isaac



On 11/11/2014 23:28, James Teh wrote:

> On 12/11/2014 12:13 AM, Isaac Porat wrote:
>> In reply to your question the command line my launcher (called
>> MediaSuite.exe)
> Strange. If that is the executable of the parent process, NVDA should
> have used that as the app module name. Does it use ShellExecute or
> something to run javaw?
>
>> javaw -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -cp
>> lib/ext/*;lib/felix.jar;TCLauncher.jar main.TCLauncher %*
> Based on the app name NVDA is deriving
> (javaw_"-XX:+UseConcMarkSweepGC"), it looks like some of those options
> ahve quotes around them, which NVDA isn't currently expecting. However,
> the command line you provided above doesn't have quotes. Do you have any
> idea where the quotes are getting added?
>
> Even once we resolve that, there is another problem, which is that -cp
> uses a space instead of a colon to separate its argument. Again, NVDA
> isn't expecting this; I initially thought Java always used a colon
> because that's all I had ever seen.
>
> We need to be able to parse the Java command line to extract the launch
> class (in this case, main.TCLauncher). The aim is that NVDA would derive
> an app module name of javaw_main_TCLauncher. Do you know the rules
> concerning the Java command line? For example, are there only specific
> options that can use a space to separate their arguments or is this
> possible for all options which accept arguments?
>
> Jamie
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

Isaac Porat
Hi again

Few more thoughts...

1.  I came across  applications that wrap command line arguments with
quotes to prevent ambiguity so if my executable launcher does this under
the hood it is not surprising and other launcher unless written
specifically might do the same thing.

2.  If you meant that the -cp (or -classpath) argumenst have a space
after them, this is the way as far as I know it should be.  paths within
the argument that follows are separated by a semicolon.

3 You might consider identifying the java application by its entry class
perhaps including its package in my case main.Launcher

With the above in mind you might consider the following strategy:

1 Split the command line based on double quotes if exists (like the
shell itself) into parts.

2 After javaw itself Start iterate through the arguments discarding
those that are prefixed with '-' If you come across the -cp or
-classpath discard the argument that comes after that.

4 With the above the first argument that you come across without the -
prefix should be the Java entry class including the package it belongs
to; all other arguments after that are the Java application arguments
and should be ignored.

The above is based on the assumption that only the -cp and -classpath
argument point to another argument after them - I might be wrong but I
did not come across other examples like that.

I hope the above is of some use.

Regards
Isaac
  On 12/11/2014 06:48, Isaac Porat wrote:

> Hi
>
> I wrote the launcher in NSIS script This in turn might be using shell, I
> don't know.
>     While the name of the executable for the app module is desirable, it
> is perhaps not essential  as long as it is unique and the characters are
> legal for file names.
>
> It is not clear to me, did you actually run my program or are you
> referring only to the info in my email?
>
> As you can see from the command line supplied the arguments in the
> classpath are separated by semicolon which is used in Windows, colon is
> used I think in Linux - I can check.
>
> Regards
> Isaac
>
>
>
> On 11/11/2014 23:28, James Teh wrote:
>> On 12/11/2014 12:13 AM, Isaac Porat wrote:
>>> In reply to your question the command line my launcher (called
>>> MediaSuite.exe)
>> Strange. If that is the executable of the parent process, NVDA should
>> have used that as the app module name. Does it use ShellExecute or
>> something to run javaw?
>>
>>> javaw -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -cp
>>> lib/ext/*;lib/felix.jar;TCLauncher.jar main.TCLauncher %*
>> Based on the app name NVDA is deriving
>> (javaw_"-XX:+UseConcMarkSweepGC"), it looks like some of those options
>> ahve quotes around them, which NVDA isn't currently expecting. However,
>> the command line you provided above doesn't have quotes. Do you have any
>> idea where the quotes are getting added?
>>
>> Even once we resolve that, there is another problem, which is that -cp
>> uses a space instead of a colon to separate its argument. Again, NVDA
>> isn't expecting this; I initially thought Java always used a colon
>> because that's all I had ever seen.
>>
>> We need to be able to parse the Java command line to extract the launch
>> class (in this case, main.TCLauncher). The aim is that NVDA would derive
>> an app module name of javaw_main_TCLauncher. Do you know the rules
>> concerning the Java command line? For example, are there only specific
>> options that can use a space to separate their arguments or is this
>> possible for all options which accept arguments?
>>
>> Jamie
>>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Teh
Hi.
I've already done all of this as of a few hours ago; see subsequent email.

Thanks,
Jamie

On 12/11/2014 7:08 PM, Isaac Porat wrote:

> Hi again
>
> Few more thoughts...
>
> 1.  I came across  applications that wrap command line arguments with
> quotes to prevent ambiguity so if my executable launcher does this under
> the hood it is not surprising and other launcher unless written
> specifically might do the same thing.
>
> 2.  If you meant that the -cp (or -classpath) argumenst have a space
> after them, this is the way as far as I know it should be.  paths within
> the argument that follows are separated by a semicolon.
>
> 3 You might consider identifying the java application by its entry class
> perhaps including its package in my case main.Launcher
>
> With the above in mind you might consider the following strategy:
>
> 1 Split the command line based on double quotes if exists (like the
> shell itself) into parts.
>
> 2 After javaw itself Start iterate through the arguments discarding
> those that are prefixed with '-' If you come across the -cp or
> -classpath discard the argument that comes after that.
>
> 4 With the above the first argument that you come across without the -
> prefix should be the Java entry class including the package it belongs
> to; all other arguments after that are the Java application arguments
> and should be ignored.
>
> The above is based on the assumption that only the -cp and -classpath
> argument point to another argument after them - I might be wrong but I
> did not come across other examples like that.
>
> I hope the above is of some use.
>
> Regards
> Isaac

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

Isaac Porat
In reply to this post by James Teh
Hi Jamie

I just tested your fix, good job, it works well.

On a functionality related point, as a self voicing application, the
sole purpose of my app module is to send NVDA to sleep when my app has
the focus.  So one day, when you work on profiles again, it would be
nice to have the sleep feature incorporated as part of the profile
recorded attributes; I filled a feature request for this I think last
December.
Jaws (which I don't use any more) implements this feature nicely, the
other two big commercials provide this in a non friendly manner.  Of
course this feature is not essential but allow that little bit easier
integration of NVDA use with self voicing applications.

Many thanks
Isaac
On 12/11/2014 03:37, James Teh wrote:

> Hi Isaac,
>
> I made some significant fixes to this code in commit 4f696962. These
> should be available to test in today's (12 November) master snapshot.
> This should result in an app module name of javaw_main_TCLauncher for
> your app. Please test and report.
>
> Thanks,
> Jamie
>
> On 12/11/2014 12:13 AM, Isaac Porat wrote:
>> Hi Jamie
>>
>> In reply to your question the command line my launcher (called
>> MediaSuite.exe) uses is:
>> javaw -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -cp
>> lib/ext/*;lib/felix.jar;TCLauncher.jar main.TCLauncher %*
>> (the %* at the end indicate various optional variables)
>>
>> The self voicing Java based application I distribute is used by the
>> blind community and is called SpeakOn MediaSuite
>> You can install it in a minute from:
>> http://www.speakon.org.uk/SpeakOn/install/SpeakOn-MediaSuiteInstall.exe
>> You don't have to learn how to use it, just launch it from the shortcut
>> on the desktop and see what NVDA detects.
>> The SpeakOn MediaSuite home page if you need more info  is at:
>> http://www.speakon.org.uk/SpeakOn.html
>>
>> If you need more information about the launcher etc you might want to
>> contact me directly at:
>> [hidden email]
>>
>> Thanks
>> Isaac
>>
>>
>>
>>
>>
>> On 11/11/2014 10:02, James Teh wrote:
>>> On 11/11/2014 6:17 PM, Isaac Porat wrote:
>>>> To try to find out what NVDA thinks my application name is when it has
>>>> the focus (I disabled the app module mentioned above) I brought up the
>>>> profile dialog > New and found that it thinks that it is:
>>>> Current application (javaw_"-XX:+UseConcMarkSweepGC")
>>> Oh dear. NVDA is definitely getting that wrong. Are you able to give me
>>> the exact command line your launcher launches javaw.exe with?
>>>
>>> Jamie
>>>
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Nvda-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>>


------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Testing the new javaw.exe handling in appModule

James Scholes
Isaac Porat wrote:
> On a functionality related point, as a self voicing application, the
> sole purpose of my app module is to send NVDA to sleep when my app has
> the focus.  So one day, when you work on profiles again, it would be
> nice to have the sleep feature incorporated as part of the profile
> recorded attributes; I filled a feature request for this I think last
> December.

This is a somewhat unrelated point, but as a user of a number of
self-voicing applications, it is extremely frustrating for me when they
put my screen reader to sleep and speak using SAPI or similar.  The
functionality exists to have your application speak through NVDA and
other screen readers, and I can't tell you how much it improves the user
experience if they do so.
--
James Scholes
http://twitter.com/JamesScholes

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Preventing touch interception in NVDA sleep mode

Isaac Porat
In reply to this post by Isaac Porat
Hi Jamie

I added touch capabilities to my self voicing Java application.  I was
hoping that my application could operate alongside NVDA in sleep mode in
the same way it does using the keyboard but it seems that NVDA
intercepts touch even in sleep mode.  Unless I miss something I would
have thought that in sleep mode NVDA should let touch through to be as
transparent to the application as possible, am I missing something?

Is there something I can do in the short term about this? I have an app
module which set NVDA in sleep mode when my application has the focus
and this works well with the keyboard.  Is it possible to add simple
python code to prevent NVDA from intercepting touch?

Many thanks
Isaac


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Preventing touch interception in NVDA sleep mode

Isaac Porat
Hello

The following would hopefully be of use to those developers interested
in touch

I had touch capabilities on my Windows 8.1 laptop for over a year but
until recently I regarded touch interface for the blind in Windows to be
no more than a impractical curiosity.  Recently, with the price of small
Windows 8.1 tablets falling significantly I decided it is the time to
take the plunge.

My application is written in Java, it is self voicing but the following
applies equally to standard application written in any language that
implement touch.
In Java I could have used JavaFX components which support touch fully
but instead I decided to use the standard Swing components and used the
mouse events generated by a touch screen.  This approach although
limited only to single finger touch  allowed me also to be able to use a
standard touch pad for those that do not have a touch screen.  I
processed touch myself implementing explore by touch and gestures.  If
nothing else this was good fun and works well.

When trying to use my application alongside NVDA I found that NVDA keeps
intercepting touch events even in sleep mode which meant that I had to
switch NVDA off to allow my application to work with touch.
As this approach was cumbersome and required a keyboard this would have
made using a tablet without a keyboard impossible with my application.

Following posting the original message on this thread, Joseph Lee kindly
replied on the users list pointing to various issues in tackling this
and letting me know that another user already has filled a relevant bug
report that was followed by useful discussion here:
  http://ehc.ac/p/nvda/lists/message/32576784/

Based on the above I decided to write a simple app module to put NVDA in
sleep mode and disable its gesture interception.  This works very well
but the ideal solution is to make the sleep mode pass touch events
transparently like it does with keyboard and mouse events. Also sleep
mode could benefit in being part of NVDA's profile capabilities so users
don't have to do this manually or employ an app module for this; Jaws
uses this approach.

Based on my experience so far with touch you might consider  the following:

* To take advantage of specific gesture capabilities in applications, to
add a transparent mode to those available already for touch. Of course
users need to be able to switch back to NVDA control and to achieve
this, perhaps NvDA should retain one gesture say three fingers tap and
pass the rest to the application in this transparent mode.

*  To add a key emulation mode which would be able to transform simple
gestures to keys and send them  to the application in focus.
Keys that come to mind are Tab, Alt, Up, Down, Left and Right, perhaps
Escape.  This approach would allow communication with traditional
applications and thus make some these accessible with touch.

Regards
Isaac



On 15/01/2015 11:21, Isaac Porat wrote:

> Hi Jamie
>
> I added touch capabilities to my self voicing Java application.  I was
> hoping that my application could operate alongside NVDA in sleep mode in
> the same way it does using the keyboard but it seems that NVDA
> intercepts touch even in sleep mode.  Unless I miss something I would
> have thought that in sleep mode NVDA should let touch through to be as
> transparent to the application as possible, am I missing something?
>
> Is there something I can do in the short term about this? I have an app
> module which set NVDA in sleep mode when my application has the focus
> and this works well with the keyboard.  Is it possible to add simple
> python code to prevent NVDA from intercepting touch?
>
> Many thanks
> Isaac
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Preventing touch interception in NVDA sleep mode

James Teh
Thanks for your thoughts. Replies inline:

On 22/01/2015 6:50 PM, Isaac Porat wrote:
> the ideal solution is to make the sleep mode pass touch events
> transparently like it does with keyboard and mouse events.
The problem is that once you're in this mode, you would be stuck there.
See below.

> Also sleep
> mode could benefit in being part of NVDA's profile capabilities so users
> don't have to do this manually or employ an app module for this.
NVDA profiles arent just application specific. It would be impossible to
save this setting while a profile is manually activated, as you have to
turn off sleep mode to get to the Profiles dialog. Still, I guess it
could be okay to allow this at least for application specific ones.

That said, it's worth noting that most apps that require sleep mode
require it for multiple users, not just one. Therefore, it does make a
certain amount of sense to do sleep mode in app modules, as they can
then be bundled as add-ons or even with NVDA itself.

> * To take advantage of specific gesture capabilities in applications, to
> add a transparent mode to those available already for touch. Of course
> users need to be able to switch back to NVDA control and to achieve
> this, perhaps NvDA should retain one gesture say three fingers tap and
> pass the rest to the application in this transparent mode.
Unfortunately, there's no way to let touch gestures through, so we'd
have to explicitly forward gestures to the application. There are a lot
of problems this could cause, but my main concern is that we can't trap
one gesture without impacting all others. For example, if we want to
trap 3 finger tap, we'd have to trap the first finger down, the second
finger down and the third finger down. If a user did a single finger
hover, we couldn't pass that to the application until after NVDA's
timeout for a 3 finger tap had elapsed. That's far from transparent. The
only thing that might possibly work is a certain area of the screen that
is reserved for NVDA, but that would probably be different for every
application, so you'd need to define the direct touch zone in an app module.

Regardless, something like this is definitely desirable. Please post
your thoughts on the ticket.

> *  To add a key emulation mode which would be able to transform simple
> gestures to keys and send them  to the application in focus.
> Keys that come to mind are Tab, Alt, Up, Down, Left and Right, perhaps
> Escape.  This approach would allow communication with traditional
> applications and thus make some these accessible with touch.
I don't think this is in scope for NVDA. You can already use NVDA
commands which facilitates access. It's true that using the keyboard can
be more efficient, but this is just as true for sighted users in some cases.

Jamie

--
James Teh
Executive Director, NV Access Limited
Ph +61 7 3149 3306
www.nvaccess.org
Facebook: http://www.facebook.com/NVAccess
Twitter: @NVAccess
SIP: [hidden email]

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Preventing touch interception in NVDA sleep mode

Isaac Porat
Hi Jamie

Thanks for your reply. I had problems emailing to the track system in
the past so until I sort it out, my further thoughts  below.

the ideal solution is to make the sleep mode pass touch events
transparently like it does with keyboard and mouse events.
The problem is that once you're in this mode, you would be stuck there.
See below.
IP
Point taken, See suggestion below

Also sleep
mode could benefit in being part of NVDA's profile capabilities so users
don't have to do this manually or employ an app module for this.
NVDA profiles arent just application specific. It would be impossible to
save this setting while a profile is manually activated, as you have to
turn off sleep mode to get to the Profiles dialog. Still, I guess it
could be okay to allow this at least for application specific ones.

That said, it's worth noting that most apps that require sleep mode
require it for multiple users, not just one. Therefore, it does make a
certain amount of sense to do sleep mode in app modules, as they can
then be bundled as add-ons or even with NVDA itself.

IP
Point taken, as you suggest sleep mode in profiles only for specific
application would do the job as it would make life easier for users.
(I filled a ticket for this about a year ago)

Regarding supplying the add-on with the applications, this of course
possible.
Before add-on were introduced it would have been possible for an
application to install its app module directly.  I fully understand why
this presented problems and add-on where introduced among other things I
suppose so that NVDA can ensures as much as possible correct
installation etc.
It would be good however if say my application installer could put the
add-on in a particular place in the NVDA directory structure and when a
user restart NVDA it would prompt him to install the add-on.
My experience in the past is that providing an add-on with the installer
presents another complexity to the user in trying to find the add-on.
The alternative of providing the add-on on the web introduced another
complexity because the version of the app installed by the user and its
add-on can get out of sync. What I am suggesting might already exists -
I am not aware of this.

* To take advantage of specific gesture capabilities in applications, to
add a transparent mode to those available already for touch. Of course
users need to be able to switch back to NVDA control and to achieve
this, perhaps NvDA should retain one gesture say three fingers tap and
pass the rest to the application in this transparent mode.
Unfortunately, there's no way to let touch gestures through, so we'd
have to explicitly forward gestures to the application. There are a lot
of problems this could cause, but my main concern is that we can't trap
one gesture without impacting all others. For example, if we want to
trap 3 finger tap, we'd have to trap the first finger down, the second
finger down and the third finger down. If a user did a single finger
hover, we couldn't pass that to the application until after NVDA's
timeout for a 3 finger tap had elapsed. That's far from transparent. The
only thing that might possibly work is a certain area of the screen that
is reserved for NVDA, but that would probably be different for every
application, so you'd need to define the direct touch zone in an app
module.

Regardless, something like this is definitely desirable. Please post
your thoughts on the ticket.


IP
Point taken, what about doing the following:
When a touch events arrives you take a copy of it and then immediately
forward it to the application.  the copy obtained is forward in parallel
to the NVDA touch processor, which can then detect the 'special'
switching back gesture.  One might argue that in some edge cases some
rubbish touch event would have gone to the application before the
detection but I think in practice this probably work just fine.

*  To add a key emulation mode which would be able to transform simple
gestures to keys and send them  to the application in focus.
Keys that come to mind are Tab, Alt, Up, Down, Left and Right, perhaps
Escape.  This approach would allow communication with traditional
applications and thus make some these accessible with touch.

I don't think this is in scope for NVDA. You can already use NVDA
commands which facilitates access. It's true that using the keyboard can

be more efficient, but this is just as true for sighted users in some
cases.

IP
 From a purist point of view one might argue that a screen reader should
not modify anything going to the application but in practice it has to
do some of this already.
If you can emulate certain keys with gestures imagine how much easier it
would be to find a button with an emulated Tab rather than trying to
hunt for it in a cluttered application with touch.
In another example, Sighted users do not need menus as much as blind
users do as lots of stuff is available in tools etc many times difficult
to access (especially with touch)  again imagine how much easier it
would be to get to the menu with an emulated Alt and then go Up and Down
with these emulated.
Perhaps a third party add-on could do this.
Thanks
Isaac


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|

Re: Preventing touch interception in NVDA sleep mode

Joseph Lee
Hi Isaac and others,
Regarding keyboard emulation, I'm of the opinion that some of the keys
should not have touch equivalents, as they're readily available. A good
example is Alt key - one can use taps to locate the menu bar, provided that
the user remembers where the menu bar is located (usually at the top, but
sometimes it's somewhere else). Same could be said about Windows key - for
8.1 and later, one can double tap bottom left corner to open the Start
screen, but in some cases, NVDA's idea of focus object gets out of sync with
system's view of focused controls.
In my case, when I recorded the touchscreen tutorial in 2013, I used one
finger tap to locate the menu bar - that is, moved my finger around the
screen to locate various parts of an app.
I once thought about adding keyboard emulation mode in my own add-on, but
Jamie pointed out that it isn't ideal, so I decided not to do it. I proposed
that mode in order to navigate combo boxes with touch (if you want a feel of
what I'm talking about, try navigating combo boxes just using object
navigation). Plus, Jamie says he is thinking about rewriting how current
touchscreen support works (namely a possibility to remove touch modes) and
since there are a lot of work to do regarding touch, I decided to take a
break from touch support to concentrate on other things (other add-ons,
QWERTY braille display support, etc.).
P.S. Just a thought: would you like to join NVDACon and bring this issue up
with other developers so we can brainstorm about this?
Cheers,
Joseph

-----Original Message-----
From: Isaac Porat [mailto:[hidden email]]
Sent: Friday, January 23, 2015 1:03 AM
To: NVDA screen reader development
Subject: Re: [Nvda-devel] Preventing touch interception in NVDA sleep mode

Hi Jamie

Thanks for your reply. I had problems emailing to the track system in the
past so until I sort it out, my further thoughts  below.

the ideal solution is to make the sleep mode pass touch events transparently
like it does with keyboard and mouse events.
The problem is that once you're in this mode, you would be stuck there.
See below.
IP
Point taken, See suggestion below

Also sleep
mode could benefit in being part of NVDA's profile capabilities so users
don't have to do this manually or employ an app module for this.
NVDA profiles arent just application specific. It would be impossible to
save this setting while a profile is manually activated, as you have to turn
off sleep mode to get to the Profiles dialog. Still, I guess it could be
okay to allow this at least for application specific ones.

That said, it's worth noting that most apps that require sleep mode require
it for multiple users, not just one. Therefore, it does make a certain
amount of sense to do sleep mode in app modules, as they can then be bundled
as add-ons or even with NVDA itself.

IP
Point taken, as you suggest sleep mode in profiles only for specific
application would do the job as it would make life easier for users.
(I filled a ticket for this about a year ago)

Regarding supplying the add-on with the applications, this of course
possible.
Before add-on were introduced it would have been possible for an application
to install its app module directly.  I fully understand why this presented
problems and add-on where introduced among other things I suppose so that
NVDA can ensures as much as possible correct installation etc.
It would be good however if say my application installer could put the
add-on in a particular place in the NVDA directory structure and when a user
restart NVDA it would prompt him to install the add-on.
My experience in the past is that providing an add-on with the installer
presents another complexity to the user in trying to find the add-on.
The alternative of providing the add-on on the web introduced another
complexity because the version of the app installed by the user and its
add-on can get out of sync. What I am suggesting might already exists - I am
not aware of this.

* To take advantage of specific gesture capabilities in applications, to add
a transparent mode to those available already for touch. Of course users
need to be able to switch back to NVDA control and to achieve this, perhaps
NvDA should retain one gesture say three fingers tap and pass the rest to
the application in this transparent mode.
Unfortunately, there's no way to let touch gestures through, so we'd have to
explicitly forward gestures to the application. There are a lot of problems
this could cause, but my main concern is that we can't trap one gesture
without impacting all others. For example, if we want to trap 3 finger tap,
we'd have to trap the first finger down, the second finger down and the
third finger down. If a user did a single finger hover, we couldn't pass
that to the application until after NVDA's timeout for a 3 finger tap had
elapsed. That's far from transparent. The only thing that might possibly
work is a certain area of the screen that is reserved for NVDA, but that
would probably be different for every application, so you'd need to define
the direct touch zone in an app module.

Regardless, something like this is definitely desirable. Please post your
thoughts on the ticket.


IP
Point taken, what about doing the following:
When a touch events arrives you take a copy of it and then immediately
forward it to the application.  the copy obtained is forward in parallel to
the NVDA touch processor, which can then detect the 'special'
switching back gesture.  One might argue that in some edge cases some
rubbish touch event would have gone to the application before the detection
but I think in practice this probably work just fine.

*  To add a key emulation mode which would be able to transform simple
gestures to keys and send them  to the application in focus.
Keys that come to mind are Tab, Alt, Up, Down, Left and Right, perhaps
Escape.  This approach would allow communication with traditional
applications and thus make some these accessible with touch.

I don't think this is in scope for NVDA. You can already use NVDA commands
which facilitates access. It's true that using the keyboard can

be more efficient, but this is just as true for sighted users in some cases.

IP
 From a purist point of view one might argue that a screen reader should not
modify anything going to the application but in practice it has to do some
of this already.
If you can emulate certain keys with gestures imagine how much easier it
would be to find a button with an emulated Tab rather than trying to hunt
for it in a cluttered application with touch.
In another example, Sighted users do not need menus as much as blind users
do as lots of stuff is available in tools etc many times difficult to access
(especially with touch)  again imagine how much easier it would be to get to
the menu with an emulated Alt and then go Up and Down with these emulated.
Perhaps a third party add-on could do this.
Thanks
Isaac


----------------------------------------------------------------------------
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
12