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

[Stefan Döhla]

Am 31.01.2008 um 07:32 schrieb Kai-Uwe Behrmann:
>
>
>> 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.

They had their very good reasons (e.g. the Windows ICM being unusable  
although it's available).

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

Right, changes are a problem. Nevertheless, the file format will  
probably stay pretty consistent - since the "convenience" functions  
will probably change more often than a configuration file with a  
rather limited syntax (which can be defined being extensible, e.g. XML).

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

Continue your good work here. Nevertheless the question remains where  
the 'interoperability point' should be so that we are set for the  
future, don't need to change much and at the same time be able to  
promote this to the desktop environment / application programmers.

If people start implementing the new oyranos configuration-only thing  
then the specification to be made is irrelevant to them but can be  
attractive for others that like to do other things than what oyranos  
provides in the future.

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

My comment was little bit related to someone suggesting the KDE  
configuration system. My opinion is: these systems come and go with  
every new major version of a desktop environment and are rarely shared  
between them. Things using config files did so many years ago and  
still do.

- Stefan