Rework & restructure setting UI and settings subsystem

[Frooxius]

Is your feature request related to a problem? Please describe.

There are two current major problems:

1) The current UI for settings is very cluttered, overwhelming and hard to use, due to having grown organically, with more and more settings being added over time. This has incurred significant technical debt, resulting in adding new settings being more difficult

2) The system for actually storing, syncing and managing the values is very primitive. This makes it difficult to do any complex interactions with the settings or upgrade the settings in case of necessary changes. There are number of bugs with the system as well

Overall both parts of the system have incurred significant technical debt and need to be scrapped and written from scratch.

Describe the solution you'd like

The solution for these problem is two-fold:

1) Introduce a new internal setting subsystem, built on top of the component system. This allows each group of settings to introduce its own component, holding the current state of the settings. Thanks to this, settings are not just simply stored values, but can use structured data and more complex behaviors - e.g. complex setting values that are computed from multiple values and other parameters, which are computed directly on the component, instead of computed in each site which needs to use that setting.

They also naturally utilize the upgrade system for components and the data model - if we change how certain settings are modeled, we can use the same system for upgrading components to upgrade old settings over time.

On top of these components will be a "routing" system, which routes the appropriate components holding the actual settings to the systems that need them. For each setting group, there might be multiple actual components holding the setting - e.g. some settings can be overridden depending whether the user is in VR or screen.

The routing system can be more advanced too, adding support for user profiles (e.g. user can switch their settings depending on whether they're socializing, building, streaming or doing anything else) and any other rules.

One additional benefit is that the actual settings have a clear definition in one place, rather than this definition being scattered and implicit, making it easier to figure out what settings are available, what datatypes they use and how they're structured.

2) Introduce a new UI system for settings, which automatically scans all available setting components and generates appropriate UI for them. With components being appropriately tagged, the UI will organize settings into categories and allow searching & filtering.

This will make adding new settings significantly easier. Instead of modifying convoluted UI code and hardcoding new settings in, we simply add a new setting component and tag settings/categories appropriately.

In a similar vein, this will make it easy for mods, plugins, device drivers and other things to add additional settings as well by simply introducing setting components and have them be dynamically picked up by the setting subsystem and having UI generated.

Individual settings will also be generated as facets, copies of which can be easily picked up by the user and placed on their dash and other places (e.g. avatar, once facet containers are added there), allowing for quick access to favorite settings.

Describe alternatives you've considered

N/A

Additional Context

This will also make it significantly easier to serve a number of requests we are getting, which require adding settings. From stuff like quality and postprocessing settings, to lots of features that we have been holding off until we have better system for settings.

[TisFoolish]

@xdelta has written a mod that completely rewrites the settings field into something much more user friendly. It might be worth looking at it

[Frooxius]

@TisFoolish I'm aware of that, but we plan to completely build a new setting subsystem and UI from the scratch as detailed in my initial post and this is not compatible.

We do not plan to make any incremental changes to the system like that anymore.

[TisFoolish]

I meant more of the UX than the codebase. The presentation of information and options is well done.

[Frooxius]

I don't think I'll be going with that particular UX either, it will be new from ground up.

My general plan has to do more style of modern settings you can find on tablet devices (like iPad for example) or Windows 11, with categories on left and setting sections on the right, grouped by things, but things aren't set in stone yet either.

[Frooxius]

I've created a Discussion for this topic here! Please direct your feedback, thoughts and wishlist for this here: https://github.com/Yellow-Dog-Man/Resonite-Issues/discussions/614

[Banane9]

Since there doesn't seem to be a separate issue for the Data Feeds in particular, I'm going to put it here: It would be very nice if it would be possible to create arbitrary data feeds as well, by defining their structure using some components. This would be amazingly useful for any setting systems on worlds or item creations, by streamlining the creation of UI to change those settings.

Some existing components would also be prime candidates for offering a data feed of their own. For example Dynamic Variable Spaces could offer their linked dynamic variables and where the components linking to them are (as mentioned in #1351).

[Frooxius]

@Banane9 You'll eventually be able to create your own data feeds, but that's out of scope for this rework.

[Banane9]

You'll eventually be able to create your own data feeds, but that's out of scope for this rework.

Yea, I don't expect it to be available immediately - though that would be very sweet for the aforementioned reasons.

[Frooxius]

With release of 2024.4.15.1407 this is now finally done! :D This unblocks a good chunk of new features that will come soon!