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

[Kai-Uwe Behrmann]

Am 19.05.10, 17:41 +0100 schrieb 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

Elektra is pretty alive and under development:
http://www.linuxwochen.at/index.php?option=com_content&view=article&id=135&Itemid=69
Oyranos is often criticised for using Elektra not only by you. So I 
may suggest my rationale behind choosing that library. Elektra has much 
influenced Oyranos core design. It is very flexible. It supports 
different DB exchange formats and mechanims and these formats are even 
extentable. It does not depend on a single toolkit. Its pretty self 
contained - ok libxml2 and iconv belong to the dependencies, but that was 
always suggested as no problem and is few. Elektra is highly portable. I 
was very impressed by this spirit. And many unix applications and core 
libraries share this one. I would not consider to rewrite that stuff. You 
have shurely some of the features available through your underpinnings, 
but all?


libXNVCtrl is included for a separate convenience tool for Nvidia 
configuration. Take it as a own project. Its just bundled.

The oforms subset of XFORMS is well separated. modules pass only strings 
around to layout their data. The FLTK part is just a layouted view of some
data model. The CLI interface renders the same data of course different.
Gtk and Qt views can be implemented.

The UI types you describe are from the first generation of Oyranos. UI 
handling has moved to the above mentioned XFORMS subset. I should remove 
that elder APIs if no existing package breaks. Thanks for pointing out.

Is'nt a full blown Gnome CMS and a KDE CMS redundant? This does not touch 
your work on the UI level with Argyll integration and what you plan with 
Gtk.

There is interesst in exchanging CMMs. Ok, its work to provide the 
underpinnings.

Compiz is currently the only way to real colour render the desktop. Come 
up with something working. And if you take on this project, please 
instegrated it in Xorg itself. For Oyranos its optional.
It could be a separate project.

Hints about a debuggable and flexible object systems in C are really
welcome, especially now.

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

May impression is that beside working specs, which need as well some 
implementation, a well designed CMS library could serve as a good 
integration point. Most users, who care about CM, want simply consistency 
of their colours and a repeatable way how to get there. They do not want a 
KDE + a Gnome learning curve. Big vendors regularily took CM out of the OS 
to provide a consistence UI experience. It may be not easy to get the 
balance. But when I look at the various CM UIs in the apps - thats more or 
less chaos. One common set of UI options would be of great help. I tried 
to provide that with the Oyranos examples UI.
It would be great if we can settle on a common options set to present in 
the UI to users. This includes names, their meaning, their translation and 
perhaps some logical order or layout. The later only vaguely. Many people 
simple take every single and are irritated by different naming.

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