Failing unittests

[Cyrille Berger]

> KRITA/IMAGE
>
> 5 - krita-image-KisPaintDeviceTest (Failed)
>
> - testColorSpaceConversion: new failure, due to changes in pigment:
> ASSERT: "dynamic_cast<const KoLcmsInfo*>(srcColorSpace())" in
> file /home/boud/kde/src/koffice/libs/pigment/KoLcmsColorSpace.cpp, line 38
Outch this is a bad one. Not sure, yet, about the best way to fix that.

Lets me explain, if you look at the code this ASSERT _can't_ fail (and yet it 
does :( ), only a KoLcmsColorSpace creates a 
KoLcmsColorConversionTransformation, and it allways gives himself as argument 
to the source colorspace, which means "srcColorSpace()" is allways a 
KoLcmsColorSpace, and allways inherits KoLcmsInfo, and so is allways castable 
to KoLcmsInfo.

But still the assert fails. I have a possible explanation for that, 
KoLcmsColorSpace is a template class, that means that while the source code 
is in pigment, the binary code is wherever the class is instantiate, that 
means in the colorspace plugins. And the problem is that RTTI doesn't work 
well when used with dlopen.

I see a couple of solutions, but none please me,
- add a KoColorSpaceInfo class and add a function in KoColorSpace to return a 
KoColorSpaceInfo that could be inherited by KoColorSpaceLcmsInfo, as it 
wouldn't be templated, the symbols would be available in pigment library and 
there should be no RTTI problem
- use RTLD_GLOBAL when calling dlopen, not sure wether it is possible in the 
KDE plugin system, and it's a little bit problematic, as with RTLD_GLOBAL the 
symbols of a plugins are exposed to other plugins, which might be a problem 
if two plugins use the same symbol

There might be a cleaner solution with the new system for color conversion, 
but it's not very clear in my mind, and I was hopping to shortcut the new 
system when converting color between two LCMS colorspace, but it might not be 
that possible :/

-- 
Cyrille Berger