[compiz] Flat file backend (ini)

[David Reveman]

On Tue, 2007-02-27 at 19:24 +0000, Mike Dransfield wrote:
> David Reveman wrote:
> > Yep, you should use the file watch interface instead of FAM. You should
> > call addFileWatch to add a watch for a specific file or directory.
> > addFileWatch will then call display->fileWatchAdded which is a wrapped
> > function that plugins that provide file watch functionality like the
> > inotify function will hook into. If you have any problems with using the
> > file watch interface please let me know.
> >   
> 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.

> 
> >
> > I'm not sure. I'd like to make it easy to adjust the defaults while
> > packaging and do so differently for different configuration systems. It
> > makes a lot of sense to have different default settings for e.g. gnome
> > and kde. This is possible right now by patching the gconf schema file
> > during packaging.
> >
> > Why do you think a system wide file would cause problems? It would allow
> > the same kind of adjustments to the defaults during packaging as the
> > schema file is currently doing, which is nice.
> >   
> 
> 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.

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

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

> 
> >> http://www.anykeysoftware.co.uk/compiz/plugins/ini.c
> >> http://www.anykeysoftware.co.uk/compiz/plugins/Makefile.ini
> >>
> >> Any other comments or suggestions are welcome
> >>     
> >
> > How about getting this into the git.compiz.org or the freedesktop.org
> > repo?
> >   
> 
> I think it would be nice to include this one in the freedesktop.org
> repo because its more of a core plumbing plugin than an extra.
> I'd like to work out all the bugs first though, I am having a problem
> with edges and the wall plugin.  It is working when I use gconf, so it
> must be my problem.

Sure, you can do that first if you want. I don't mind putting it in
right now, though.

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

- David