Hi,
> Fedora 10 ships with compiz and launches it as: compiz
> --ignore-desktop-hints glib gconf
>
> This causes compiz to load the glib and gconf plugins at startup. This
> works fine.
>
> The problem arises when the gconf database does not include those
> plugins in /apps/compiz/general/allscreens/options/active_plugins. What
> happens is that the plugins get loaded at startup, and after all the
> "general" (read: core) options are read, it then unloads any
plugins not
> in the active_plugins list right after, causing the gconf plugin to not
> configure any other plugins, and stop listening for gconf notify events
> so further configuration does not take effect at runtime (even for core
> configuration options).
>
> Using gconf-editor to add gconf to the active_plugins list allows it to
> work as expected (a viable replacement for the ini plugin).
>
> HOWEVER, ccsm does not appear to have any knowledge of the existence of
> the gconf plugin, so whenever you add or remove another plugin from the
> list, it ends up removing gconf from the list as well. Immediately
> causing compiz to stop listening for gconf notify events (see above).
Correct. Using the ccp plugin is the _only_ supported way to have ccsm
working correctly. Fedora doesn't want to do that, mainly because they
fear a switch to libcompizconfig would
a) break their desktop-effects app
b) cause a dependency of compiz to libcompizconfig
> I would be happy to supply a patch to fix this behavior, but I would
> appreciate direction on how best to fix the bug.
>
> 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.
> 2: Update the ccsm gconf backend so that any updates to active_plugins
> will implicitly include gconf in the list (this made sense to me, since
> you wouldn't want to be configuring compiz via gconf without giving
> compiz the ability to actually respond to configuration events).
No, that doesn't make sense. Libcompizconfig assumes that you use the
ccp plugin, which makes everything automatically work correctly (as
written above). Enforcing the gconf plugin (which might not even be
present) is not a good idea there.
> 3: Update the gconf plugin itself to always include itself in the
> active_plugins list when requested, and it doesn't exist (this is more
> in line with option 1, but only modifies the gconf plugin).
That is essentially the idea of
http://bugs.opencompositing.org/show_bug.cgi?id=379. David didn't like
that idea, which is the reason for this patch not being upstream yet.
David's idea (comment #4) is something like (for ccsm):
- load backend
- load settings
- look if gconf is in there -> disable DE integration, force backend to
gconf, keep glib and gconf on plugin changes
- else look if kconfig is in there -> disable DE integration, force
backend to kconfig, keep kconfig on plugin changes
- else look if ini is in there -> unsupported, bail out
- else assume ccp
This would be pretty complicated, but on the other hand would give the
user a visual clue that he can't change backends and expect things to
work if the gconf plugin is used. It doesn't cover the "gconf plugin is
not listed in the active_plugins list in gconf" case, simply because
ccsm doesn't know anything about the command line compiz was started
with (compiz isn't necessarily running at the time ccsm is run).
All in all, personally I'm in favour of option 1, perhaps combined with
the GUI changes from option 3. Any other opinions?
Regards,
Danny