group layers design

Gábor Lehel illissius at gmail.com
Sat Dec 24 12:00:57 CET 2005


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.


More information about the kimageshop mailing list