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

[Richard Hughes]

On 19 May 2010 19:09, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Elektra is pretty alive and under development:

No, Elekra is dead. Last stable release was two years ago. The IRC
channel is empty, and the mailing list is averaging less than an email
a month. No distro (to my knowledge) ships the library by default in
either the community or supported version. I don't know any other
project, other than Oyranos that requires Elektra as a hard
dependency. That qualifies as dead in my book.

> Elektra has much influenced Oyranos core design.

Right, and this is my issue.

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

That's really not the point. It might only require libc to run, but if
nothing is using it, and it failed to be accepted by other software
projects then it's kinda a non-issue.

> The oforms subset of XFORMS is well separated. modules pass only strings
> around to layout their data.

Why is data being mixed with UI?

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

Out of interest, what distros ship (and support) FLTK by default?

> Is'nt a full blown Gnome CMS and a KDE CMS redundant?

Sure, I think the concept of a "CMS" is flawed. Color management has
to be integral to the stack, so Xorg, GTK, Cairo, etc all have to play
their part. You can't really push a monolithic library when you need
to interface with so many parts of the stack. I see g-p-m as a the
cherry on a cake, with all the heavy lifting being done by cairo, lcms
and argyll. GPM just provides the configuration widgets in the session
and makes the data available to applications.

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

If you want to "swap" a CMM then I think you're doing it wrong. I
think it makes sense to swap out lcms to some proprietary system if
required, but this needs to be a preference in the session with hooks
in the toolkit.

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

Sure, I'm currently looking at adding the required hooks in mutter, or
maybe the xserver itself.

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

It's already been solved. You shouldn't be inventing the wheel. Just
use GObject and Gio. If you want to use C++, use Qt. I'm not sure what
an object system has to do with a CMS. From a 40,000ft view an
application just wants to transform an image to make the colors
different. I'm not sure where the requirement for an object system
fits into that use case.

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

Sure, I'm open to naming discussions, as I agree this is a source of confusion.

> From a toolkit point of view thats correct. From a CMS point of view its
> problematic. It has many advantages to name things consequently including
> their translations. Thats why I suggest to let the UI be part of the CMS
> (and further a common one).

I don't think nomenclature is a good argument for not having a good
logical split between components.

> If your DBus conventin could be easily supportable through Elektra and
> applications really want DBus, why not?

Sure, see my other mail. It would be great to standardize on an
interface, even if we disagree on code. :-)

Richard.