frontend: Log sceneitem and filter enabled

[Penwy]

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:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[prgmitchell]

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.

[alinsavix]

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.

[Penwy]

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.

[prgmitchell]

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.

[Penwy]

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.

[prgmitchell]

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.

[Penwy]

Done.
I still personally dislike the way it prints, but if you two agree on this, I'll bow to the majority.
example log here

[Warchamp7]

@Penwy Can you fix up the conflict on this?

[RytoEX]

Commit prefixes and PR prefix will need to be updated to "frontend: ".

Requested relevant reviews.

[Penwy]

Upon revisiting it I realised this leaves one logging without that info :
When creating a new source or a sceneitem of an existing source through the "add source" dialog, the created sceneitem can be created disabled.
It is however impossible to log this in one line as the visibility is set after the creation of the sceneitem, and hence the logging of its creation.
Rather than add a second line of log for this, I think it is preferrable to not log the visibility status in that instance.