Color Management Integration in GNOME

Back a couple of years ago, I started gnome-color-manager. Like all new projects grown out of an idea, it was a self contained project that could be added to GNOME if the user wanted, or removed if they had space or stability concerns.

A year ago, a large part of gnome-color-manager got forked out into the colord project, as color management was needed on desktops like KDE, and also we needed a system component for CUPS. This made the lines of code in gnome-color-manager drop substantially, but then gnome-color-manager gained a dependency of colord.

Fast forward to about 6 months ago. The design team wanted some pretty drastic changes to the color management interface, and most people agreed that is CM should be a core part of the GNOME desktop. It needed to be properly integrated rather than a stand alone package. The following things needed to be done:

  1. Redesign the control center panel and push it into the gnome-control-center project
  2. Redesign the calibration framework using the new GtkAssistant style, rather than using lots of modal dialogs.
  3. Move the profile registration into a gnome-settings-daemon plugin
  4. Move the device registration into a gnome-settings-daemon plugin
  5. Integrate the colord profile information with the GTK print dialog

For point 1, Bastien wanted me to convert my hastily-written libcolord sync methods into async methods. This meant adding lots of new code to libcolord, and in the end I rewrote most of libcolord to ensure that all the async methods were indeed non-blocking. This took a couple of days talking to the designers, and another couple hacking colord, and another few days hacking gnome-control-center.

For point 2, I had to perform some pretty major surgery on the calibration code in gnome-color-manager, and I’m sure I’ve broken something for somebody. That said, the new UI is pretty and certainly easier to use. To do this I spent two days in the #gnome-design channel posting hundreds of screenshots and talking to all kinds of designers about new ideas. The code itself was probably another couple of days. Matthias found a GtkAssistant bug that Benjamin promptly fixed. Now I’m happy with the new wizard.

For point 3, it was pointed out in the gnome-settings-daemon review that I shouldn’t be passing filenames to profiles in the users home directory and instead I should be passing file FDs. This is of course better from a security point of view, and I spent about a day adding the FD passing as an optional feature to CreateProfile in colord. This uncovered a bug in SElinux (it appears the FD passing stuff is not well tested), which is pretty much solved now. I probably spent half a day working out the SELinux bug.

For point 4, Bastien wanted a lot of the Xrandr functionality to be merged with the existing stuff in gnome-desktop, and for the new color plugin to depend on that. This meant an API change to gnome-desktop, and two new patches for feature requests. These needed followup patches to address bugs and style issues, but hopefully those patches will be good to commit later today. These patches took up about two days of my time. This leaves the device registration patch to g-s-d which is almost ready for prime time too.

For point 5, I initially prepared a patch for the GtkUnixPrintDialog, which worked, but Matthias said was in the wrong place. This took nearly a whole day. I’ve re-factored this into the CUPS print backend and that patch is now awaiting review, although I fear some more drastic changes to the CUPS backend might be required. New functionality that was required in GTK has now been coded, reviewed, committed and fixed. This took another day.

So, all these days look like a giant waste of time, considering you can’t do anything more than you could a couple of weeks ago. But, think again. Taking the time to do the design work correctly, and to build on existing projects and libraries is the key to success in the open source world. Bastien was so strict about gnome-control-center and gnome-settings-daemon as ultimately if my new code breaks just before a big release, he’s the one who has to fix it. Federico was strict as he’s got to maintain and fix gnome-desktop for the coming years. Matthias was so strict with GTK as he’s got to keep things working in a sane way and doesn’t want hacky solutions that will be a nightmare to debug. We all get to use the new stable, debugged and supported code.

This is how open source is supposed to work. It takes an amazing amount of time and patience to do this, but it’s really the only sane way to integrate new functionality into an existing system. Re-implemented features lead to re-implemented bugs, and having to fix things in more than one place. I’m so lucky working for Red Hat, as I get the time to do things like this properly without people breathing down my neck for different things. There are not that many companies that understand how to really foster an open source ecology.

So, expect GNOME 3.2 to be quite cool from a color management point of view. I’m getting there, with a lot of help from my friends.