[Openicc] Helping with colord

[Kai-Uwe Behrmann]

Am 08.03.11, 12:02 +0300 schrieb Alexandre Prokoudine:
> Oyranos? Not used in any software project any distribution relies on.

Oyranos needs to convince projects. That could I agree with if you mean 
this. But not before it is ready for. Nevertheless Oyranos is useable 
for automatic monitor ICC profile setup. Any distributions can ship 
Oyranos already for that.

> Kolor Manager? Never made part of KDE, nor integrated into digiKam as

Kolor Manager is in KDE playground, which is the official path to join the 
KDE project.

> planned. Instead a new project is started.

There are many projects about configuring ICC devices on Linux. I know of 
at least five. I am sorry if you perceive development speed slow. I doubt 
that it happend and happens with other projects more fast at the same 
feature set. Building colour management into Linux is complex.

> And you know why? While having created a nice architecture (I did my
> bit iof pluggin trying to get Scribus developers use Oyranos in the

My impression was, it needs stable APIs before starting to create patches 
for projects like Scribus and others. We are working on that. Oyranos is 
not the first library, which takes serious time to provide a stable 1.0 
API with a refined and supportable feature set. Personally I consider this 
as a desireable goal.

> past), you made a number of utterly wrong design decisions, from UI
> toolkit to configuration system, and now you *suddenly* discover that

Oyranos does not depend on FLTK. FLTK is nowhere stated as a hard 
dependency[1]. This is as well clearly mentioned in the FAQ[2]. And I 
obtained notion that interessted reviewers find this page.

The same on Elektra. It is not externaly needed in order to build Oyranos. 
Compared, can colord be build without a sql data base? I guess no. Does 
the KDE or Gnome desktop work without a configuration library? No. Why do 
you want, that Oyranos shall store its configuration data in the blue. 
Thats not even for Oyranos possible.

I am highly depressed about Richards and your repeatedly wrong statements. 
It causes real damage.



Instead we need here contructiveness, fairness, to honour each other and 
keep the truth enabled.

> desktops don't want it. Well, guess what -- you are not in position to
> tell desktops what technologies to use. *You* plug into
> infrastructure, not vice versa.

Uups, we continue to plan and design interoperability layers. You missed 
the according technical discussion?

> Having stamina for a long run is simply not enough. Having nice
> architecture is not enough either. The only way to stop people
> wondering if a project is dead or alive is to arrange matters so that
> no sane person would ever have reasons to doubt. Of course if you

At the moment I see confronted with the repeated spreading of false 
statements about Oyranos and dependent projects.

Each time I adjusted the Oyranos library to meet expectations that was 
misused. There was no positive feedback. Just take it and bash again:
I created a ICC printing profile set to solve license demands.
Richard pushed fakes of these profiles to Fedora, while violating license 
terms. It took him half a year to show some minimum reaction. The faked 
profiles are still distributed.
Oyranos has the external Elektra dependency made optional. You seems not 
to accept that fact and provide as well not useful comment. 
The FTLK example was made optional to convince distributions to build 
Oyranos without having FLTK installed. FLTK is still misused as a argument 
against Oyranos. I have not observed any constructive hint, what else to 
do about.
A KDE Kolor Manager font was created. That appears to play no role 
regarding Oyranos relying on FLTK. Instead that project used to citicise 
its non distribution.

GCM was on many systems, which I checked, rather unrelyable. It showed 
wrong data, had a non working profile selection, crashed in certain 
situations and so on. Is this what you claim distributions want to get 
pushed in?

[my tests where made with Fedora13 and ubuntu 10.04, 10.10.]

In contrary Kolor-manager tries to provide a more robust experience. I 
guess thats about preferences and project goals.

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

[1] http://www.oyranos.org/scm?p=oyranos.git;a=blob;f=README;h=2a2256b6b8a663208150b6d8d296c3e3c9bf7260;hb=7586cdb1496e0ccf11211ed70eb9e651338121ca#l12
[2] http://oyranos.org/wiki/index.php?title=Oyranos_FAQ