Hm. About code separation.
boud at valdyas.org
Tue Jul 27 21:14:51 CEST 2004
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
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
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
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi
More information about the kimageshop