And so, long story short, we decided to revert the change for F12.
Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.
GNOME Color Manager now a mailing list – It’s for discussion about colour management in GNOME, and that sort of thing.
Late last night, after a few hours of intense refactoring (to allow udev based devices, as well as xrandr based devices) we got the initial scanner support working:
This lets us support printers and digital cameras pretty easily too. At the moment we just need to figure out how to make gnome-scan make a scan for us and save it in tiff format, and then we can get the calibration working for all types of scanners. Of course, you need a precision printed reference image, but you can get these pretty cheaply from Wolf Faust.
Then, we need to work with the gnome-scan guys to agree an interface so that gnome-scan knows what profile to use for each device. Either a library or DBus interface (with calls in either direction) are being considered, although I think the session-activated dbus interface is probably going to win. There’s still quite a bit of integration work to make CUPS ICC profile aware, but that’s on the list after scanners are working. After all, you need a calibrated scanner to calibrate the printer. Help is always welcome, so please checkout the code and help find bugs.
GNOME Color Manager now has a website. The mailing list will be set up soon, which means we can start building a community.
I’ve also recently completed the calibration integration, using the great ArgyllCMS to do the heavy lifting. This means it’s literally two clicks (with no options!) to generate an accurate screen profile with hardware that costs less than $50. And it only takes about 15 minutes. Anyone that takes photos or cares about colour accuracy should really invest in one of these things.
Also, a few people have been telling me to just write a GNOME front end for Oyranos and scrap what’s already been done. While I think Oyranos is a great project, I needed something that “just worked” and did the bare minimum integration without a hundred configuration options or integration points. I’ve also been told that some parts of colour management are heavily patented, and so I’m going to keep things as simple as possible for now so gnome-color-manager can be used in as many places as possible. If the Oyranos guys want to hook into gnome-color-manager then that would be great, but I think for now, GNOME Color Manager should aim to do much less than what the Oyranos guys have been trying to achieve.
Well, you could say I’ve been busy. I’ve had a couple of days off this week, and instead of relaxing like normal people, I wanted to fix ICC profiles on GNOME.
First the hard bit. You have to go to your screen vendors website, and download the “drivers” for your monitor. They’ll likely come in a zip file with other junk like .inf, .cat and other windows driver stuff. Somewhere in there should be a .icm or .icc file which contains the data you need specific for your monitor.
Then go to System->Prefrerences->Color Profiles and select the correct file for your monitor. There are also some other test files you can play with.
Then you can set any gamma or contrast or brightness settings if you wish. The gamma defaults to 2.2 just like newer Apple systems and Windows XP, but if you don’t like this you can set it back to 1.0.
You’ll need shared-mime-info from git master (for the double click to work) and gnome-color-manager from gnome git.
There’s still lots of work to do, such as:
I’ve ordered myself a Pantone Huey hardware calibration device, and soon hope to have this wired up to gnome-color-manager to make accuratly calibrating a device as easy as a single click.
Now, I’m all out of time for this little bit of fun, as I have to return back to fixing PackageKit and DeviceKit-power for the impending F12 release, but if anyone wants to help me with this I would be very grateful.
I’ve got a multi-monitor setup here, with my T61 being my primary display, and a 28″ LG flatpanel as my secondary display.
I also take a lot of photos, and do editing in GIMP and Rawstudio and have noticed the colours on the LG are very different to the colours on the T61 screen. And when I print them, they bear little resemblance to what I just saw on screen. I’m almost thinking of buying a macbook and OSX just so I can actually see the colours I’m about to print. Heck, even Windows XP does things better than Linux does now.
I’ve done quite a bit of research, and found the general state of colour profiling to be, well, pretty hardcore, and in GNOME practically unusable. I can set my xgamma table using xcalib or dispwin, but this isn’t aware of xrandr setups and only applies the profile to a single screen. It’s certainly not a persistent setting or easy to figure out as it’s not installed by default.
In an ideal world I would visit System->Preferences->Color calibration (which is installed by default) and then either import the .icm file I’ve downloaded from the manufacturers website, or click a button and calibrate my display using an external calibration device. Certainly no commands on the root prompt, or typing in a bunch of hex.
So what am I thinking:
Now, this colour problem is very complicated. There’s lots of work in applications to support other colourspaces and profiles and lots of very clever colour libraries (e.g. ArgyllCMS or lcms) but not a lot of work is being done to actually make this usable on the desktop.
Now, I’m very short on time these days, but would be very willing to co-maintain a project (or join an existing one) if other people are interested in this. I’ve got more than enough work to do with PackageKit, DeviceKit-power, and gnome-power-manager but I can spare a few hours a week to this as I think it’s a very important problem to solve. If it’s annoying me with my photography hobby, then it’s got to be a really big deal for professionals trying to use Linux. So, anyone interested?
There’s been a lot of noise about PackageKit and debconf in the past, but not an awful lot of coding… Until now.
Daniel Nicoletti is the maintainer of KPackageKit, and a log time contributor to PackageKit. He’s also the guy behind all the recent SimulateX() methods that required quite a bit of clever coding to work properly on all backends. The simulate methods alone make PackageKit much more useful with apt (where updating a package can remove another) and now he’s dealing with the debconf problem.
I’ll not repeat what he’s planning to do as all the details are available on his blog, but it basically involves adding a DBus frontend on debconf and telling packagekitd a private connection of a helper program running in the session. This means debconf can work in the standard PackageKit “no blocking” modes when required (e.g. for an unattended update) but also ask required questions when setting things up like MySql when running interactively.
I’ve still not changed my stance on asking questions and blocking during a package install, but with this new helper program and secondary session interface, a lot of the debconf headaches can go away. I’m sure all the changes might take a few weeks to even be prototyped, but it’s nice things are going in the right direction.
A few people commented on my blog after my last post, and asked me if I actually liked GNOME Shell. My last post wasn’t meant to be stinging criticism, more pointing out things that need to be addressed before we can call this the shell of GNOME 3.0. I’ve filed lots of bugzillas (some already fixed!) and I’m pleased to say that most of the issues I’ve brought up the developers seem keen on addressing. Owen has been working hard on the theming code, so hopefully I can get a less white-on-black theme for my little old eyes. Dan has been working on multi-monitor support, and it’s much better already. I do heartily recommend installing mutter and gnome-shell from gnome git, rather than using the distro built packages, as it’s all being implemented / fixed so quickly.
I do think I’ll be sticking with GNOME Shell, as it really is some cool stuff.
I’ve been unwell the last couple of days, and with a muzzy head programming isn’t that easy. So I decided to try out gnome-shell and document some of my initial findings. The following finds are purely subjective and my own opinions only. Comments are welcome telling me I’m being a moron, or that an issue is fixed in a newer release. I’m currently using the newest packages in Fedora rawhide.
So, it’s certainly very different to what we’ve had before, but you can clearly see it’s a preview, not a final release. It’s certainly not useful to me as a production desktop just yet.
Every time somebody writes “Linux is about choice” something inside of me dies. Just because something can be done, doesn’t mean it should be done.