I seem to have misunderstood how Compiz settings work (That's what I
get for not looking through the tree before commenting). Let me
describe somewhat how Beryl settings work and what we like about them.

Beryl used to have a settings plugin that just called the appropriate
libberylsettings function, and we have since moved this in to core. In
my opinion it makes a lot more sense if core is calling one function,
i.e. beryl_settings_context_comp_set_option_value, and this eventually
reaches a read_setting call that is passed to the current backend
which reads the settings and calls beryl_setting_set_<TYPE>_value.

This makes backends very small, and easy to maintain and write.
Essentially the backends are just a library exposing a few functions
such as read_setting, write_setting, write_init, write_fini, etc. Many
of the common functions used between them are obviously available in
libberylsettings.

Furthermore it allows core, and external settings apps to interact
with the settings in a consistent manner and not have to reimplement
code for writing and reading specific settings. Bindings for languages
like python are also of course easy.

It seems to us like this design makes a lot of sense, and is easy to
maintain, expand, and use.

> > After we transitioned to this we also started using
> > an is_active setting on each plugin rather than a_active_plugins.
>
> hm, is your settings plugin extending the current options with more
> information?
>
I'm not sure what you mean by this.

> - David