Proposal for Clone layers.

[Boudewijn Rempt]

On Tuesday 17 May 2011 May, Dmitry Kazakov wrote:
> On Mon, May 16, 2011 at 10:59 AM, Boudewijn Rempt <> wrote:
> > 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.
> 
> Well there is a local variable 'parent' that is defined twice in two nested
> namespaces: a paremeter (function-visible) and a local variable inside 'if'
> block (if-block-visible). The last one initialized in a wrong way so it has
> a random value.
> 

Ah, I wouldn't call that namespace issues. I was thinking -- we don't do namespaces in krita, do we? This should be easy enough to fix on its own, right!

> 
> >> 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.
> 
> Well, yes. That is what I'm talking about. Currently, there is no check for
> this. And I'm suggesting adding this check. But it should be added not to
> drag-and-drop only. There should be a universal interface for such checks.
> And the same interface should be used during creation of nodes and during
> moving of them.

Right.

> 
> 
> >> 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?
> 
> Yes. Currently, to create a layer, KisNodeManager parses the signal into a
> type of the layer written as a QString. Then this string is passed to a
> allowAsChild function. It checks the combination of the layer/parent and,
> together with, getNewNodeLocation (the latter one uses QString as well).
> After that, they pass a parent/above pointers to KisLayerManager and the
> latter one creates a layer.
> 
> This way of creation has at least one big flaw. You cannot decide where to
> put a clone before you created it. Well, you can workaround it by hardcoding
> special treatment of clone layers here, but this will expose internals of
> KisLayerManager into KisNodeManager. And after that there will be no reason
> of keeping these two classes separated. We will have to merge them.
> 
> That is why I'll need changes in KisNodeManager. The layers will have to be
> created in two stages. First, the KisNodeManager asks the KisLayerManager to
> create an object (prototype). Then the node manager searches a proper place
> for this layer in the stack and puts it there. Afterwards it passes a
> created and positioned layer to the layer manager back where it can
> configure it if needed (for Adjustment layers, for example).
> 
> 

Okay, now I get this.

> > One thing I'm not getting is how you will handle clones from grouplayers
> with a clone layer inside. Will that be possible?
> 
> Sorry, I haven't go the question.
> I'll try to answer what I understood. The clone layer is just a projection
> of some other layer. When the source changes, an update signal is issued for
> the clone as well. So the only thing we should avoid is a cycle links. So if
> a group layer has any other clones inside, those do not link to this very
> group layer, it'll be ok, and they will not need any special treatment.

Yes, right. Okay, good plan -- thanks for the explanation. Let's make sure this explanation finds its way into the code documentation!

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