[Openicc] Helping with colord

[Kai-Uwe Behrmann]

Am 08.03.11, 20:35 +0300 schrieb Alexandre Prokoudine:
> On 3/8/11, Kai-Uwe Behrmann wrote:
>> 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.
>
> *sigh*
>
> That's another popular misconception. You don't make a successful
> project by going around and convincing people. You arrange matters in
> a way that *they* come to you and drool at your doorstep begging and
> wagging their tails.
>
>> Any distributions can ship Oyranos already for that.
>
> Any distribution that wants extra work, because packaging Oyranos and
> related apps is reportedly PITA.

I did not read complaints recently about that.

> Did you ever wonder why the only distribution that ships Oyranos is
> made by *you* and available only via susestudio?

Wrong again. The CD is available on SourceForge.

>>> 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.
>
> For how long is it sitting there? I know the answer, but I'd like
> *you* to say that.
>
>>> 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.
>
> Few things are easy

This says exactly what?

>>> 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.
>
> However the default configuration tool is nowhere close to being OK
> for either GNOME or KDE, and exactly how much useful is Oyranos
> without a configuration front-end?

This is a comparision of apples and oranges. Kolor Manager designed to 
integrate into KDE. That is compareable to GCM.

Oyranos is useful as its Xorg device setup is completly automatic. Thus
CompICC and all other dependent apps do not use any UI for the Xorg ICC 
profile.

>> The same on Elektra. It is not externaly needed in order to build Oyranos.
>
> Yes, since how long? I'll tell you: end of September *2010*. When was
> G-C-M started? End of November *2009*, AFAIK. And when was KM written?
> So your point is...?
>
>> Compared, can colord be build without a sql data base? I guess no.
>
> I wonder if you are up to date regarding modern desktops. Both KDE and

The desktop is one important part in the design of Oyranos. However its 
not the only one. So your argument is misplaced.

> GNOME rely on SQL because of the thing called semantic desktop (not
> mentioning music players shipped by default), and sqlite is available
> in virtually any Linux distribution whose developer isn't some sort of
> geek who needs only console and ratposion-like WM configured via text
> files in nano.

You compare apples with oranges again. I suggest we exchange arguments 
about that matter in the according thread. This will give a slightly 
chance that all parties have read more than just blurry ideas about 
desktops.

>> 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.
>
> I never said that.

Yes, you purely complained about what Oyranos uses without providing any 
suggestion.

>> I am highly depressed about Richards and your repeatedly wrong statements.
>> It causes real damage.
>
> The fact that they are repeatedly right should make you even more
> depressed, I'm afraid.

My personal impression is you act upon a maxim alike:
"Alexandre is infallible and always right."

>> Instead we need here contructiveness, fairness, to honour each other and
>> keep the truth enabled.
>
> How about following your own advices then? You overreact to every
> single statement I make as if I was some sort of enemy.

I did not select any enemy here. Instead I am very welcoming to people. I 
am really sorry about how the statement exchange went.

>>> 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?
>
> Yes, I'm quite missing a KDE representative round here. I mean, does KDE know?

Uch, no one from KDE here? Do you read the names of the posters.

>>> 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.
>
> No statement of mine has proven to be false so far. But the fact that

It seems you are intangible.

> you keep insisting on the opposite makes me wonder how long you can
> keep going that way. This isn't even funny.

I reacted to several suggetions positively including from you.

>> 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.
>
> You are missing the little detail called timing and how it influents
> design decisions. You know -- things happening first, things happening
> next? That sort of thing. Or do I have to remind you which happened
> first -- the aforementioned epic elektra thread or shipping local copy
> of elektra with Oyranos as, presumably, result of it? Do I have to say
> how exactly much time it took you to solve this? I can spread facts
> with a shovel, just say the word.

Timing needs order of time. Sorry I did not see that in your previous
argumentations. If you would include that as a context like above it might 
be easier to get your points earlier.

Oyranos has no external Elektra dependency since one of the last releases.
Is was in the annoucement. What else to say here?

>> 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.
>
> Because there is no other configuration tool for Oyranos that would be
> ok for either of existing desktops. All we have is KM not being used

Hmm, and colord has a KDE front end already? I guess thats a apples and 
oranges comparision again.

> upstream and a new project that has zero pushes in git repo as of this
> morning.

It was just an annoucement of a new project. I am pretty sure it will be 
much more relyable than GCM today once it is released.

>> I have not observed any constructive hint
>
> Observation is an effort. You are not making it. But then you do a
> very reasonable overreaction at barely any price, so it's bargain :)
>
>> A KDE Kolor Manager font was created.
>
> A font?

Sorry a typo.It should read "A KDE Kolor Manager front end was created."

>> 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.]
>
> 10.04, GCM 2.30, never crashed, never shown incorrect data (apart from
> weird loooking description tag generated by early releases). Granted,
> no software is bugfree. Did you log any reports into bugzilla, or is

Display a Cmyk profile in GCM 2.30.0-ubuntu3 and GCM crashes. Thats on 
10.04.

> it a rhetoric question? Likewise, what bug tracker are Oyranos, KM and

A top link on http://www.oyranos.org points now to "Support".

> Cinepaint users supposed to use?

I am not a member of the CinePaint team. I am not part of the official 
project. Please refere to their web site, mailing lists and usual places.

If you have questions around my patches, best contact me offlist or if it 
must be made public, use one of the Oyranos bug trackers. As my focus is 
mosty on colour management there and some few compile and bug fixes. Thats 
typical as with any distributor repository. Btw. openSUSE has the 
identical set of patches applied.

> I don't quite understand where we are heading to with this thread,
> especially with topic starter gone.

You had your questionable job fullfilled.

> Alexandre Prokoudine
> http://libregraphicsworld.org

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