obsproject
UI: Log sceneitem and filter enabled
Description
This logs whether sceneitems and filters are enabled on scene collection load.
Inactive ones are prefaced with a o and active ones by a *.
An example log can be found here
Motivation and Context
Whether or not sceneitems/filters are enabled is often an important matter in support, having it logged would greatly simplify some support workflows.
How Has This Been Tested?
Running obs, checking it logs correctly.
Types of changes
- New feature (non-breaking change which adds 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.
This is just my opinion of course but I think if this PR is introducing state logging on load it should also include logging of state changes.
Would it perhaps be better to identify enabled or disabled filters just by adding (disabled) or (enabled) somewhere on the line? Or even just (disabled) for the disabled ones, with lack of it implying not-disabled?
That way no special knowledge is needed to read that information in the log, the filter lines are just self-explanatory.
This is just my opinion of course but I think if this PR is introducing state logging on load it should also include logging of state changes.
I considered it but it is IMO, too verbose, and not that useful, in the same vein that, for example sceneitem order changes aren't logged, only sceneitem order on load.
Would it perhaps be better to identify enabled or disabled filters just by adding
(disabled)or(enabled)somewhere on the line? Or even just(disabled)for the disabled ones, with lack of it implying not-disabled?That way no special knowledge is needed to read that information in the log, the filter lines are just self-explanatory.
Quite in the same vein, my goal was to preserve simplicity and keep verbosity at a minimum. I feel that the way it is is decently self explanatory, but am deffo open to other alternatives.
This is just my opinion of course but I think if this PR is introducing state logging on load it should also include logging of state changes.
I considered it but it is IMO, too verbose, and not that useful, in the same vein that, for example sceneitem order changes aren't logged, only sceneitem order on load.
I disagree with the comparison and don't think it would be very verbose unless someone is constantly enabling/disabling sources and filters. If the motivation for this change is to assist with support then having a way to determine the current state is more valuable then just knowing the initial state at load.
This is just my opinion of course but I think if this PR is introducing state logging on load it should also include logging of state changes.
I considered it but it is IMO, too verbose, and not that useful, in the same vein that, for example sceneitem order changes aren't logged, only sceneitem order on load.
I disagree with the comparison and don't think it would be very verbose unless someone is constantly enabling/disabling sources and filters. If the motivation for this change is to assist with support then having a way to determine the current state is more valuable then just knowing the initial state at load.
After sleep and reconsideration, yeah, fair. Added.
I will also add that I agree with @alinsavix on using (disabled) for the disabled items only and logging nothing for something that is enabled.