[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    PaintDevice/Layer/Mask/Selection/Overlay
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2007-05-14 20:26:50
Message-ID: 200705142226.52771.boud () valdyas ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Here's the datamodel I am trying to implement for the mask/selection/overlay 
design. Because all layers now can have modifications, all layers have a 
projection.

I am assuming that painterly overlays are only useful for paint layers. 
Thrain: am I correct in that assumption?

Let's first map the generation of the projection for the various types of 
layers:

Paint Layer

paint device -> overlays -> effect masks -> projection

Shapes Layer

shapes -> canvas paint device -> effect masks -> projection

Group Layer

layers -> composition -> projection 1 -> effect masks -> projection 2

Adjustment Layer

projection of the stack under the adj layer -> filter -> projection


So, I'm right now implementing the following class model:

KisLayer {
	KisPaintDeviceSP projection
	QList<KisMask> effectMasks
}

KisPaintLayer::KisLayer {
	KisPaintDevice canvas
	QList<KistMask> painterlyOverlays
}

KisShapeLayer::KisLayer {
	KisPaintDevice canvas
	KoShapeManager shapeManager
}

KisGroupLayer::KisLayer {
	KisPaintDevice projection
	QList<KisLayer> layers
}

KisAdjustmentLayer::KisLayer {
	KisMaskSP mask
	KisFilter filter
}


Two complications:

* KisAdjustmentLayer shouldn't have effect masks, that's silly.
* The optimization where if there's only one layer and no effect masks, that 
layer is also the projection of the owning group layer should be kept

Design problem:

* I want to make this as generic as possible: so, for composition, 
thumbnailing etc. we should always be able to call KisLayer::projection(), 
for painting we should be able to call KisLayer::canvas() -- which returns 
the mask in the case of an adj. layer, the canvas in the case of a paint 
layer and nothing in the case of other layer types.

* Masks and overlays can have several types of representation: a visible one 
(like the red or blue editing mask) and an effect one (like, well, like adj. 
layers now). So maybe also a method to toggle the showing of the mask and a 
method to get the current mask. This needs to be integrated with the layer 
box, so the mask is shown as a mask and not an effect when the mask is not 
selected in the layerbox.

Selections:

Right now the selection is part of KisPaintDevice. We have agreed on having 
more than one selection type per layer: namely one that determines reading 
and one that determines writing, and one that determines both. That means 
three KisSelectionSP's on the paint device, unless we go a KisSelection with 
three channels, of course.


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

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]