PowerToys/doc/devdocs/settingsv2/settings-utilities.md
Stefan Markovic 073caffef4
[Settings, Common.UI, runner exe] Unify exe/dll naming (#15005)
* Unify exe/dll naming - PowerToys.Runner

Align naming with other exes - PowerToys Runner -> PowerToys.Runner

* Unify exe/dll naming - Microsoft.PowerToys.Common.UI

Project name - Microsoft.PowerToys.Common.UI -> Common.UI
dll name - Microsoft.PowerToys.Common.UI.dll -> PowerToys.Common.UI.dll

* Unify exe/dll naming - Settings

Project names - Microsoft.PowerToys.Settings* -> Settings*
Dll names - Microsoft.PowerToys.Settings*.dll -> PowerToys.Settings*.dll

* Revert file autoformat

* [Docs] Update paths to settings projects/files

* Fix tests - Update path
2021-12-15 12:56:52 +01:00

14 lines
1.2 KiB
Markdown

# Settings Utilities
- Abstractions for each of the file/folder related operations are present in [`SettingsUtils.cs`](src/settings-ui/Settings.UI.Library/SettingsUtils.cs).
- To reduce contention between the settings process and runner while trying to access the `settings.json` file of any powertoy, the settings process tries to access the file only when it needs to load the information for the first time. However, there is still no mechanism in place which ensures that both the settings and runner processes do not access the information simultaneously leading to `IOExceptions`.
## Utilities
### `GetSettings<T>(powertoy, filename)`
- The GetSettings function tries to read the file in the powertoy settings folder and creates a new file with default configurations if it does not exist.
- Ideally this function should only be called by the [`SettingsRepository`](src/settings-ui/Settings.UI.Library/SettingsRepository`1.cs) which would be accessed only when a powertoy settings object is being loaded for the first time.
- The reason behind ensuring that it is not accessed elsewhere is to avoid contention with the runner during file access.
- Each of the objects which are deserialized using this function must implement the `ISettingsConfig` interface.