libobs: Add sub property group

[exeldro]

Description

Add sub property group, this will make the properties in the group be in a setting object with the name of the group instead of all properties in the root settings object.

Motivation and Context

I want to have multiple groups with settings that do not have unique setting names, only unique per group.
Previous version #7612 was closed without warning

How Has This Been Tested?

On windows 64 bit with a lua script

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

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

[Warchamp7]

My immediate question here is why don't properties inside of a group already behave this way? That feels like an error in the original implementation of OBS_PROPERTY_GROUP that we should be fixing instead.

[exeldro]

@Warchamp7 That would not be possible for checkable groups as you would need to save a boolean and an object with the same name. Also changing the behavior of existing groups now would break lots of plugins (in my current setup it would break 17 plugins).

[Warchamp7]

@Warchamp7 That would not be possible for checkable groups as you would need to save a boolean and an object with the same name. Also changing the behavior of existing groups now would break lots of plugins (in my current setup it would break 17 plugins).

What I'm suggesting is we fix the API itself instead of hacking onto it.

Ex.

EXPORT obs_property_t *obs_properties_add_group2(obs_properties_t *props, const char *name, const char *desc, enum obs_group_type type, bool nested_settings);

obs_properties_add_group is marked deprecated and forwards to this with nested_setting as false, new code uses obs_properties_add_group2.

Then exported data for groups is changed to be something like

"myGroup": {
    "enabled": true,
    "children": {
        "x": 0
        "y": 10
    }
}

with a obs_property_group_children() getter or such.

This wouldn't break existing plugins unless they naively update their code to call add_group2 with the same existing key name they used for add_group, which would be a mistake on their part for any data format change. Plugins should use new key names when updating to nested group properties so that they can migrate existing data safely and maintain backwards compatibility.

Given the fact you'd be updating the sub property names anyway to take advantage of the non unique restriction being lifted, that shouldn't be too much additional work.

This also gives us checkable groups with nested values for "free" without needing another enum value and more special handling.

Does that make sense?

[Warchamp7]

The more I dwell on this and having spoken with @PatTheMav the more it feels like this is trying to "fix" what is ultimately a design choice of the properties API.

It is not structured or designed to support namespaces in this way.

I will think on this more.