[compiz] Flat file backend (ini)

[Mike Dransfield]

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.