I have written an initial flat file configuration backend for Compiz. At the moment it is using FAM for monitoring of files (it can be compiled without monitoring support for now). It is working fine but there are a couple of problems. 1. It looks like I should use addFileWatch rather than directly accessing FAM, is this correct? I notice dbus uses addFileWatch rather than (*d->addFileWatch) is this intentional, and does it get wrapped in the same way? 2. I cannot see how to work out what the defaults are so that people can revert to default values. As far as I know Compiz does not store the original value so the only way to revert back when someone deletes a config file is to reload Compiz. I could keep the defaults in a separate system wide file, but that would probably have problems. I like having it only rely on user config files. Would adding some default storage to the core make sense?, we could then have a dbus method which would revert an individual value easily. 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
On Thu, 2007-02-22 at 16:01 +0000, Mike Dransfield wrote:> I have written an initial flat file configuration > backend for Compiz. At the moment it is using > FAM for monitoring of files (it can be compiled > without monitoring support for now).Great!> > It is working fine but there are a couple of problems. > > 1. It looks like I should use addFileWatch rather than > directly accessing FAM, is this correct? I notice dbus > uses addFileWatch rather than (*d->addFileWatch) is > this intentional, and does it get wrapped in the same > way?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.> > 2. I cannot see how to work out what the defaults are > so that people can revert to default values. As far as > I know Compiz does not store the original value so the > only way to revert back when someone deletes a config > file is to reload Compiz. I could keep the defaults in a > separate system wide file, but that would probably have > problems. I like having it only rely on user config files. > Would adding some default storage to the core make sense?, > we could then have a dbus method which would revert an > individual value easily.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.> > > http://www.anykeysoftware.co.uk/compiz/plugins/ini.c > http://www.anykeysoftware.co.uk/compiz/plugins/Makefile.ini > > Any other comments or suggestions are welcomeHow about getting this into the git.compiz.org or the freedesktop.org repo? - David
Diogo Ferreira wrote:> The current INI plugin seems to fail loading when there isn't a > ~/.compiz dir. Since most users won't have it I believe it makes sense > to mkdir it before trying to mkdir the sub-options directory. > I would have done it but since you use the get dir function a lot it > would mean changing the structure a little and since it's your plugin > I think you know best how to change it accordingly. >Ive been meaning to get some clarification on whether or not I can rely on .compiz existing. When I first wrote the ini plugin, I though I could. Its more a global directory so I do not create it, but I can if its required. Should I be creating this directory? OR should it be the responsibility of core to make sure this exists (it is defined there)
The current INI plugin seems to fail loading when there isn't a ~/.compiz dir. Since most users won't have it I believe it makes sense to mkdir it before trying to mkdir the sub-options directory. I would have done it but since you use the get dir function a lot it would mean changing the structure a little and since it's your plugin I think you know best how to change it accordingly. Regards, Diogo Ferreira On 2/22/07, Mike Dransfield <mike@blueroot.co.uk> wrote:> > I have written an initial flat file configuration > backend for Compiz. At the moment it is using > FAM for monitoring of files (it can be compiled > without monitoring support for now). > > It is working fine but there are a couple of problems. > > 1. It looks like I should use addFileWatch rather than > directly accessing FAM, is this correct? I notice dbus > uses addFileWatch rather than (*d->addFileWatch) is > this intentional, and does it get wrapped in the same > way? > > 2. I cannot see how to work out what the defaults are > so that people can revert to default values. As far as > I know Compiz does not store the original value so the > only way to revert back when someone deletes a config > file is to reload Compiz. I could keep the defaults in a > separate system wide file, but that would probably have > problems. I like having it only rely on user config files. > Would adding some default storage to the core make sense?, > we could then have a dbus method which would revert an > individual value easily. > > 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 > > _______________________________________________ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/compiz/attachments/20070405/f1d934a1/attachment.html