<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Le 26/01/2012 18:21, Alan Bell a écrit : <blockquote cite="mid:4F218B9B.9030807@ubuntu.com" type="cite">On 26/01/12 16:28, Jorge O. Castro wrote: <blockquote type="cite">- It's possible to accidentally uncheck the Unity plugin, breaking the user's desktop. </blockquote> 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 </blockquote> It still will. The dependency on largedesktop has been done to explicitely letting people to get the cube: <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://bugs.launchpad.net/ubuntu/+source/unity/+bug/711561">https://bugs.launchpad.net/ubuntu/+source/unity/+bug/711561</a>. 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. (<a href="http://git.compiz.org/compiz/compizconfig/ccsm/log/">http://git.compiz.org/compiz/compizconfig/ccsm/log/</a>). 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): <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <a href="https://bugs.launchpad.net/compiz-compizconfig-gconf/+bug/874799">https://bugs.launchpad.net/compiz-compizconfig-gconf/+bug/874799</a> This has his a lot of people, including at UDS. Didier </body> </html>