[Feature Request] Make it easier to manage config via a dotfile system

[ToasterUwU]

I manage my dotfiles in a way where they end up being read only. So my config.toml has all the settings i want, but the version check and window size settings which are more state data than config data, are saved in the same file.
So when an update comes out, i need to by hand update my config file to say that "Yes, i saw the changelog popup, dont show it again".
I also have to resize the window on at least one of my devices every single time because instead of respecting what the Window Manager tells the window to do, it resizes itself to what it wants. I use a Tiling Window Manager called Niri, it defaults to putting every window on the left half of the screen, filling the whole left half, or right half if the left half is already taken. Supersonic is the one window that doesnt want to be handled like that. It will make itself a tiny box on my Desktop if use the lower resolution from my laptop for the config file, or make itself too big for the screen on my laptop if i use the window size based on the resolution of my Desktop.
This gets annoying really fast, so i would like to request one of 3 possible solutions.

1. Move state data out of the config.toml, since they arent really config data in the first place. This would be update check info and window size. Under linux this would go into .local/share, aka $XDG_DATA_HOME

2. Make the config system modular. Add a config.d folder next to the config.toml file, read every toml file in it and merge them, that way people like me can choose to make a config.d/appearance.toml file and define the theme and default tab in there, but have the rest still be managed by the program in the config.toml. This would be extra nice because that way i can choose to force specific settings, but leave others up to be changed any time or be different on specific devices.

3. Add an option to not manage state data in config.toml at all. Basically disabling changelog popups and not saving the window dimensions on exit and just defaulting to whatever the Window Manager wants.

I would highly prefer option 2, if thats not an option for you, number 1 would be my second favorite, and if thats still not an option, than number 3 would be a sufficient workaround.

The cleanest and best case scenario would be both option 1 and 2 combined, since that complies with XDG standards (which supersonic doesnt really do currently because of those two settings sections), and also allow people to mix and match their config files and configure it in an automated way to their hearts content.

[dweymouth]

If I implement 1., at least to start, should the division between config and state be that anything configured in the settings dialog is config, and everything else is state? Examples of other things that would be state in this approach: whether the sidebar is visible, the relative width of the sidebar, visible tracklist columns for each page type, sorting order for artist discography, etc.

[zacaj]

An important consideration here is whether the value makes sense to be per device. To me, I'd want want to keep my visible columns synced between devices so that when I provision a new one I can move my config over and not have to set up my preferred columns again. But width of the side bar is going to be very display dependent, I probably wouldn't care to keep it in sync.

At the same time, I can picture another user who's working with one ultra wide monitor device and one with a 1024px screen and really does want different columns on each.

Or, what about stuff in the settings screen that's related to the audio system being used? That might need to be configured per device, but other settings on that same tab make sense to be global.

[ToasterUwU]

I would say yes to settings being dialog options only, if someone wants to really control the size of colums they still can manage the state-file via dotfiles as well.