[Compcomm] Suggestion for settings for everyone

[Danny Baumann]

Hi,

> Since its been requested, here is my suggestion (again)

Thanks.

> *OFFLINE*
> 
> This can work offline because the code flow is like this
> 
> _online_
> 
> GUI -> libccs -> ccp -> compiz -> ini/gconf
> 
> _offline_
> 
> GUI -> libcs -> direct to file/gconf (with metadata xml)

I don't yet see the advantages of that new approach. From what I see, the
situation is the following:

Differences:
- If Compiz is loaded, the storage plugin would actually store the settings
instead of the CCS backend.
- We could see / set settings of plugins without metadata (are there any?)

Same:
- ccp still needs to be loaded for the settings manager to work.
- We still would need backends for the offline mode.

So the situation then hasn't changed much except that the compiz settings
plugins _must_ be compatible to the CCS backends and that there must always
be a matching backend for each settings plugin. Did I miss something in your
idea?

> The offline part would obviously mean that the ini backend
> would need to be written to be compatible.  AFAIK the
> original ini format was designed to store information about
> the datatype but that is not needed any more because of
> the xml files.

What do you mean by "the original ini format"? If you mean the format used
by the CCS INI backend - I chose it because
a) there was a parser available for that
(http://ndevilla.free.fr/iniparser/) and
b) it's easier to create profiles if you have one file per set of settings
instead of one directory and
c) it's - in difference to the files created by the INI plugin - an actual
ini file format (http://en.wikipedia.org/wiki/INI_file) ;-)

I didn't really feel like reimplementing an ini parser, and I also didn't
feel that the ini plugin is already relevant enough that compatibility is a
must. This is not meant rude or anything like that, but the ini plugin is
available since 0.4, where the gconf plugin is available since the
beginning. I just assume that the vast majority of the users uses the gconf
plugin, so I chose the easiest way when implementing the ini backend ;-)
We would highly appreciate if you could make an ini-plugin compatible
backend for CCS - I just don't have the time for that at the moment.

> *DE Integration*
> 
> This was done ages ago as a different plugin by gandalfn.
> I don't suppose it would be hard for KDE or others.
> 
> The information is here
> 
> http://gandalfn.wordpress.com/2007/01/04/compiz-extra-036-gnome-compiz-
> manger-extra-010x/
> 
> And the plugin (as a patch) is here
> 
> http://gandalfn.club.fr/ubuntu/compiz-patch/92-gnome-bridge-
> keybindings-plugin.patch

Thanks, I'll have a look at it.

> *Seamless backend switch*
> 
> Firstly I have to say that I don't really understand why
> Joe User would want this feature, they should not care how
> their settings are being stored, if they use Gnome then they
> should use gconf, ini otherwise.  The startup script can handle
> it.
> 
> ASSUMING there is some valid reason why they would want to
> switch backends then there are a few solutions to the problem.
> 
> It seems like it is closely related to profiles (which you did
> not mention as a required feature).  Profiles can be done externally
> direct to the storage or they can use the abstraction plugin/lib.

You're right, I forgot the profiles. What I'd like to see in terms of
profile handling (and what's currently implemented in CCS) is that the
storage place for each profile matches the storage place of the "main
dataset". This means that for ini other profiles just are other ini files,
and for gconf that other profiles are other parts of the gconf tree (with
the compiz schemas assigned to them). I don't see how that could be achieved
by using the Compiz settings plugins only.

> If it is related to profiles then switching backends would be this.
> 
> save current profile -> switch backend -> load profile again
> 
> If it cannot be done that way then I *think* you can actually do
> this (assuming compiz was started with gconf).
> 
> Load ini plugin (after gconf).  I think this will get ini to
> write out the settings (maybe not, but it could be fixed somehow).
> Then remove gconf.  I see no reason why compiz would complain,
> its only a question of what happens.
> 
> If I remember right, I used to load ini after gconf, then change
> a setting and ini would write out the settings (I wrote write
> functionality before read functionality)

That part of the functionality would work, right. The problem I meant was a
different one: If you switch backends, the startup script will need to take
care of that. If you switch from gconf to ini, you have problems if the
startup script still chooses gconf next time ;-)
That's what I originally meant by "seamless backend switch": The used
backend is completely transparent to the startup script, because the
settings plugin takes care of that.

Regards,

Danny