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

[Kai-Uwe Behrmann]

Am 31.01.08, 02:39 +0100 schrieb 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  

Indeed the last Oyranos release contains almost only configuration stuff. 
It is C with C++ namespacing and the only dependency is Elektra a low 
level C library as well.

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

In principle this sounds good. But ...

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

Consistency:
This will easily bring confusion. We see applications with an unified 
colour management and even there it is difficult to keep colour paths 
always consistent. Look around.

Moving specs:
We have already revised some of our previous agreements. A libary API can 
possibly better hide this. A library can even provide features some 
application developers would not even think about. In other words, what 
most people want is colour management with the possibility to opt out, not 
the other way around.

Resources:
the Create project has several people working on standards drafts. Things 
are moving sometimes slowly. At least there are several people involved in 
this.
Here, with the one exception of Ross Burton for jumping into the X11 
configuration, are not that many prople involved in writing and 
implementing. In practise this would be me to specify the evolving Oyranos 
implementation. For good practise I have featurewise ideas and sketched 
some ideas of a system. Probably I could turn this material into a 
lecture, not shure.

As long as no one says a certain detail in Oyranos has to be changed, 
which would require to look at the API documentation or signals 
interesst in the implementation, or someone comes with a concrete proposal 
on how something should work, I would rather reject to start additional 
work. Defining a good API with appropriate examples and useful 
documentation is currently my primary goal.

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

No worry. Oyranos has no desktop specifics. 
Oyranos is low level - C.

Dependencies like X11, osX , Win32 calls will be wrapped into separate 
libraries with the help of dlopen().


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