On 2/21/07, David Reveman <davidr@novell.com> wrote:
> On Wed, 2007-02-21 at 13:44 -0500, Robert Carr wrote:
> > On 2/21/07, David Reveman <davidr@novell.com> wrote:
> > > On Wed, 2007-02-21 at 12:35 -0500, Robert Carr wrote:
> > > > On 2/21/07, David Reveman <davidr@novell.com> wrote:
> > > > > On Tue, 2007-02-20 at 17:37 -0500, Robert Carr wrote:
> > > > > > At the risk of breaking out of the flow of the conversation we were having.
> > > > > >
> > > > > > I've talked to Jason (DBO), Dennis (Onestone), Guillaume (iXce), and
> > > > > > Thomas (lupine) about this. We obviously doesn't represent all of
> > > > > > Beryl, but the opinion is relatively significant.
> > > > > >
> > > > > > Everyone was quite excited about the ideas, and the consensus was
> > > > > > mostly the following:
> > > > > > New name, with the project including both core and a non trivial
> > > > > > set of plugins.
> > > > >
> > > > > I'm probably willing to agree to this but I'll have to see what the
> > > > > other people involved with compiz thinks about it.
> > > > >
> > > > > > Commits to core would be made to a branch, and 1 of 2-3 people
> > > > > > (including you) will merge it in to the actual core if deemed
> > > > > > appropriate. This is a balance between the obviously different
> > > > > > development models of Compiz.
> > > > >
> > > > > Any number of people can keep personal branches around. Where they're
> > > > > hosted doesn't even matter as long as we use a distributed version
> > > > > system.
> > > > >
> > > > > Whoever wrote some piece of code should have the final say in what
> > > > > changes that will go in. E.g. I'm not going to allow anyone to apply
> > > > > changes to code I've written without them first knowing that I'm OK with
> > > > > it.
> > > > >
> > > > > I don't mind at all that a large amount of people have commit access to
> > > > > my code. Obvious bug fixes can of course be applied by people when they
> > > > > are sure about them but other changes should always be discussed first.
> > > > > I'll of course make any significant changes I plan to make to code I've
> > > > > written available for discussion before anything is moved in to the
> > > > > core.
> > > > >
> > > > > These are general rules that are used by most open source projects out
> > > > > there. If you believe that other rules should be used I'd need a good
> > > > > motivation before I could agree to that.
> > > > >
> > > >
> > > > This seems fair enough, and was more or less what I meant.
> > >
> > > Good.
> > >
> > > >
> > > > > > License, MIT might be ok, but would have to be discussed more.
> > > > > > LGPL was brought up, this would still allow linking to by non GPL
> > > > > > compatible plugins but be less liberal in it's terms than MIT.
> > > > >
> > > > > I'm interested in reasons people have to why MIT shouldn't be used that
> > > > > are so important that the reasons for using MIT that I've pointed out
> > > > > would have to be sacrificed.
> > > > >
> > > >
> > > > Again, I'm not really concerned about MIT so I can't argue this point
> > > > for other people, I will try and get some more specific information
> > > > though. After taking to people though there seems to be very little
> > > > resistance.
> > >
> > > Good.
> > >
> > > >
> > > > > > Core of the new project would have to have settings all in core
> > > > > > (no settings plugin like Compiz has...), something like
> > > > > > libberylsettings would be preferred, though this is definitely
> > > > > > something that can be discussed.
> > > > >
> > > > > I'm very skeptical to this. I'd need a very good motivation for why we
> > > > > would want to have a specific configuration backend part of the core.
> > > > >
> > > >
> > > > I think we could probably work something out here, will have to talk
> > > > to others about this though. One thing that I think does make a lot of
> > > > sense is the settings plugin being in core (individual backends can
> > > > still be plugins).
> > >
> > > What is the settings plugin? Is it not that you just want to share some
> > > code between different configuration backends? That's a different thing
> > > and it could be OK to include such code in the core or if it's likely
> > > that some want compiz running without plugins that use that
> > > functionality loaded it might make more sense to keep it in a library
> > > instead.
> > >
> >
> > 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.
>
> In 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.
>
Good to hear
> >
> > > > 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?
>
We don't have a settings plugin at all.
And no the a_plugin_active setting is accessible as a setting of a
plugin like any other setting.
> Anyhow, it just seems like different ways of exposing information,
> difference in what information that should be exposed and ways of
> sharing code.
>
> - David
>
Yes, it's largely just a different design functionally it works in
very similar ways.
For example in setDisplayOptionForPlugin after calling
p->vTable->setDisplayOption it calls
beryl_settings_context_comp_set_option_value and the
beryl_settings_context_write(display->context) (Type
BerylSettingsContext *) which calls the current backends write_setting
function on the changed settings.