Skip to content
This repository has been archived by the owner on May 26, 2022. It is now read-only.

Settings system refactor #16

Closed
8 tasks done
raiguard opened this issue Dec 5, 2016 · 2 comments
Closed
8 tasks done

Settings system refactor #16

raiguard opened this issue Dec 5, 2016 · 2 comments
Assignees
Milestone

Comments

@raiguard
Copy link
Owner

raiguard commented Dec 5, 2016

Multiple issues have popped up with the settings system, such that it needs to be fully redesigned. The settings will move back to being local, with changes being automatically copied to the external location as a backup. After updating, the values in the external files will be copied back in so settings will still be preserved.

The ReadINI and WriteINI functions will no longer be directly used to edit the files. They will only be used to compare values.

Also, functionality must be added to make the imported backup affect the skin INI's as well as the variables. This was an oversight in v1.0.0 that must be corrected.

It should also be noted that settings backups can be turned off through the global settings skin.

To-do

  • Move settings management and update checking functionalities out of gadget manager and into a dedicated (invisible) skin
  • Rename 'ReferenceFiles' subfolder to 'Settings'
  • Create 'Defaults' subfolder to contain default settings (will remain unchanged)
  • Implement 'invokeAllSettings()' function into all gadget settings scripts, which will invoke all the settings changes for each script with the current variable values
  • Implement 'setDefaults()' function into all gadget settings scripts, similar to invokeAllSettings(), but with the default values
  • Completely scrap SettingsManagement.lua
  • Write new 'SettingsBackup.lua' script with the backup functionality described above
  • Implement backups toggle in global settings skin

Notes

  • This will fix all problems relating to nonexistent settings files, since they will now always exist
  • Upon updating, the settings will all have reset. The invisible config skin will check for the existence of a backup. If the backup exists, it will automatically transfer the values to the local settings files, then it will invoke all the config scripts for each gadget, changing each gadget's configuration to match those settings before refreshing them
  • If no backup exists, it will be assumed that it is a new installation
  • Currently debating whether or not it should be an option to have backups
@raiguard
Copy link
Owner Author

raiguard commented Jan 4, 2017

Just had a brain wave. Need to write this down before I forget it!

  • The parts of the scripts that change the gadgets' INIs directly need to be separated out and all shoved into the setup skin
  • The gadget settings skins will only change their toggle buttons, and invoke the corresponding function through the setup skin
  • This will allow the setup skin to update the gadgets after importing a backup, as well as reset them to defaults
  • Will likely entail going back to the "old" method of having two toggle button meters per button, one off and one on, so it doesn't need to be changed using LUA anymore

EDIT: Some progress has been made. Here's the current setup:

  • The scripts are still interacted with by the config skins themselves, but the functionality to update the toggle buttons has moved to measures with IfConditions
  • Each gadget loads its own settings skin and, when given a command, will update itself based on the current states of the variables
  • After importing a backup, all gadgets are refreshed, then updated using their own settings scripts
  • Also made it way easier to implement the "lock" symbol on unavailable items, e.g. HWiNFO-bound settings in CPU Meter

@raiguard
Copy link
Owner Author

raiguard commented Jan 6, 2017

DOOOONE!

@raiguard raiguard closed this as completed Jan 6, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant