New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide NVDA command line switches in an ini file #6812

Closed
leonardder opened this Issue Jan 26, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@leonardder
Collaborator

leonardder commented Jan 26, 2017

It is possible to provide command line switches to NVDA, but it would be a handy addition if we could provide them in an ini file in the root of the NVDA installation folder.

I have the following use case. In a corporate environment where I would like to implement NVDA on behalf of @BabbageCom, the roaming appdata profiles used can't exeed the size of 50mb. Thus, what I'd like to do is set the local appdata profile as the default for storing the NVDA configuration. This can be done by changing the NVDA shortcut, but that is a slightly ugly fix since people would be able to change their shortcuts, an update can break the particular shortcut, etc. Define such options in an ini file would be helpful in this case.

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Jan 26, 2017

Collaborator
Collaborator

derekriemer commented Jan 26, 2017

@feerrenrut

This comment has been minimized.

Show comment
Hide comment
@feerrenrut

feerrenrut Jan 31, 2017

Contributor

Can I ask which command line switches you are using? Rather than introduce a new ini file, we could read these particular options from the current nvda configuration.

Contributor

feerrenrut commented Jan 31, 2017

Can I ask which command line switches you are using? Rather than introduce a new ini file, we could read these particular options from the current nvda configuration.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Feb 8, 2017

Collaborator

I'm afraid it is not possible to read the current configuration, as the primary reason I want to do this, is that I'd like to change the default config path for every user on the system.

Collaborator

leonardder commented Feb 8, 2017

I'm afraid it is not possible to read the current configuration, as the primary reason I want to do this, is that I'd like to change the default config path for every user on the system.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Feb 9, 2017

Collaborator

I noticed that the optparse module is deprecated in favour of argparse. So, I thought it would be a good idea to move the argument parser to argparse in the first place, which at least has functionality on board to parse command line variables from files (one argument per line). One of the questions we need answered is, do we want a file with just a raw command line argument on every line, or do we want a nicer, ini-style kind of file?

Collaborator

leonardder commented Feb 9, 2017

I noticed that the optparse module is deprecated in favour of argparse. So, I thought it would be a good idea to move the argument parser to argparse in the first place, which at least has functionality on board to parse command line variables from files (one argument per line). One of the questions we need answered is, do we want a file with just a raw command line argument on every line, or do we want a nicer, ini-style kind of file?

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Feb 9, 2017

Contributor

In this case, I'd suggest we narrow the scope to the use case. I don't think there's much use for making most of those command line arguments ini settings, at least not the ones that already aren't. Your use change is changing the default config folder system wide. Rather than using an ini file, I'd suggest we just have a setting in the hklm registry for this.

Contributor

jcsteh commented Feb 9, 2017

In this case, I'd suggest we narrow the scope to the use case. I don't think there's much use for making most of those command line arguments ini settings, at least not the ones that already aren't. Your use change is changing the default config folder system wide. Rather than using an ini file, I'd suggest we just have a setting in the hklm registry for this.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Feb 9, 2017

Collaborator
Collaborator

leonardder commented Feb 9, 2017

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Feb 9, 2017

Contributor
Contributor

jcsteh commented Feb 9, 2017

@feerrenrut feerrenrut added the p3 label Feb 10, 2017

@nvaccessAuto nvaccessAuto added this to the 2017.3 milestone Jun 21, 2017

feerrenrut added a commit that referenced this issue Jun 21, 2017

Update changes file
For PRs:
- #6864 - NVDA user configuration files can now be stored in the user's local application data folder. This is enabled via a setting in the registry. See 'System wide parameters' in the user guide for more details. (Issue #6812)
- #7055 - In web browsers, NVDA now reports placeholder values for fields (specifically, aria-placeholder is now supported). (Issue #7004)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment