Add support for special config-provider plugins

[ammen99]

@myfreeweb has his gsettings plugin which has some limitations, which arise from the fact that core has hardcoded support for dynamic (re)loading of the config file. We have discussed various approaches before, but now I have yet another way to do that.
What if we have a new kind of special plugins which are loaded once, at startup, before everything else is initialized. They would be responsible for populating and updating the global config struct.

To set the config backend plugin, we'd need a command line flag (with a build-time-configurable default value).
This would also make it even easier for other config backends if people are interested (for example, having a more sway-like config file, etc.)

Also, I'd give this plugin control over which plugins are loaded, in which order, etc.

What do you think @myfreeweb? Is this an overkill from design perspective? Any potential issues?

[damianatorrpm]

I patched output-layout to use gsettings directly btw, apart from that wouldn't it be easier to support option_wrapper
to use gsettings instead of wf-config as some ifdef, config backend (it is something I'm working on.)?
For example gsettings plugin can't do output configuration.
I doubt it will be less work to support plugins that may act as config (replacement?/addon)
or just have another backend...

I'm sure @AdrianVovk and @myfreeweb would be happy to see that as well...
The gsettings plugin build .gschema files from the config.xml files.
option_wrapper{"plugin_name/option"} backend could just use the schema org.wayfire.(plugin_name)

[ammen99]

I know your dream is having gsettings support in wayfire core, but no way :D

Anyway, you bring up a good point. A custom configuration plugin can be made to also provide output and input device configuration.

[valpackett]

I was only hoping for a way to disable the auto-reload and then I'd have a pre-packaged config file that would just load gsettings.
Loading a plugin directly as a flag instead of the config file path flag is a nice simplification I guess! :)

I'd give this plugin control over which plugins are loaded, in which order, etc.

Well, that's kinda already the case, gsettings already does set the plugins option just like any other option, and without file auto-reload disrupting it, there would be no problems left with that.

output and input device configuration

Yeeeeeah......

Maybe these things just shouldn't be top-level sections and should be somehow specified in the schema.

[ammen99]

Yeeeeeah......

Maybe these things just shouldn't be top-level sections and should be somehow specified in the schema.

How do you configure your outputs and input devices now? Via wf-gsettings somehow, or with the config file?

What I have in mind is pretty straightforward (I hope):

class config_backend_t
{
public:
void load_configuration(wl_display *display, config_manager_t& config);
config_section_t get_output_configuration(wlr_output *output);
config_section_t get_input_device_configuration(wlr_input_device *device);
};

[valpackett]

With the config file.

Actually, setting input/output configuration wouldn't be hard now, just get_section("device-name") and set stuff there, right? The reason wf-gsettings doesn't do that (yet) is not because it's impossible, but just because so far wf-gsettings is a pure 1-to-1 mapping, with no smart logic to handle corner cases like these top-level unspecified sections.

Replacing the (IMO janky; but not that problematic in practice so far) "device-name section" mechanism via this API is okay, maybe even the optimal solution.

Of course my dream solution would be a richer type system that would allow things like

[displays]
DP-1 = { scale = 2.0 }

and all of that would be specified in schemas so that any config plugin could handle that automatically like everything in the existing schemas :)

but again, maybe that's too much considering that most options are not like that and these device things are the only case so far.