n what way did this change and improve when it was moved into the core?

>
> 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.

This seem to just be about sharing code. Whatever we agree is the best
way solution, I'm sure the code you've written for the beryl settings
system wont go wasted.

>
> > > 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.

I'm just wondering if your settings plugin knows more about plugins than
what can be retrieved by other plugins through the core?

Anyhow, it just seems like different ways of exposing information,
difference in what information that should be exposed and ways of
sharing code.

- David