New color conversion system

[Cyrille Berger]

> > Or in other words, could you turn you shoes slightly to direct to
> > simple C.
>
> That would be pretty hard. We rely a lot on templates to make sure we only
> have the bare minimum of essential work when adding a new colorspace.

Yes on the other hand, a C wrapper would be really easy to do. As, the API for 
use in applications is not using hardcore advanced C++ features. (As for 
templates, they are just code generator, you know, any type of code generator 
could be used instead, it's just templates are integrated in C++). As for 
switching the whole library from C++ to C, it is out of question, it would be 
a complete rewrite, and I doubt we have the man power (I know I can't help, I 
don't know how to code in C).

> > I expect it would more easily fit in a open source CMM framework.
> > A floating point CMM together with lcms and argyll's libicc would be
> > cool.
> >
> > If you plan only for KDE so be it.
>
> It would probably not be too hard to make Pigment plain standard C++ by
> replacing the Qt dependencies with the STL, but we'd need a pretty strong
> reason to go that extra mile, like actual help and user applications. After
> all, we're short-handed, like every project on this earth :-)
On the other hand pigment could probably made to only requires QtCore (it 
currently uses QImage which is in QtGUI, but that could be changed without 
too much work). I wish people stop complaining about this. Do we complain 
about one of the library used by Krita depending on glib ? (or even GTK on 
Debian, but on that point, I did complain, so...) I could see it as a problem 
if the library was depending on the whole Qt4 Framework ! People have to 
remember now that Qt4 is splited in small package.

-- 
Cyrille Berger