[Openicc] colord Printing Plans, CPD and Gutenprint

[Kai-Uwe Behrmann]

Am 01.03.11, 10:22 -0000 schrieb 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.

Users are about choice. That vendors like RedHat have limited resources 
and try to contrain them is legitimate. I doubt ajax meant creating a 
jail like you appear to approach for Linux colour management.

> 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.

That conclusion is pure fiction. You draw a avarage user on the wall to 
justify a weak architecture. Colord is simpler as allowed. Naivity is no 
excuse for ignorance.

>> 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.

Thats ignorant. The threads on this list contain enough proposals, how to 
do stuff in a more clean, robust and easy way.

> 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).

The problem I came not around is, that colord will give a not satisfying 
answere to the "is device $foo being profiled at the moment" question.
So why not the other way around and base the colord policy daemon on top 
of Oyranos' much robuster profile selection?

>>> 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.

The problematic architecture in colord causes inflexibility. Defending 
that inflexibility by marginalising valid users requests is not helpful. 
Better would be to reflect what a general purpose CMS on Linux should do 
and what not. This involves to provide real answers to the questions not 
these weak excuses like above.

(The "95%" rule is so fuzzy. It must have been invented in a beerful night 
in the talk between some advertising genius and business economist. User 
where of course not allowed and all abroad.)

regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org