It's time to jettison CCSM

Didier Roche didrocks at ubuntu.com
Fri Jan 27 09:07:37 UTC 2012


Le 26/01/2012 18:21, Alan Bell a écrit :
> On 26/01/12 16:28, Jorge O. Castro wrote:
>> - It's possible to accidentally uncheck the Unity plugin, breaking the
>> user's desktop.
> Maybe make it a bit harder to do that, principally by removing the 
> depends on largedesktop. The reason people uncheck unity by accident 
> is because they want to turn on the cube. I think if you just drop the 
> depends line then it won't disable unity when you change your 
> workspace switcher from wall to the cube. If you uninstall wall and 
> cube then the workspace switcher stops working which is logical 
> enough. If you want to make it impossible to disable unity then you 
> can probably do that
It still will. The dependency on largedesktop has been done to 
explicitely letting people to get the cube: 
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/711561. We need to 
have unity depending on either cube or wall for some plugin loading 
order that ccsm can't handle right otherwise.

The issue in this particular case is a ccsm/libcompizconfig one. 
Basically unity depends on largedesktop (features that I patched 
upstream to be provided by the 2 above plugins, cube and wall...). You 
enable cube, cube conflicts with wall, wall is deactivated (cube is 
still not enabled at this stage). Then, ccsm/libcompizconfig tells "oh 
wait wait, there is no largedesktop provider anymore, I need to remove 
unity". It displays the warning and people check "yeah, go ahead", then 
cube is enabled (but no more unity).

 > The suggestion to drop ccsm as a whole does feel a bit like "Unity 
doesn't work right with other plugins, lets get rid of all the others" 
when educating Unity to play nice with it's friends would be a much 
better solution.
As you can see above, this is far from being a "unity not playing nice 
with its friends".

There is a need for transactional handling there so that dependencies 
are just checked at the end. From what I heard from upstream, it will be 
quite a lot of work and really not trivial, but contributions are more 
than welcome there. However, seeing the number of real recent 
contribution on ccsm (12 commits that impacted the code in the last 
year, 28 in the last *two* years! 38 if we go until the last 3 years!), 
we can see there is basically no maintainance on it. 
(http://git.compiz.org/compiz/compizconfig/ccsm/log/).

This is just one example where ccsm is playing bad, there is as well the 
case when if you set the real default for an enum setting, this makes 
compiz crashing. Consequently, and only because of ccsm, we have to put 
a fake setting for it in the profile. Another big issue we had with ccsm 
(because of compizconfig-python) is that people clicked on 
"preferences", then, because of bad data given, ccsm fallback to the 
"default" profile which has no unity (which is setup on purpose to allow 
people using compiz without unity): 
https://bugs.launchpad.net/compiz-compizconfig-gconf/+bug/874799
This has his a lot of people, including at UDS.

Didier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-desktop/attachments/20120127/b6729aa8/attachment.html>


More information about the ubuntu-desktop mailing list