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:
- Redesign the control center panel and push it into the gnome-control-center project
- Redesign the calibration framework using the new GtkAssistant style, rather than using lots of modal dialogs.
- Move the profile registration into a gnome-settings-daemon plugin
- Move the device registration into a gnome-settings-daemon plugin
- 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.
Seems nice, but is this something I need if I just occasionaly take photos with my N900 and then store it and watch it, sometimes scan something and sometimes print something with my black and white printer?
I.e., on colord page you talk a lot about color profiles, but what are those? The use cases there are full of color profiles, but what does it mean? I have been using computers for over a 10 years now and have not ever heard about color profiles (and therefore never missed that).
I am not saying your work is useless, but maybe some layman explanation somewhere would be appropriate if this is going to be a part of GNOME and exposed to the user via control center.
If you’re just printing documents on a B+W printer, and taking snaps on your N900 then it’s unlikely to be used by you. What you might appreciate is the display compensation, i.e. making colors on your screen match to what they are supposed to be like. This means if you visit redhat.com, you see the logo in “Red Hat Red” rather than some approximation your monitor has done. When I’ve calibrated peoples monitors at conferences it’s always been a pretty instant effect followed by gasps of “ohh wow”.
But, you’re right. We do a pretty poor job explaining what a color profile really is. I’ll try to fix that in the UI, but I’ll talk to the designers first.
In the GIMP documentation is a nice page, that explains color management:
http://docs.gimp.org/2.6/en/gimp-imaging-color-management.html
Perhaps that helps.
Hi Richard! I can’t wait to use color management. Should I order a Huey for the office? Is there enough working code now to start testing stuff out? (*knows sadly little about color calibration* )
Yup, go grab a Huey. I reverse engineered the Huey, and so we’ve already got great native drivers :-)
I know very little too, but this sounds great. I’m sadly ‘not getting it’ and have for instance, failed to create a usable profile for my monitor, even though I have a color calibration device and agrylcms.
Anything that can make this more user friendly and better integrated would be a win.
Hi,
Looking at your last screenshot, I need to remark: “Calibration quality” is too verbose and break the 1 word per line of the list [futhemore take car of long language translation]. It is “Calibration”. You have no other entry, no “calibration intensity” or so on. Quality is subjective. In fact : “Higher calibration quality requires many color samples and more time” is “Better calibration requires more color samples to test”. And the list bellow indicate the corresponding time.
This is awesome news! Just got an “x-rite Display” lent by my photo lab guy … would that work with zour new stuff? (And can your new stuff be made to work with Gnome 3.0?)
An x-rite display should work just fine with the argyllcms driver.
>can your new stuff be made to work with Gnome 3.0
No, not really. You can install gnome-color-manager 3.0 for GNOME 3.0, but the new stuff is targeted to GNOME 3.2, as you need new library versions of a few things.
The first screen-shot hierarchical list in a classic way, but in a wrong way… A user should see without any intervention all the peripherals (current state ok), but also all the selected profiles (currently wrong).
Once a profile is selected, this profile should appear permanently. The hierarchical list of profile should move from the current level to the 2nd level, those of profile.
No profile selected: I see only the list of peripherals.
A peripheral with a selected profile. I see the peripheral with its active profile.
Want to switch profile. I click on the profile and the list of all others is displayed.
Regards.
I’m not entirely clear what you mean? Could you mock up a screenshot for me showing what you mean please. Thanks.
I have done few mockups with comments. You can look at these images when accessing the public Picassa gallery at the address below.
https://picasaweb.google.com/viale.fabrice/GnomeControlCenterColor?feat=directlink