You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of the series of issues created as a result of discussion in #12076
Is your feature request related to a problem? Please describe.
Currently NVDA does not warn when it was started with invalid command line parameters. For example if someone misspells --disable-addons and attempts to rule that the given issue is caused by add-ons or not there is no indication that testing they're doing does not prove anything.
This problem exists because all CLI arguments unknown to NVDA are placed in globalVars.appArgsExtra (the motivation for this is to allow plugins to support additional CLI arguments)
Describe the solution you'd like
NVDA should warn on startup about arguments which are unknown and which has not been used by add-ons. To do so it would be necessary to make plugins register for parameters they're interested in rather than just passively looking for them in globalVars.appArgsExtra.
To ensure that the new solution is as flexible as old globalVars.appArgsExtra were the following points need to be considered:
First plugin which is interested in the given parameter does not remove it from the list of unknown params - the old system allowed two plugins to share parameter with the same name
The design which I have in mint is as follows:
-In addonHandler there is new extensionPoint CLIParamIsKnown to which all globalPlugins interested in processing command line parameters should register.
Unfortunately none of the extensionsPoints we have currently would work for this. Filter modifies data thereby removing a CLI param making it impossible for later plugin to process the same parameter) and Decider returns as soon as first interested plugin would be interested in the given parameter. The ideal option would be to create a Decider which accumulates results and returns True if at least one handler returns True, False otherwise.
After NVDA starts each argument placed in globalVars.appArgsExtra is provided to all handlers registered to the extension point - if at least one parameter is not known to add-ons core.doStartupDialogs should show a dialog informing about what unknown parameters were provided. The disadvantage of this approach is that all add-ons which want to parse extra command line parameters have to ship a global plugin (there is no guarantee that app module or other type of plugin would be loaded on startup).
Describe alternatives you've considered
Leave code as is
Do not allow plugins to support command line parameters (I'm not aware about any which needs this functionality). @LeonarddeR Since globalVars.appArgsExtra were introduced by you in Switch from optparser to argparser for parsing command line arguments #6865 would you be able to tell if you know about any use cases or has this been implemented just in case some plugin may need this? I'll also ask about possible usages on add-ons list.
First of the series of issues created as a result of discussion in #12076
Is your feature request related to a problem? Please describe.
Currently NVDA does not warn when it was started with invalid command line parameters. For example if someone misspells
--disable-addonsand attempts to rule that the given issue is caused by add-ons or not there is no indication that testing they're doing does not prove anything.This problem exists because all CLI arguments unknown to NVDA are placed in
globalVars.appArgsExtra(the motivation for this is to allow plugins to support additional CLI arguments)Describe the solution you'd like
NVDA should warn on startup about arguments which are unknown and which has not been used by add-ons. To do so it would be necessary to make plugins register for parameters they're interested in rather than just passively looking for them in
globalVars.appArgsExtra.To ensure that the new solution is as flexible as old
globalVars.appArgsExtrawere the following points need to be considered:The design which I have in mint is as follows:
-In addonHandler there is new extensionPoint
CLIParamIsKnownto which all globalPlugins interested in processing command line parameters should register.Filtermodifies data thereby removing a CLI param making it impossible for later plugin to process the same parameter) andDeciderreturns as soon as first interested plugin would be interested in the given parameter. The ideal option would be to create aDeciderwhich accumulates results and returnsTrueif at least one handler returnsTrue,Falseotherwise.After NVDA starts each argument placed in
globalVars.appArgsExtrais provided to all handlers registered to the extension point - if at least one parameter is not known to add-onscore.doStartupDialogsshould show a dialog informing about what unknown parameters were provided. The disadvantage of this approach is that all add-ons which want to parse extra command line parameters have to ship a global plugin (there is no guarantee that app module or other type of plugin would be loaded on startup).Describe alternatives you've considered
globalVars.appArgsExtrawere introduced by you in Switch from optparser to argparser for parsing command line arguments #6865 would you be able to tell if you know about any use cases or has this been implemented just in case some plugin may need this? I'll also ask about possible usages on add-ons list.Additional context