[compiz] Annoying gconf/ccsm behavior

[Bob Richmond]

Danny Baumann wrote:

> 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 don't believe Fedora's design goals are incompatible with either of 
the possible changes I'm proposing. (see below)

>> 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.

The configuration plugins are kind of a special case, though. The 
"configuration" bit is the part that actually drives the loading and 
unloading of other plugins. I'm not sure what the original intention was 
behind allowing plugins to be overridden from the command line, but it 
at least makes sense for configuration plugins, since that bootstraps 
the rest of compiz's behaviour. Maybe it makes more sense to change the 
meaning of the command line overrides to just allow the user to load the 
correct configuration plugin (and it's dependencies), and let the rest 
of the plugins simply remain configurable by whatever configuration 
backend is chosen.

>> 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.

Well, the difference here is that when you choose a configuration 
backend through ccsm, you're only updating the configuration that the 
associated compiz conf plugin will actually read and use. It does make 
sense to include gconf in the active_plugins list when you were 
configuring compiz through gconf, because that configuration would only 
be active if the gconf plugin is actually specified on the command line. 
It wouldn't, for instance, also update active_plugins for the ccp 
backend. It would be a backend-specific implicit override to make sure 
the associated compiz conf plugin remains loaded if the user chose that 
one when launching compiz.

>> 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

Well, libcompizconfig is only really a dependency for ccsm, right? It 
shouldn't be that complicated to create a consistent interface where 
each configuration backend knows the plugin dependencies for the conf 
plugin the user is targeting, and make sure those dependencies are 
implicitly included when the user is configuring via the associated backend.

> 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