Am 02.02.2013 22:33, schrieb Daniel Nicoletti:
2013/2/2 Kai-Uwe Behrmann <[email protected]>:
I am not so sure that will help. colord follows a minimalistic approach as
is typical to GNOME. At the moment Oyranos supports quite more features.
In regards to colord we gave up our requests to see certain features added
and maintained. We wanted some policies considerd for ICC shared profiles,
which is a essential part for Oyranos. But these whishes where completely
ignored. We try to work around things and hope to cooperate better based on
specs.
Who wrote the specs? You did right? So what about providing good use cases
and not complex features that will just make the code more likely to have bugs
and less likely to get used by real people. We are always open to new features
when they do provide a good use case.
Oyranos is based in many aspects on community driven spec from OpenICC.
I have the impression you did not read the OpenICC wiki pages, the specs
or email list. That's probably a problem for a person, who wants to
maintain a CM stack inside KDE. You completely depend on one API and the
word of one person without good own reasoning. That's all you offer KDE.
colord
------
* Linux only, CMF only
* Not a CMM, leaves that to toolkit, app or window manager
* libcolord gobject C library, LGPL 2.1
* Config stored in DConf
* DBus service & api for all options
* Command line tool for all options
* Intergrated into GTK, CUPS, SANE, etc.
SANE-backends-1.0 (e.g. libsane.so) has no dependency to DBus or colord.
Each colord client, which likes to support SANE has to implement that by its
own. colord has no device specific code inside. ldd shows that easily on
Linux.
colord doesn't need to have device specific code, since it only provides a mean
to match device <-> ICC,
Coding device specifics in each client makes detection of driver
settings more error proune, as is it is a not simple and is a repeating
and to be continued task.
Oyranos
-------
* CMF and CMM abstraction API
* Linux and BSD support using own CMF implementation
* OS X native ColorSync CMF support
* Plans for Windows CMF support
* CMM api only supports lcms/lcms2, plans to re-write to support more
CMM's
* C library, BSD license
* No DBus service
* Command line tools for certain options
* No integration into CUPS, GTK, SANE, etc.
* Not fully stable api yet
* Must be hard build time dependency
Every CLI tool can be called at runtime especially easy on Posix systems.
That is not much different than DBus. So it would in theory be possible to
use Argyll/Oyranos or colord in exchange without hard linking. I guess the
amount of code might be similar like supporting all those different DBus
APIs + support code.
Using command line tools is actually extremely hard/boring if you need to keep
parsing it's output, QtDBus brings you all the convenience of SIGNALS and SLOTS
and is async as well.
In KolorManager we do it *with* SIGNAL + SLOT for asynchronous tasks. No
problem.
Let me add an advantage. Argyll and Oyranos have the needed device dependent
code already inside. No need to fiddle with EDID, X11, CUPS and other API's.
Since the work is so small I don't really see such advantage...
The concept in colord is to use a device ID, which is a actificial name.
That one might have nothing to do with actual colour behaviour and thus
is eigther only particial useable for profile association or inflexible.
What appears small work to you results from the omitting of real world
use cases.
In some ways Oyranos could be seen as an alternative to Qt in providing a
common abstraction api across the major platforms, except it is in C, not
yet
on Windows, and requires explicit CMM code rather than having it implicit
in
the Qt graphics classes.
The last half sentence makes no sense to me. First of all. lcms is the most
highly valued CMM on the planet right after the AdobeCMM. It's portability
is simply amazing.
CMM code is dlopen'd in Oyranos on demand. E.g. KolorManager will never link
against or call lcms.
On the opposite, a ldd to libcolord.so shows a hard dependency to
liblcms2.so .
Qt graphics classes are dependent to any CMM in what way? Are Qt apps free
to choose a CMM if Qt graphics classes have already choosen one?
There is no color correction in Qt yet, dlopening a library is
actually a much worse
practice than linking against it, if lcms change their API you won't notice
at compile time and might give nice crashes with odd backtraces.
I did not write what you imply. Your blindly jump to hostile assumptions
about a project you appearently did not care to look much into.
The Oyranos CMM wrapper modules in question link against lcms, but the
modules themself are dlopend like any normal plugin system does.
I did not even hear about that service. Even though I am one of two persons,
who had worked on specs for a shared CMS DB on Linux. The other person is
Graeme Gill. His implementation is based on JSON files, which I find sound.
You should really rethink about JSON, it should only be used on the web...
Let me outline point 4) and what I expect that to become:
colord is mostly a small API for DB queries. The DB itself is otherwise
hidden. The outlined project will need many own code to implement the basic
device and driver configuration detection. Or it can choose to ignore
aspects leading to a poor implementation. As soon as one has written all the
needed code for KDE or Qt it needs to be continued for each other supported
platform. Thats the logic. In the end it means parts of Oyranos or GCM get
rewritten in a Qt specific style. All remaining Linux DE's have to rewrite
everything by themself too. The actual Gnome CM (colord) way makes a massive
repeat of code necessary. IMO that is a waste of programmers energy. Because
KDE/Qt will for sure not provide a shared API suitable for any Gtk/EFL or
other DE project out there.
I'm sorry but I really don't understand why do you keep saying about device and
drivers?
The whole chain of drivers, their colour related options, the colour
device itself + involved media influence all the colour result. This
chain has to be reproduceible, otherwise reproduction of colour is not
managable. ICC profiles are merely a characterisation of a certain
colour reproduction state. A CMS typical tries to get all required
infomation to reproduce a colour behaviour and get most parameters to
reduce unwanted disturbance. That's the reason why driver settings must
be covered as well. In the case of X11 that might be switchable colour
primaries, which are detectable over the EDID data. For most other
device classes exist at least gamma and more driver parameters, which
need to be taken into account for profile selection.
If you are talking about X then all you need to do is talk to XRandR which has
no sense to be abstracted in a library or put on some backend thing since on
Windows and OSX they will handly that.
There exist at least two open source implementations, which exactly do
this kind of abstraction. Applications use these and in parts own
abstraction layers.
So if KDE will write some color correction abstraction this would only
to allow apps like Krita to run on OSX/Windows/Linux without lot's of ifdefs
but after a talk to Richard Hughes he explained that they are too different to
abstract, and as with him I care most/only about Linux.
Funny.
regards
Kai-Uwe Behrmann
--
www.oyranos.org
