It's time to jettison CCSM

[Alan Bell]

On 27/01/12 09:07, Didier Roche wrote:
> 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).
yes, I understand the circumstances. Dropping the requirement seems to 
let everything still load for me and allows me to switch between cube 
and wall so unityshell.xml only requires:
<requirement>
<plugin>opengl</plugin>
<plugin>compiztoolbox</plugin>
</requirement>

I kept wall and cube in the <relation type="after"> block, so I would 
think that would deal with the loading order (I might be wrong, but it 
works for me). Dropping largedesktop from the requirements does allow 
users to break their workspace switcher still, but nothing else seems to 
be problematic about it, though your mileage may vary.

>
> > 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/).
>
what might be good is to not turn on and off plugins live when you hit 
the enable checkboxes, but have an "apply changes" button that does 
everything, so the screen doesn't redraw when you navigate about the 
GUI. Live settings changes are fine, but live plugin activation is 
probably a bit scary.

> 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.
lets fix that widget then. There was another comment about mouse scroll 
wheels activating the HScale widgets, these are essentially redundant as 
there is a spin control next to all of them, so I took out the HScale items
https://code.launchpad.net/~alanbell/ubuntu/precise/compizconfig-settings-manager/safetyfirst/+merge/90389
> 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.
OK, but it is fixed, right?
>
> Didier
>
>