Hm. About code separation.

[Boudewijn Rempt]

I had started before I went on holidays to move all color strategies to 
plugins. This, I hoped, would force us to keep all color strategies 
independent of each other, and would make it easier to extend Krita with new 
strategies.

Unfortunately, this now appears to be quite hard to do, since even the tile 
manager links to colour-strategy related stuff, and most colour strategies 
needed to link to the rgb strategy.

However, I think that that's wrong, and I'll try to untangle the situation 
tonight. The tile manager should store bytes and know nothing, absolutely 
nothing, about the nature of the bytes stored, except for the number of bytes 
that makes up a pixel. So no dependencies on anything from 
core/color_strategy.

Color strategies can use an external class to convert, probably via lab or xyz 
-- that needs a bit of research, and possible, once we're further along, 
sometimes directly. For now they should use koColor. No sense in 
re-implementing an already bad algorithm again, and especially no sense in 
using rgb as an intermediate format. I won't be able to fix this today, but 
it's a firm decision.

Then, factoring out composite operations into a separate lib sounds nice in 
practice, but it just means scattering stuff that belongs inside a color 
strategy in two different places, and throwing together stuff from different 
color strategies in one place. The solution for the problem compositeop tries 
to solve (and which I had tried to solve in an abolutely similar way with the 
capability mediator), lies in having the colour strategy present to the UI a 
list of composite ops it supports, and keep those ops inside the colour 
strategy. This is also something I intend to fix this week, deo volente.

But the first thing is to untangle the colour information from the tile 
manager.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi