Kismet

[Boudewijn Rempt]

On Monday 08 March 2004 13:07, Patrick Julien wrote:

> True, but this is not how I want to use them.  Here, I just wanted a small
> info structure to be defined and initialized once.  Then, you simply
> iterate over the array of structures to fill in the gaps.

Well, it was why I started designing this bit of code :-). And even if this is 
not the answer, these points (spreading functionality that belongs to an 
image type all over the place, connecting code to the ui, extensibility) are 
things that should be solved -- so why not by having a rich ImageType class.

> I don't think it should no, the image type depth should be determined by
> the image.

Not the image as such, but rather the paint device -- i.e., the layer. Having 
the restriction that all layers should be the same image type is not really 
necessary, and will make some things more difficult later on. And then, not 
all colour strategies will be able to work with all bit depths either.

>
> I don't think the supported image types should be a member of the color
> strategy, no.  Or am I not understanding what you are saying here?
>

How about this: the ImageType -- which is an attribute of KisPaintDevice, 
while KisImage has a only default ImageType, but can contain layers of 
different ImageTypes -- defines one colour strategy and a list of supported 
bit depths. 

> Having a middle class with the setters allows you to expose to getters
> without the setter methods... i.e. KisImageType would no longer any members
> or setters, only getters.

Okay.

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