[Openicc] Fedora CM, was: Google Summer of Code . . .

[Chris Murphy]

I don't have an ample enough developer/programmer vocabulary to completely understand all of this. And further I have a very Mac OS centric view, so I don't thoroughly understand the Linux view which seems to be quite fractured. So if I say something totally ignorant, it's because I am, not because I'm being a dick. :-)

But, it would be nice if there were a way for all Linux distributions to agree upon some very basic things. Very basic for me is the creation of a default display profile (hopefully based on EDID if possible), and a way for applications to request it. That way developers don't need to create a display profile, find a place to save it independent of other applications, and users don't need to be bothered with finding and setting it themselves. It is the year 2010 after all, we're supposed to be heading to Jupiter for the 2nd time by now . . .

So this is the ignorant person's question, which is more of a culture question, maybe even a licensing one: is it not possible for distributions to agree on some extremely basic things, and get them in place in more than one distribution? For application developers and for users, the number one thing in color management that is constantly coming up for both of them is the setting and discovery of a display profile. If that could be automagical across many distributions, that would be huge. So what would it take to get agreement among the top distributions to enable this one thing in the same way?


Chris Murphy

On May 19, 2010, at 10:41 AM, Richard Hughes wrote:

> On 19 May 2010 16:18, Alexandre Prokoudine
> <alexandre.prokoudine at gmail.com> wrote:
>>> It would be unfortunate if there's independent development of the same basic
>>> structures going on.
>> 
>> This has already been discussed with Richard. He had his reasons not
>> to go for Oyranos. We were hoping to get him onboard at LGM to discuss
>> things again, but he won't be able to attend.
> 
> Sure, unfortunately not. I've maxed out my travel budget with GUADEC.
> 
> When starting with color management, I didn't choose Oyranos. I
> probably owe an explanation of that too. I rejected Oyranos for the
> following reasons:
> 
> * Mixing libelectra into the public API, which no distro ships by
> default, and upstream is dead
> * Linking to odd things like libXNVCtrl
> * Deadly mix of xforms and fltk, mixing in the UI with the backend
> with no clear separation betwixt the two
> * Mixing in UI toolkit, CMS and low level glibc style library leading
> to API like oyWIDGET_e and void oyTextsTranslate_ (void);
> * Oyranos has it's own memory allocation framework and string
> processing utilities
> * Putting the image processing integration points themselves (lcms,
> libraw, etc) in the CMS, rather than in the application or toolkit
> * Reliance on compiz for full screen color management
> * Oyranos has it's own type and object system oyOBJECT_e, which simply
> blows my mind
> 
> So, Oyranos tries to (in my opinion) to be a "thick solution" where it
> tries to do all of the pieces of a color managed solution. GPM is a
> "thin solution" where it defers to the application the pixbuf
> transforming (using something like lcms, or cairo in the future) and
> only providing a simple UI and minimalist DBus interface for
> interested applications to query. Biased completely, but I think most
> of the CMS functionality can be (and should be) integrated into the
> platform, e.g. GTK and Cairo.
> 
> I'm also a strong believer that it's best to have two different
> applications for something that share a common spec, rather than
> trying to be a jack-of-all-trades. It's a cliché, but KDE users do
> want options, and GNOME users do want things to 'just work'. You can't
> design a library, or even an application for those different user
> types.
> 
> I appreciate people have different opinions to me, but in my humble
> opinion a shared DBus specification is much more interesting to me
> than a framework that isn't installed on any distribution by default.
> 
> Richard.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc