On 2/21/07, David Reveman wrote: > On Wed, 2007-02-21 at 13:44 -0500, Robert Carr wrote: > > On 2/21/07, David Reveman wrote: > > > On Wed, 2007-02-21 at 12:35 -0500, Robert Carr wrote: > > > > On 2/21/07, David Reveman 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__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.