[compiz] Flat file backend (ini)

[David Reveman]

On Wed, 2007-02-28 at 15:28 +0000, Mike Dransfield wrote:
> David Reveman wrote:
> > On Tue, 2007-02-27 at 19:24 +0000, Mike Dransfield wrote:
> >   
> >> I will write a fam plugin as well and test if that works
> >> correctly too.  I think it will  need extending a bit but I didn't
> >> look too hard.
> >>     
> >
> > Do you get any benefit out of fam except that it provides polling for
> > when inotify isn't available? If not, I might make more sense to add a
> > simple polling based file watch plugin instead of one that uses fam.
> >
> >   
> 
> The only benefit was it was the easiest thing to install and use at
> the time ;)
> 
> I think I will just install inotify and change ini to support that, then
> we can have a look at an inotify alternative.
> 
> >> My idea was that there would be a core function which could
> >> revert an individual option value to its default value, this could
> >> be copied only when it changes to save memory.
> >>
> >> This would mean that it would be easy to expose it via dbus for
> >> the different settings managers, plus it would mean that the
> >> gconf and ini (and any others in the future) would not have to
> >> know how to revert the defaults.
> >>     
> >
> > I don't know, maybe some default defaults could be good to have but I'm
> > not convinced. If you have both a gnome config utility that uses gconf
> > and some other kde utility that uses dbus running at the same time you
> > likely want different defaults for each of these utilities and the
> > default defaults wouldn't be useful to them.
> >
> > If you necessarily don't want to keep the defaults in a separate file,
> > you could keep a copy of the initial value of any option you change in
> > the ini plugin. We could provide some utility function that will make
> > that easy.
> >   
> 
> Yes, I hadn't thought of this before.  I am not bothered either way.
> The ini plugin probably does not need to have a ini-dump plugin
> because it writes out the internal values if it does not find a user
> config file.

Yes, that seems simple and good enough.

> 
> >> Maybe we could add a compiz_defaults.h and a plugin_defaults.h
> >> file which would contain all the defaults in one easy place.  Packagers
> >> would be able to patch this same file differently for each package.
> >> I know they can already do this, but moving everything to 1/2 files
> >> would encourage it.
> >>     
> >
> > I'm not sure I understand. Should these headers be included in each
> > plugin that like to know about the defaults? Seems like worse then the
> > schema file to me as now you have files that need to be patched
> > differently depending on which plugin they are included in.
> >   
> 
> My initial idea was that the packagers could modify the
> individual c files.  Most of the plugins have their defaults at
> the top in a nice easy to read format.

Problem is that you have one set of plugins and one core that is shared
between all your desktop environments but you want different defaults
depending on which desktop environment you're using. So patching the
source code files doesn't work.

> 
> I just expanded this idea to pull all these defines to one header
> file and then all the plugins can include the same file.  This might
> have been a stupid idea though.
> 
> >> This raises another question I forgot about, how are multiple screens
> >> handled?  ie. how does the schema file get modified depending on how
> >> many screens are being used?
> >>     
> >
> > That's broken. Only defaults for screen 0 is currently provided in the
> > schema file. I don't have a good solution for this. 
> >   
> 
> Now might be a good time to solve this skeleton once and
> for all.  Have you thought about making it a compile time option?
> 
> The other alternative might be to pull the plugin loading functions
> into a separate library, then we could create a small utility program
> which could load a plugin and then ask it to write its schema to a
> global location.  Users could run this utility when their xorg 
> configuration
> app changes the number of screens.
> 
> This could possibly be expanded to some sort of daemon which just
> listens for notifications from X about new screens, then adds schemas
> when needed.

Sounds complicated. I think a simple solution like having the schema
install procedure be able to install the default values for any number
of screens. The packager would select how many screens to install
schemas for. One is probably fine in most cases and I'm pretty sure
almost no one uses more than four screens so those who are concerned
about people using more than one screen could use something like that.

(this is only a problem when using multiple screens and not normal
multi-head as you then just have one X screen) 

> 
> >> The only difference is that I incrementally add to the action option
> >> whereas gconf does it in one hit.  Do you think this would cause a
> >> problem?  The edges work for other plugins (ie. scale)
> >>     
> >
> > Depends on how reading and writing of options is implemented in your ini
> > plugin. It's always preferred to do atomic changes to options so I would
> > suggest that we fix this at some point.
> >   
> 
> Yes, I will fix this and tidy it up a bit.  Hopefully that will fix the
> problem, otherwise Ill try to get to the bottom of the edge bug.

sounds good.

- David