[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