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
