[Openicc] Helping with colord

[Kai-Uwe Behrmann]

Am 09.03.11, 17:07 +0300 schrieb Alexandre Prokoudine:
> On Wed, Mar 9, 2011 at 4:30 AM, Graeme Gill wrote:
>
>> It's a perfectly valid argument, because it reflects reality. People
>> can't work full time on things unless they have some means of paying
>> their way in life.
>
> Graeme, with all respect due to Cinepaint "team", not releasing a
> v0.25 (with 0.23 and 0.24 buried) in several *years*, while
> defensively talking of patches submitted, as well as of how unique and
> robust Cinepaint is, sounds very much like BS. What sort of full time
> work could possibly be even remotely involved?
>
> I finally got to broadband and cloned git repo. Well, guess what -- it
> starts in July last year with mentioning a 0.25 tarball, but do you
> know where it is available? *Only* in at https://build.opensuse.org
> and few mirrors, presumably -- to be able to build a custom susestudio
> distro (which I have around thanks to Kai-Uwe). This tarball is not
> available anywhere *else*. It wasn't announced anywhere except [1],
> and even then -- only as intention and almost two years before the
> beginning of the Git repo. In the former Cinepaint blog Robin just
> skipped the whole thing after [1] talking of anything but final
> release. How is it possibly a good releasing practice? How is it an
> example of good communication between developers and users? How is it
> remotely related to full-time employment?
>
> http://cinepaint.blogspot.com/2008/10/preparations-for-0250-release.html

I am still subscribed to cinepaint-user, if you care to get something 
around that done.

>>> Do you know when Cinepaint's source code was officially released last?
>>> Have a look yourself:
>>
>> I think it's a bit odd that you are bringing up slow Cinepaint development
>> is an argument against as Oyranos.
>
> Especially since I don't :) Richard's question was whether Cinepaint
> was dead or alive. Remember?
>
>>> This has already been discussed in the epic elektra thread. Do you see
>>> any point getting back and starting it all over again?
>>
>> Assuming Oyranos doesn't have a hard dependence on Elektra anymore (and I
>> have no reason to doubt Kai-Uwe's statement on that), then what is the
>> current relevance ?
>
> As far as I can tell, no hard dependency in this case means a minimal
> local copy of Elektra, statically compiled with Oyranos. And it also

Without code no functions.

> means that by the time it happened, design decision for GNOME had
> already been made. I really don't understand why after repeatedly
> mentioning the timing this question keeps popping up.

The issue was about cross desktop configuration storage for colour 
management. gconf and kconfig are still not much helpful for usability 
reasons. Thats confirmed and not even questioned by any CMS data base 
discussion here on list.

libxml2 would have been distribution wise and political a no brainer. 
However libxml2 is techical not as easy as Richard pointed recently out 
in his comparision.

>>> Do you want to see what happens when you go for a perfect architecture
>>> instead of starting small and progressing step by step? Visit
>>> lumiera.org. Excellent idea, shot in the head by overdesign. After
>>> three years there are still no downloads, because there is nothing to
>>> download. Not even an alpha is available. Do I want the only viable
>>> desktop integrated color management app be shot in the head likewise?
>>> Hell, no.
>>
>> I don't quite see the relevance. You certainly can't claim that
>> Oyranos is some paper design.
>>
>>> Back when we started OpenICC, the idea was to agree on concepts, work
>>> out common solutions and then bloody well get things done. I love the
>>> fact that we have best experts in CM here, as well as both proprietary
>>> and free software developers and hardware vendor engineers. I love the
>>> fact that I learnt tons of stuff. But it's been, how many -- four?
>>> five? -- years since then, and the question I'm asking is: are we
>>> getting things done?
>>
>> Apparently not a lot. But there has to be some willingness to work
>> towards common goals, and take into consideration others legitimate
>> requirements. While Richard Hughes has made admirable progress with
>> GCM, he's not shown a lot of willingness so far to compromise
>> the "get my project working in the most efficient GNOME/Red Hat way
>> possible",
>> in order to actually establish some basic system color management
>> standards, such as how profile & device associations are stored.
>>
>> I'm certainly willing to make ArgyllCMS work with a standard that
>> can be agreed by the various interested parties, and I get the impression
>> that Kai-Uwe might be willing to change Oyranos to work with a standard,
>> but I'm not getting the impression at the moment that Richard is willing.
>>
>> If we could get that at least done (including sample code), then we could
>> start arguing about what's stored in it, and after that there may even be
>> scope to specify a system CMM api or even implement it based on
>> Oyranos/GCM/lcms2/Ghostscript code!
>
> This is what I very much hope will happen :)

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