A note on compiz development and Unity / Ubuntu

I was quite disappointed to see this in a bug comment today:

Compiz […]. The only work on it are hacks to bend it to the will of Unity

There seems to be a misconception going around that Compiz exists only to serve the needs of Unity as the compositor framework, and that development of compiz exists as a series of “bends” to make Unity work.

That is not true, and has never been true.

Internally at Canonical, compiz was always handled as a separate upstream project. It was a separate upstream project before I worked there, a separate upstream project while I worked there, and is a separate upstream project after I left.

Not once was any development decision in compiz made for the sole benefit of those who use Unity to the detriment of those who use compiz as a standalone window manager or with other desktop environments. If it did – you would know about it. Unity is a very tightly designed desktop shell in which many of the parts that make it up were highly dependent on the other parts. That was by design – the team that led the implementation of Unity wanted to create a great desktop shell, and not to create a series of independent parts.

Compiz was always the exception to the rule.

If compiz truly was a compositing framework that was a part-and-parcel of Unity, then one would see that the entire plugin system / settings framework would have been dropped – the window decorators would have been dropped, many of the plugins would have been dropped from the source tree completely, and much of the window management behaviour would have been rewritten internally to match the Unity design guidelines.

That never happened, because the DX team and later the Product Strategy team at Canonical saw the value of keeping compiz as a separate upstream project, in which Canonical and the Ubuntu community invested effort into which benefited all users and not just those who used Unity.

What did happen, during my employment at Canonical, and while compiz is the compositing framework for Unity is that the developers who are working on it tend to put their priority on things that affect the most users. Considering that its the default desktop on Ubuntu – that’s a very large chunk of users. The good thing is, that all of the effort put into that maintenance usually always benefits those who don’t use Unity as well.

There’s only one place where I screwed up in this aspect, and that was in the maintenance of the grid plugin. I believe that’s one area where I let design requirements take over the original intent of the plugin. The better thing to do would have been to implement it inside of the Unity shell. So to the original author – an apology. I’ve messed up in that regard. But I hope that all of the work I did both at Canonical and outside of Canonical has been worth it for everyone who uses compiz, and not just those who used it with Unity.

7 thoughts on “A note on compiz development and Unity / Ubuntu

  1. Doesn’t matter. Weston is still the future – a nice, lightweight WM, not the huge abomination that is X.org. Moving faster to it is the best thing we can do right now. I just hope people won’t fragment the Weston platform like they did with X (though that was mainly because X is a terrible display manager).

    Apple rewrote its display server when making Mac OS X, as did Microsoft with Windows NT. We simply can’t depend on legacy code like that. The Wayland ‘stack’ sits at about 35,000 lines of code last time I checked (very recently!). X.org? 11 *million*. This goes to prove that X is an old, massive, giant mess. You need to try to write a program for it yourself though to realise how awful it is.

    PS: don’t give this ‘boo Wayland runs only on Linux, no [insert obscure UNIX-like OS here]. We know the people that run those are far too clever to need graphics of any form anyway.

    1. I agree that it would be better to move to a platform with less fragmentation, but I don’t necessarily think the the less lines of code the better. That opinion isn’t held with those who work on small kernel-style codebases, but it is something I dissent from.

      The better metric to use in this case to determine how crufty an old codebase is, is how many of those lines are hit at runtime in the standard usecases, or are hit in tests (and then, a submetric is how precise the tests are).

      In well-designed projects, those extra lines are often used to construct systems that are clearer and more robust, more easily testable and easier to reason about.

  2. One thing that has led to this misconception is the compiz.org website that leads people to believe compiz is a dead project.. And that nearly all other distributions only pull releases from compiz.org (and thus outdated). Giving some love and updates to the compiz.org page would greatly help in the misconception that compiz in ubuntu is a fork of the original product.

  3. I ended up finding this blog in a search to see if it is possible to get compiz working on a recent release. I’ve tried two rather-mainstream releases, Debian stable 7.1, and Mint 15 MATE. I’ve been unable to get compiz to work on either. The install goes fine, but it never starts working, even after a reboot. I have seen several other comments other places saying that compiz is a dead project. This is the first place I’ve seen saying otherwise, but I’m not seeing any evidence of it. Especially with being unable to get it working on Debian friggin stable.

  4. Sorry for the negative tone of my previous message. I am really sad to see compiz being dropped by major distros and falling by the wayside. So much so that I’m sticking with debian stable 6 for the time being in order to keep running it.

Leave a comment