[compiz] Annoying gconf/ccsm behavior

Danny Baumann dannybaumann at web.de
Sat Nov 29 04:16:41 PST 2008


Hi,

> After reading the comments on:
> http://bugs.opencompositing.org/show_bug.cgi?id=379
> 
> The problem stemmed from the inability to unload the gconf plugin via 
> gconf. However, what would the alternative be?
> 
> It seems like a better solution overall to simply treat conf plugins for 
> what they are, and load (and keep loaded) one plugin for the lifetime of 
> compiz. Does it really make sense to have two configuration plugins 
> loaded? Which configuration value for the same configuration key would 
> apply? Would it depend on load order? Does it make sense for NO 
> configuration plugins to be loaded? The user couldn't make any further 
> updates while compiz is running.
> 
> Maybe it would be better (at least for distributions) to include a 
> global config file that specifies which conf plugin to load for the 
> distribution, and let both compiz and ccsm read that file to determine 
> the proper backend to use. You wouldn't have to monkey with the command 
> line plugin overrides at all.
> 
> ... in fact, I think that file already exists as 
> /etc/compizconfig/config ...
> 
> The user wouldn't have to make a choice any longer as to which conf 
> plugin to configure using a particular backend. ccsm would just work to 
> configure the running compiz.

You might not have noticed it, but you just described the compizconfig
system.

> I don't wanna get crazy here, but maybe the conf plugin API can be 
> altered slightly so that the same conf plugin could be used by both 
> compiz and ccsm to read AND write compiz configuration. You wouldn't 
> need libcompizconfig any longer. The code seems largely duplicated 
> anyway between conf plugins and conf backends.

Well, you can't get rid of libcompizconfig, because it's needed _at
least_ by the configuration tools to do XML parsing, plugin list
generation, etc, pp. The only duplicated code is the actual backend
writing code (a few 100 lines) and the boilerplate plugin code in ccp.c.

What exactly would the gain of using compiz plugins from another app be
compared to just using the current compizconfig system (and forgetting
about the gconf and kconfig plugins if usage of ccsm is desired) be?
I am aware of only one thing that is suboptimal in ccp: The metadata is
parsed twice (by compiz and by libcompizconfig). On the other hand,
using libcompizconfig + ccp + backends provides additional features (DE
integration, transparent backend usage/switching). Additionally, using
compiz plugins from other apps means duplicating a number of parts of
compiz (plugins can use all functions offered by compiz core).

Remember, the gconf and kconfig plugins were written under the
assumption that config tools will write to gconf/kconfig directly; it
never was the plan to use the plugins outside of compiz. It just turned
out that there seemingly was not enough interest in writing a couple of
settings managers.

Regards,

Danny



More information about the compiz mailing list