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

[Kai-Uwe Behrmann]

Am 20.05.10, 07:53 +0100 schrieb 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.

There are well known distributions, which allow to install Elektra through 
their default repositories. It is good to know that other opens their 
books for Elektra.

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

Because Oyranos has a very generic approach to data. The core does not 
know that it handles colours. However it has to maintain rules, translate
messages and enforce policies on request. The hard colour math is done by 
a CMM everything else are convenient layers for the sake of easier
application writing. When things are hardcoded it is perhaps easier to 
have the according UI and functionality separated. That would be 
combersome with the degree of flexibility in Oyranos.

So you might look with a very specific asset of question at Oyranos. But 
others may have other questions, which we still seek to answere.

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

You iterate again and again over this offtoppic detail of some example 
code in the Oyranos sources. The examples could have been KDE, Gnome, 
FLTK, CLI or something else. No problem.

I do not know any distro without FLTK packages in their default 
repositories.

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

"flawed" reads in german ...
CM integration in Xorg, GTK, Cairo and so on is fine. Chris' questions 
came up as he had read that you want to work on CM preferences, device 
detection and configuration and integration into the toolkit (Gtk). This 
sounds exactly like CMS work. And as long as we have no other and better 
term this one will easily be used.

If you feel more at home around the OpenICC project as an effort to 
integrate CM into Linux - why not?

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

That option is not yet added, as long as a second CMM is not yet plugged 
into the CMS.

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

Interessting. I have drafted the net-color spec v0.2. Lets see how 
they can fit. My part will go into an other email on list.

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

Qt is rather large for a CMS and in C++. GObject seems far from being 
easily debuggable. In contrast the used object system is relatively 
lightwight and very well debuggable with standard means.

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

Fine, this would be better handled in a separate thread.

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

Naming and their translations are hard to keep in sync. Do you 
have some special project in mind, where it happens that different 
projects use the same names for the same thing?

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

Lets see how this can be made useful.


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