group layers design

[Casper Boemann]

Hi

Just some of my thoughts on this and related subjects.

Whenever we invent a new VWLT we need to update the layerbox accordingly. I 
cant really imagine that we would be able to design a ui that will be able 
to handle anything. PaintLayers need to show the mask and preview. 
GroupLayers need to show the children, and so on. TextLayers should if not 
just a partlayer show something else, and AdjustmentLayers too.

So for me I don't really se how we can avoid hardcoding. Unless we make a 
ui/LayerBoxLayerUI class that every KisLayer can be associated with. It 
would however have the same problem that Gábor wrote about for GroupLayer in 
particular.

So for this reason I don't think making KisLayer absorb KisGroupLayer would 
be the right solution. Sure it could solve the group problem. But then comes 
the next layer type and we need to absorb that as well.

This actually only leaves the first solution, which is more or less like we 
have right now. Using dynamic casts.

Btw layerbox is not the only one with this problem. Soon we need to fix 
saving and ones again we need to tackle this subject. My intention was/is to 
make a visitor but that hardcodes the types of layers. Unlike colorspaces 
saving needs to be different for each type of layer. So short of putting 
saving into the layer itself we again have not much choice.

If you get the impression that I advocate hardcoding layertypes (ie not as 
plugins) then you are right. With visitors we have the framework to easily 
add new layertypes in future versions of krita, but not as plugins.

Now layerbox could use a visitor too to populate the layerbox, but I 
anticipate that this is not enough for manipulating and updating. A 
LayerBoxXXXItem class for each layer type could be part of the answer to 
that.

----- Original Message ----- 
From: "Gábor Lehel" <illissius at gmail.com>
To: <kimageshop at kde.org>
Sent: Saturday, December 24, 2005 12:00 PM
Subject: group layers design


> Hi all,
> I've been thinking about how the group layers should be designed. The
> question is basically how much of the functionality to put into
> KisLayer, and how much into KisGroupLayer. At one extreme,
> QListViewItem has no concept of 'plain items' vs 'group items' --
> every item can have children, just not all actually do. That doesn't
> quite work in Krita's case, as a KisPaintLayer with child layers
> doesn't make much sense. At the other end, any time you have a
> KisLayer want to deal with child layers, you would have to
> dynamic_cast to KisGroupLayer, and the only possible way for a layer
> to have child layers would be by inheriting KisGroupLayer.
>
> There's the following issues I can think of at the moment:
> - Say someone wants to create a Very Weird Layer Type (VWLT), that has
> child layers, but does something new and funky with them, instead of
> just compositing them together. How do we make this possible?
>
> - KisLayer has methods prevSibling() and nextSibling() -- I think it'd
> be excessive and inefficient (and require housekeeping to keep it all
> consistent) to have m_prevSibling and m_nexSibling to store these,
> when you could just find out via the parent(); but this needs parent()
> to be of a type that's guarenteed to have the info (either m_layers
> accessible, or KisLayerSP itemAtIndex(int i) / int
> indexOfItem(KisLayerSP), or something of the sort).
>
> - Having just a KisLayer, not knowing whether it supports child
> layers, and then finding out and adding some needs to be handled
> somehow, and also which part of the code we force to do the checking.
>
> And I can see the following options:
> - Only KisGroupLayers can have child layers; this means no
> add/removeLayer() methods in KisLayer. If you have a KisLayer and want
> to add sublayers, you have to dynamic_cast. parent()s of layers are
> forced/guarenteed to be KisGroupLayers. If you want to make a VWLT,
> inherit from KisGroupLayer -- perhaps KisGroupLayer and anything else
> inheriting directly from KisLayer should do so virtually, so if
> someone wants to inherit from multiple layer types, it doesn't get
> really very ugly. Minus the last part, this is more or less what's in
> the code now, but it can still be changed without too much of an
> effort. Which part of the code has to do the dynamic_casts to
> KisGroupLayer and which can just pass in KisLayers is a bit ambiguous
> though.
>
> - Have virtual bool add/removeLayer() in KisLayer, which merely return
> false. If you have a KisLayer of unknown type and want to add child
> layers, just call the the methods and trust it to do the right thing.
> For a VWLT, you can inherit from plain KisLayer.
>
> - As above, except also have virtual bool supportsChildLayers(), which
> you can check before adding child layers.
>
> - Obsolete the concept of KisGroupLayer and move it into KisLayer;
> have KisLayer::supportsChildLayers() return true and add/removeLayer()
> actually do so, have KisPaintLayer et al override
> supportsChildLayers() to return false, and check supportsChildLayers()
> before adding child layers to anything.
>
> There are probably more issues and options; if I saw the whole
> situation clearly I probably wouldn't be writing this mail but
> would've chosen one already.
> _______________________________________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>