Proposal for Clone layers.

[Boudewijn Rempt]

On Sunday 15 May 2011 May, Dmitry Kazakov wrote:
> We have a bug: https://bugs.kde.org/show_bug.cgi?id=270753
> 
> This very crash happens due to wrong use of namespaces in the code.

I'm not sure what you mean here.

> But even
> if you fix the namespaces, then you will not be able to create a clone of a
> group layer, due to our algorithm of the check. This algorithm checks that
> the clone layer will not clone any of the parent layers. But due to the
> algorithm inside getNewNodeLocation() the parent and the source of the clone
> will always coincide. So, even if we fix the namespaces, it will not be
> possible to create a clone of a Group Layer. Ok, we can change
> getNewNodeLocation() to return some other sibling of the active node for
> clone layers to allow creation of the clones. But it will not work as well
> =). The problem is, the user will still be able to drag-and-drop the clone
> inside the group layer it duplicates. 

Well, not if d&d check whether the drop area is allowed. 

> So it'll lead to infinite loop
> finally.
> 
> Ok. What do I propose.
> 
> 1) Remove KisNodeManager::allowAsChild function and make use of all the
> KisNode::allowAsChild functions we do already have, but not use. This
> KisGroupLayer::allowAsChild will check for all the possible infinite loops.

Ok, that sounds good.

> So both creation and drag-and-drop will not cause infinite loops
> 2) Fix getNewNodeLocation() to allow creation of clones for the group
> layers.

Ok.

> 3) The type of the layer will be passed not by QString, but by an object
> prototype, so there will be needed some changes for KisNodeManager and
> (less) KisSelectionManager.

Can you elaborate on that?

One thing I'm not getting is how you will handle clones from grouplayers with a clone layer inside. Will that be possible?

-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org