Review Request: include KolorManager in kdegraphics

[Kai-Uwe Behrmann]

Am 14.03.12, 15:14 +0100 schrieb Thomas Zander:
> We had a little talk about those two projects recently on k-c-d as well, 
> where colord was proposed and Kai used that opportunity to plug his project.
>
> I then went and downloaded both codebases and looked at them.
>
> First thing that I'm worried about is that the whole project is designed 
> around user roles (called policies).  As I have been involved with KDE

Policies are grouped preferences for rendering intents and default profile 
settings. The advantage is, they can be stored instead of switching each 
single option. The policies feature was recommended to implement. 
What would you suggest to improve that feature to gain more simplicity?

> usability I have seen discussions and concepts of user roles a lot. Frankly, 
> they don't work. There is almost no research to support them, there is plenty 
> of research stating they don't work.

The policies in Oyranos are not forced other than normal settings. So each 
user is free to choose what she/he likes. There is no artificial 
limitation.

> Then there is the technical dependency tree of Oyranos;  this shows a 
> subsection of its deps;
> http://pkgs.org/fedora-16/fedora-x86_64/oyranos-libs-0.3.1-1.fc16.x86_64.rpm.html

That comes from the device plugins being included inside the Oyranos 
source tree. However users can install a minimal Oyranos library and add 
X11, CUPS or othe device plugins later. KolorManager panel has no direct 
dependency to these device modules. The advantage is that the CMS can care 
about even complex device configuration and needs minimal device driver 
interaction.

> Thats a lot of dependencies;  some of them anything but easy to find 
> packaged.
> Compare to http://packages.debian.org/wheezy/colord

I guess components needs device access somewhere in the stack to obtain 
informations about the actual device. The advantage is a small core, but 
on the other side the components need to do all device interaction themself.

> All of this could be ignored, as long as there is real cooperation and 
> willingness to work together; so I looked at how lively the Oyranos community 
> is.
> http://sourceforge.net/mailarchive/forum.php?forum_name=oyranos-devel

When talking about cooperation, then it is appropriate to look at the 
OpenICC channel. That is the place where colour management project 
interaction happens and many Oyranos developers, write there directly to 
get opinions from the community and discuss technical ideas.
http://lists.freedesktop.org/mailman/listinfo/openicc

> I don't know why  colord was created instead of working with Kai on his 
> mostly one-man project, it may have been for very good reasons, it may have 
> been just not-invented-here.  But the end result is that the new project is 
> quickly replacing the longer existing one both in developer community and in 
> usage.

It might be that Oyranos core appears slow evolving. But that is as well 
due to being involved in following other ICC related projects:
OpenICC default profiles - research, creation, quality control
basICColor default printing profiles - tals with many vendors, licensing
CinePaint - ~second open source ICC graphics editor, 3 year maintainance
ICC Examin - profile viewer
KolorManager - you know
libCmpx - long long discussions for relyable print concept, implementation
CompICC - idea, mentoring, maintainance, many improvements
Taxi - idea, concept, new standards

These projects and some others belong to the Oyranos path of finding out,
what might be useful for good colour management support on Linux. Of 
course other projects can continue more easy and faster based on that 
previous work and on the experiences made. And surely they do.

> And thats a good point; how many people use it in the wild?  I find the 
> debian popularity contest insightful;
> http://qa.debian.org/popcon.php?package=colord

It was pointed out that such results are influenced by colord being 
mandatory inside Gnome.

How does that relate to (?):
http://qa.debian.org/popcon.php?package=nautilus

> If you don't have a good idea what those numbers are, compare to; 
> http://qa.debian.org/popcon.php?package=k3b or 
> http://qa.debian.org/popcon.php?package=kdebase-workspace both of which have 
> a lower install score than colord.
>
> So, last time the colord and oyranos projects where mentioned on 
> kde-core-devel, this amounts to the data I looked through and got my 
> impressions on.
> I personally came to the conclusion that KDE is probably better off by 
> focusing on colord, even if there is currently no KDE gui for it.
>
> -- 
> Thomas Zander

kind regards
Kai-Uwe

-- 
Kai-Uwe Behrmann
http://www.oyranos.org