Proposal for Clone layers.

Dmitry Kazakov dimula73 at gmail.com
Sun May 15 18:08:18 CEST 2011


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

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110515/24fe52b2/attachment.htm 


More information about the kimageshop mailing list