[compiz] Annoying gconf/ccsm behavior

Bob Richmond bob at lorez.org
Fri Nov 28 11:08:04 PST 2008


drago01 wrote:

> On Fri, Nov 28, 2008 at 9:19 AM, Danny Baumann <dannybaumann at web.de> wrote:
> 
>>> Some options I considered:
>>>
>>> 1: Treat plugins passed on the compiz command line as unremovable at
>>> runtime. active_plugins can safely not include gconf, and gconf will
>>> remain loaded for the lifetime of compiz.
>> At first I thought that this would be no viable way. Imagine somebody
>> loading the switcher plugin from the command line and loading fade at
>> runtime later on. He would have no chance of getting switcher's
>> opacity/brightness/saturation changes faded.
>> On the other hand I wonder if there is _anybody_ using that kind of
>> scenario anymore. If we consider that an invalid use case, enforcing the
>> command line plugins as being loaded all the time might be a pretty good
>> idea.
> 
> Nobody really uses the command line for any plugins but configuration
> / configuration related ones.

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.

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.

>> [...]
>> All in all, personally I'm in favour of option 1, perhaps combined with
>> the GUI changes from option 3. Any other opinions?
>
> + 1
> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz


More information about the compiz mailing list