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

[Richard Hughes]

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.