-
-
Notifications
You must be signed in to change notification settings - Fork 626
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
Add-on config: allow add-ons to respond to config save/reload/reset actions via a new extension points action #7598
Comments
… and perform appropriate actions when saving or reverting settings, respectivley. re nvaccess#7598. Some add-ons do not participate in ConfigManager/profiles at the moment. For these, there's no easy way to revert settings or Control+NVDA+C cannot be used to let add-ons save settings. To accomodate this, two new actions (extensionPoints.Action) are introduced: * config.saveConfig: a new extension point that allows add-ons to save settings to custom location(s). * config.resetConfig: allows add-ons to reload settings from anywhere and/or reset configuration to defaults (controlled by a boolean). This requires NVDA 2017.4/extensionPoints support.
@josephsl I am aware that this issue has progressed into implementation, and has active discussion on the PR. However, I don't think the original use case is very clear. Could you please expand on the problem that is being solved here? A concrete example would probably help. |
Hi, a concrete example is an add-on that uses a separate file for storing its config and saves its settings when Control+NVDA+C is pressed with help from the new action. As @ctoth pointed out, I plan to separate the action into at least two phases: save (action) and postSave (perhaps other modules such as a potential cloud storage module might want to perform an action once all settings were saved). Thanks.
From: Reef Turner [mailto:notifications@github.com]
Sent: Tuesday, September 19, 2017 10:28 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Add-on config: allow add-ons to respond to config save/reload/reset actions via a new extension points action (#7598)
@josephsl <https://github.com/josephsl> I am aware that this issue has progressed into implementation, and has active discussion on the PR. However, I don't think the original use case is very clear. Could you please expand on the problem that is being solved here? A concrete example would probably help.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#7598 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkK3rizLihrt0NATT_xQaygcCA4N1ks5skKJDgaJpZM4PVkNN> .
|
Could you take this further, why would an add-on store its config in a separate file? Can you name one that suffers from this problem? The suggestion of a cloud storage addon is a good one. However, I would be cautious of extending a new area of code in order to provide support for an add on that does not exist. The extension points code is quite new, and hopefully it does become stable. Growing the available extension points quickly, at this stage, could prove to be problematic. If we ran into some problem with the core use cases, we may need to change the design. |
Hi, several, including Remote Support, SPL Studio, and to some extent, Place Markers and what not. One of the limitations of our current Config Manager (as noted above) is the fact that it does not offer an easy way to delete sections, needed by SPL and other add-ons. In case of SPL, I took config management a step further by reading config from multiple files at once. Thanks.
|
Also, tip of the day uses ini with configobj, but the data is not config based, but many of the things I store are specifically state. I do that in a separate file. |
So the other question is why do these add-ons (perhaps just explain one) store config in a separate file? |
The reason I'm doing it, is because the config system was not mature enough in the old days to do this, and I also don't want things like the current tip value being stored in other than base config. See my issue #7467 |
Hi, not that I know of at the moment, as there is really no __delitem__ method defined. Thanks.
From: Reef Turner [mailto:notifications@github.com]
Sent: Monday, October 2, 2017 6:49 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Add-on config: allow add-ons to respond to config save/reload/reset actions via a new extension points action (#7598)
So the other question is why do these add-ons (perhaps just explain one) store config in a separate file?
What is the current work around for deleting sections?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#7598 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkChynYEXOSFb-Zoc3Qs8vzuSn_gjks5soZKkgaJpZM4PVkNN> .
|
@josephsl commented on Oct 2, 2017, 7:57 PM MDT:
Know of what? |
Hi, know of safely deleting sections (keys) instead of fiddling around with files and introducing monkey patches and subclassing. Thanks.
From: Derek Riemer [mailto:notifications@github.com]
Sent: Monday, October 2, 2017 9:08 PM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Joseph Lee <joseph.lee22590@gmail.com>; Mention <mention@noreply.github.com>
Subject: Re: [nvaccess/nvda] Add-on config: allow add-ons to respond to config save/reload/reset actions via a new extension points action (#7598)
<https://github.com/josephsl> @josephsl commented on Oct 2, 2017, 7:57 PM MDT <#7598 (comment)> :
Hi, not that I know of at the moment,
Know of what?
Cheers
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#7598 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkExQ9CvKDhs_uEM7ZmM1-kxgp1-Yks5sobMKgaJpZM4PVkNN> .
|
…ess#7598. Requested by many reviewers: there are times it is helpful to let modules perform actions prior to and/or after NVDA settings are saved, most likely when add-ons need to save settings and/or a module will transport settings to a cloud location for safekeeping or cynchronization purposes. Thus split configSaved action into configPreSave (prior to) and configPostSave (after) actions. Not all modules should listen to both events at once - for add-ons, configPreSave action is enough.
Renamed the following actions: * configProfileSwitched -> postConfigProfileSwitch * configPreSave -> preConfigSave * configPostSave -> postConfigSave * configPostReset -> postConfigReset Modules that uses config switch action will be modified next.
…vaccess#7598. To keep in sync with renamed actions, various modules with handleConfigProfileSwitch has been renamed to handlePostConfigProfileSwitch.
…s. Re nvaccess#7598. During the pull request discussion, @ctoth advised splitting save/reset actions into three parts: pre, on, and post. With a possible case of these actions being cloud settings backup/restore, it would be best to divide it like this: * preConfigSave/preConfigReset: for validation checks, preparing settings files for reset. * onConfigSave/onConfigreset: called right after NvDA own settings are saved and reset, useful as the main action by add-ons and other modules to save and/or reload settings. * postConfigSave/postConfigReset: the best use case is transporting settings to somewhere, especially to the cloud.
Reviewed by Reef Turner (NV Access): just because settings dialogs have pre/on/post save handlers does not mean config should be made consistent with it. Thus remove onConfig* actions for now until future work justifies this.
…). Re nvaccess#7598. Advised by Reef Turner (NV Access) and @LeonarddeR (Babbage): use the following variable identifier format: 'pre_/post_actionname'. This means: * config.postConfigSave -> config.post_configSave. * config.preConfigSave -> config.pre_configSave. * config.postConfigReset -> config.post_configReset. * config.preConfigReset -> config.pre_configReset. * config.postConfigProfileSwitch -> config.post_configProfileSwitch.
…ons and renamed profile switch action. Re nvaccess#7598.
Closes #7598 Config: add the following actions so add-ons can respond and perform appropriate actions when saving or reverting settings, respectively: * `config.post_configSave` * `config.pre_configSave` * `config.post_configReset` * `config.pre_configReset` * `config.post_configProfileSwitch` Some add-ons do not participate in ConfigManager/profiles at the moment. For these, there's no easy way to revert settings or Control+NVDA+C cannot be used to let add-ons save settings. These new actions now alleviate this. Example use cases: * pre/post config save: allows add-ons to save settings to custom location(s). * pre/post config reset: allows add-ons to reload settings from anywhere and/or reset configuration to defaults (controlled by a boolean). Pre / post: there are times it is helpful to let modules perform actions prior to and/or after NVDA settings are saved, most likely when add-ons need to save settings and/or a module will transport settings to a cloud location for safekeeping or synchronization purposes. Not all modules should listen to both events at once - mostly, `pre_configSave` action is enough.
Hi,
For various reasons, some add-ons do not participate in Config Manager/Profiles scheme. In case of one of my add-ons, the ability to delete sections from aggregated sections is needed, while @tspivey has expressed some reservations about current approach to config profile handling.
To cater to these scenarios - especially if add-on settings are stored elsewhere, and in order to provide a possible justification for cloud-based settings, I'd like to propose adding two or three extension point actions:
Use cases:
Algorithm:
Impact and requirements: this proposal requires NVDA 2017.4. The impact would be greatest for add-ons that takes advantage of this.
Mitigation strategies for add-ons:
Thanks.
The text was updated successfully, but these errors were encountered: