obsproject
libobs: Write default values to config
Description
Changes the config file implementation to save default values in case no user-provided value has been set.
Motivation and Context
Migrations make life diffcult when we change defaults. So just save values even if the users never changes them from default.
How Has This Been Tested?
Locally in portable mode, checked that generated config had all keys with default values written.
Types of changes
- Tweak (non-breaking change to improve existing functionality)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
If a plugin does not have confit_set_default..., 0 is assumed as the default. However this PR only changes config_set_default... APIs so that the assumed 0 won't be written.
If a plugin does not have confit_set_default..., 0 is assumed as the default. However this PR only changes config_set_default... APIs so that the assumed 0 won't be written.
Correct, although I'm not sure how many plugins use the config API. None of the ones included with OBS really do (win-capture uses it for writing an INI file with the offsets helper, but not for actually saving settings), they all use obs_data_* APIs.
As somebody else has pointed out off-chain, we probably should go through all of our first-party plugins and UI code and explicitly set defaults rather than relying on the implicit behvaiour.
I would also say that once we decide to write defaults we probably want to have 1 or 2 further minor/major releases where we keep doing migrations to avoid breakage until the vast majority of users is on a recent enough version for the defaults to be written.
~~Added a commit to save most settings even when the widget didn't change. This just makes the code a little nicer and together with #8229 the impact should be negligible, but I can remove it if people would rather keep it the current way.~~
Removed for now to make it easier to review.
As somebody else has pointed out off-chain, we probably should go through all of our first-party plugins and UI code and explicitly set defaults rather than relying on the implicit behvaiour.
Is this something to be done in this PR, or is this something you're looking to do in a follow-up PR?
Is this something to be done in this PR, or is this something you're looking to do in a follow-up PR?
No, that would be a separate undertaking that modifies primarily the UI rather than just the config parser in libobs. I'd do that as a separate PR if this gets merged.
Bug Reports Downloaded Nightly Build. There is a bug in the language setting on first launch. Tried in portable mode.
75693a6 (this PR) = language is forced to "English".
https://user-images.githubusercontent.com/1337354/223735090-eeb67b6b-e0a0-4115-b0bb-4b0e1471bf7b.mp4
. 2789735 (one before this PR) = language is set to "Windows display language". (Japanese in the case of this video)
https://user-images.githubusercontent.com/1337354/223735164-8ddc3387-a0b6-4e92-8867-eee256cb5bf3.mp4
There is a bug in the language setting on first launch. Tried in portable mode.
The commit c99256cf2 should fix the issue.