Review Request: include KolorManager in kdegraphics

Boudewijn Rempt boud at
Wed Mar 14 15:39:00 GMT 2012

On Wed, 14 Mar 2012, Matthias Klumpp wrote:

> Hi!
> Colord - just to mention that - is also not a GNOME project, it's a
> FreeDesktop project. (Doesn't mean it's "standard", but does mean that
> it's not GNOME)

Well, no, having something on doesn't mean it's not a 
gnome project; it is a gnome project, and it's widening its scope. The 
reason it's used at all is that is is used inside gnome.

> So everyone is free to contribute to it, and the
> maintainer is interested in collaborating with KDE. (which he already
> does very nicely)
> There's one thing about Oryanos I'd like to mention: I wanted to find
> out why Oryanos is not packaged yet on many distributions. Reasons are
> the strange build system it uses (looks like a custom thing to me),
> which makes it difficult to build it on multiple architectures. It
> also has dependencies like Elektra, which looks dead to the public.
> (But is still developed, as it's maintainer says) Oryanos requires a
> special version of Elektra packaged. There's also some other stuff
> going on which needs to be clearified before Oryanos can be shipped in
> distributions easily.

It's easy enough to package -- the opensuse packages I use work perfectly 
fine, so I cannot imagine that there are any real and relevant problems 
for other distributions.

> It also has some legacy stuff, like Compiz
> plugins - a KWin plugin would be better for KDE, IMHO ;-)

So that is irrelevant -- it used to be relevant some years ago, which sort 
of shows that oyranos is a project that has been going already for quite 
some time and has made several transitions already. Which is a good thing.

> On the other hand, colord has a clean codebase, less dependencies and
> it "just works" for GNOME.

And oyranos + kolormanager "just works" for KDE.

> Although I don't have experience in color
> management,

Well, that's the issue really: nearly nobody has a real and thorough 
understanding of color management. I've been working with color management 
in Krita since 2004, and I still have to admit that I don't have a good 
overview of all issues.

> seeing the younger project replacing the older one so fast
> shows me that colord at least provides enough and well-working
> functionality for color management on Linux.

The only reason colord spreads is because it's by default part of gnome3. 
That in itself doesn't show anything about its technical merits. And 
within gnome, it is actually barely used. In the end, it's the 
applications that make the difference.

> Therefore, it might be a good thing for KDE to choose it.
> (Maybe do some tests with it first)
> I also want to point you to this comparison colord against Oryanos:
> =>

Given the extremely tense and nasty discussions we've had, with Alexandre 
Prokoudine calling Kai-UWe a liar and so on, I am not sure that relying on 
one project's assesment of the other project is a good idea. In fact, I am 
sure it is not.

I'm also sure unless people are prepared to spend some time on figuring 
out what color management is all about instead of posting lists of 
"statistics", the question is not being considered on its technical 
merits. pop-contests, lines-of-code, dependencies and so on are all 
non-technical when it comes to determining whether the color management 

But then, as I've said before, for me, as the author of an application 
for which color management is actually essential, both colord and oyranos 
work fine.


More information about the kde-core-devel mailing list