[Openicc] Helping with colord

[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.

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

>> 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

>> 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?

> 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
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.

> 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.

> 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.

> 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.

>> 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?

>> 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
you keep insisting on the opposite makes me wonder how long you can
keep going that way. This isn't even funny.

> 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.

> 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
upstream and a new project that has zero pushes in git repo as of this
morning.

> 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?

> 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
it a rhetoric question? Likewise, what bug tracker are Oyranos, KM and
Cinepaint users supposed to use?

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

Alexandre Prokoudine
http://libregraphicsworld.org