Technical Blog of Richard Hughes

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.

2011 was my first LGM. Random points of note:

• Huge thanks go to the LGM organizers for sponsoring my flight to and from London.
• James Shubin was a superb host, and I really thank him for letting me crash at his flat for the week and eat his food. He’s a cool dude.
• Meeting up with Kai-Uwe, Peter and the other guys was really great and the OpenICC BOF was a real highlight of the week — lots of thing are coming together now. Lots of color dudes all in the same place. The only people missing that I wanted to buy beer were Marti, Chris and Graeme. Hopefully next year.
• Most of the talks were of a very high quality and interesting.
• Most of the people at LGM were developers of one kind of another, although I did expect a mix of devs and users like at FOSDEM. I’m not sure if a mix would have been better.
• I’m sure colord is stronger as a project from the feedback I’ve received. I’ve certainly swapped contact details with a few people and hopefully some interesting conversations will happen in the next few weeks.
• I think my colord talk went well, although in retrospect it was perhaps a little too technical for the audience. I also talked pretty quickly to try to condense 1h of verbage into 30 mins. Apologies to the translation booth.
• Montreal is a cool place that seems less American than America and less French than France. It’s hopefully a place I’ll return to in the future.
• Poutine is really tasty, in a artery clogging, heart-attack inducing kind of way.
• I hope LGM is in Europe next year; I hate long flights. Either way, I’ll be there.

 

Start of a new era: GNOME 3

I really want to just synchronize two directories on multiple machines. I don’t want to worry about IP addresses and things like that and I don’t want to store my private files “in the cloud”. Has anyone done a cute hack using ssh, avahi and inotify for GNOME? Note: I don’t want to backup a folder like DejaDup wants me to do, I want live multi-master replication. Unison also fails for me, as it currently doesn’t work in Fedora 15, and has to be run manually. Ideas?

GNOME Color Manager has shown 2D CIE 1931 plots for a couple of years now, but as all color savvy people know, a gamut is a 3D object, and a 2D slice can be horribly inaccurate and misleading sometimes.

To fix this, I worked for a couple of hours at the weekend to produce a 3D gamut graph using clutter:

It’s then a simple case of clicking and dragging on the hull to rotate it. Long term, there will be a way to compare the different device gamuts, but I’ve not worked out a good way to show this in the UI.

To accomplish the new plot I’ve reused a lot of the math from icc_gamin, and a lot of the setup code from the viewer example program for mash, and also used a lot of the cleverness in clutter-gtk.

To play with the new toy, you’ll need to install clutter-gtk and mash, and be building gnome-color-manager from git master.

The soon to be released gnome-color-manager 3.1.1 (unstable) will have a hard dependency on colord. Please could distribution people start making packages for colord and including them in your distributions development channel now please. I’ve done an example .spec file if that helps.

At the moment, upstream ghostscript and foomatic already use the DBus interface of colord, but this is a soft dependency. If colord is not present, they both use the non-color-managed code. If you have a spiffy distro that has a “suggests” or “recommended” attribute available for packages, it’s probably a good idea to add that for foomatic and ghostscript-cups.

Thanks.

I’ve just submitted my talk about colord to LGM 2011 in Montreal. I’m hoping I can get some kind of sponsorship, as talking at LGM would be really great.

I’m hopefully presenting at the Open Printing Summit about the same topic too. Exciting times!

Matthias and I have been working on the network panel for a large chunk of this week, now we have NetworkManager 0.9:

Quite a lot of stuff works, but there is lots more to do. If you’re using odd connection types like WIMAX, we would appreciate any help testing. At the moment, editing the low level connection details is done in nm-connection-editor, but we’ll roll this functionality into the panel for 3.2. I’ve upset the translators enough already.

If you’re testing, ensure you also rebuild NetworkManager and network-manager-applet using jhbuild.

Till has just merged my foomatic patch upstream that adds colord support. This means we now have ghostscript and foomatic support for colord, and I just need my CUPS patch committed to make everything magically work. I’m going to backport all my patches into Fedora next week, although hopefully in a few months we’ll have new releases of all the projects.

Slowly but surely, we’re getting there.

Just in case anyone else happens to stumble on this random error message when building CUPS locally:

./cupsd: symbol lookup error: ./cupsd: undefined symbol: cupsArrayNew3

Just remember to do make install before you try running cupsd.