Layer tree model

[Boudewijn Rempt]

On Friday 23 March 2007, Schleimer, Ben wrote:
> Hey Boud,
>
> > * layers need to be able to access their parents
>
> Absolutely.
>
> > * layers need to be able to access their siblings
>
> Layers don't necessarily need to track their siblings. 

But if we keep the model inside the layers, then it's easy enough to keep, 
isn't it?

> It might be better 
> for a layer to be able ask its parent to accept a compositing visitor to
> all of the children following the requesting layer.

Hm, that would also help with my dirty-marking problem. Right now I mark rects 
in layers dirty, but I only use that to see at which adjustment layer's 
projection I can start recompositing.

> The Parent would need 
> to decide which of the children follow the layer and apply the visitor but
> it would eliminate the need for maintaining sibling pointers.
>
> > * groups need to know their children
>
> Here's a thought: Let all KisLayers have children and use constraint rules
> in the datamodel to determine when it's valid to add a layer as a child to
> another layer. Then KisMaskLayer and KisSelectionLayer can be a subclass of
> KisPaintLayer. Add a constraint rule that says only KisPaintLayers can have
> KisMaskLayers or KisSelectionLayers as children and that a KisPaintLayer
> can only have one KisSelectionLayer.

I'm not sure whether we should make masks and selections full-blown layers -- 
they are now a special kind of paint devices (there's already a little code 
in trunk for that), but in general I agree: merging KisLayer and 
KisGroupLayer and handling what is what with constraints makes sense, 
especially code-wise.

> UML is designed by using similar contraint rules and I've found that they
> are a lot easier and more flexible to use for arbitrary tree structures.
>
> > * Keep the hierarchy administration inside KisGroupLayer and KisLayer.
> > Access only through KisImage. Keep the external KisLayerModel updated
> > from KisLayer.
>
> I agree with Cyrillebhere and say that the data should be separated from
> the model interface.
> http://doc.trolltech.com/4.3/itemviews-simpletreemodel.html seems like it's
> pretty similar situation (simplier of course) to the layer system.

Ok. I was getting confused by the need to call the model both before and after 
rows get inserted, removed or moved, but that can be handled anyway.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20070323/0521a82e/attachment.pgp