[Openicc] colord Printing Plans, CPD and Gutenprint

[Richard Hughes]

On Tue, 2011-03-01 at 12:08 +1100, Graeme Gill wrote:
> You can't assume that everyone will use the "one dedicated profiling package".
> People want choices, and there needs to be room for development and
> innovation. (One of the reasons people get mad at Microsoft and Apple
> is their "making life simpler by not giving you any choice" approach.)

Right, but Linux is not *about* choice. See
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
for a better argument than I could ever write.

I would agree with you that we need more choice if every application on
the Linux desktop was color managed by default, and we had a super-sleek
calibration process with great tools for power users to use. But
unfortunately at the movement we've got quite a few command line tools
in layers that overlap that most people are not using. It's a pretty
bleak picture really.

> So create a general mechanism that any and all calibration and profiling
> software can use. By all means use this mechanism to provide a default,
> simple to use profiler for your particular ecosystem.

Right, that general calibration notification mechanism is a DBus method
in colord. No-one has proposed anything else, and no other code actually
exists that can achieve the same result.

Even if the user wants to compile, install and configure oyranos, it's
trivial for oyranos to ask colord "is device $foo being profiled at the
moment". One central API that is usable my all calibration software
(which, I'm struggling to think of more than argyllcms at the moment).

> > GNOME Color Manager. I've not yet decided on whether we should show
> 
> Great. And if it's not a Gnome system ?

Alex Fiestas (afiestas at kde.org) is working on a KDE policy agent for
colord. He's aiming to have it ready for KDE 4.7.

If you're not using either KDE or GNOME, you're already in the
fraction-of-a-percent group of people. In this case you can either write
your own policy agent for the desktop (a few weeks work) or you can
write wrapper scripts in bash around all the existing tools. My emphasis
for software has always been to make doing 95% of the user-cases "just
work" and allow the other 5% of use cases to be hacked around by someone
who knows what they are doing.

Richard.