[Openicc] libcmwidgetcore (working title) [was: List Scope]

[Stefan Döhla]

>>>>
>>>
>>> Beside a gamut hull display, would'nt it make sense to keep the
>>> remainder in one core project? I am not shure how much work it  
>>> would be to
>>> wrap a application like ICC Examin into several toolkit cloats.
>> Well that's clearly how I see it :
>> oyranos => library for CM settings
>> libcmwidgetcore => toolkit independent base for creating CM widgets
>> libcmqt => Qt Widgets
>> libcmgtk => Gtk Widgets
>> libcm... => ... Widgets
>
> That scheme looks good.
> As the last years candidate for that GSoC project could not start,  
> because
> of the limited number of accepted projects, there is quite some work  
> to
> do.
>
> A first API draft would help with the split.
>
I'm just thinking about this and I don't see the difference in between  
oyranos and the configuration currently. I've not really looked into  
oyranos but what about the following:

(1) define a config file format (e.g. the oyranos-internal one) with  
the low-level things as a "freedesktop" standard for color-management  
configuration on Linux-like operating systems
(2) provide an API to it (namely oyranos) which supports the low-level  
calls (preferably C, not C++ for maximum interoperability) - but it  
doesn't matter
(3) promote this to the desktop environment communityand supply them  
with the widgets already made so that they can include it within their  
configuration systems (oyranos+oyranos-widgets)

A standard (=> (1) ) is always about 'interoperability' - such an  
approach allows you have competing systems all fideling around with  
the color config file (which is standardized) - just if they don't  
want to use oyranos for one ot the other reason - e.g. no C++). And  
oyranos could be the one library which is always conforming to the  
standard and is therefore attractive to developers. Defining the  
standard would exactly be the scope of this list.

Oh, and by the way: I'm in favour of a config file rather than any  
desktop-environment specific configuration system. Because what would  
you do on a print server that does not run X11/Qt/GTK/Fltk/Gnome/ 
KDE/... but lcms?

Just my 2cents
- Stefan