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.
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.
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.
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.
_______________________________________________
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
