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