<br>On Mon, May 16, 2011 at 10:59 AM, Boudewijn Rempt <> wrote:<br>> On Sunday 15 May 2011 May, Dmitry Kazakov wrote:<br>>> We have a bug: <a href="https://bugs.kde.org/show_bug.cgi?id=270753">https://bugs.kde.org/show_bug.cgi?id=270753</a><br>
>><br>>> This very crash happens due to wrong use of namespaces in the code.<br>><br>> I'm not sure what you mean here.<br><br>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.<br>
<br><br>>> But even<br>>> if you fix the namespaces, then you will not be able to create a clone of a<br>>> group layer, due to our algorithm of the check. This algorithm checks that<br>>> the clone layer will not clone any of the parent layers. But due to the<br>
>> algorithm inside getNewNodeLocation() the parent and the source of the clone<br>>> will always coincide. So, even if we fix the namespaces, it will not be<br>>> possible to create a clone of a Group Layer. Ok, we can change<br>
>> getNewNodeLocation() to return some other sibling of the active node for<br>>> clone layers to allow creation of the clones. But it will not work as well<br>>> =). The problem is, the user will still be able to drag-and-drop the clone<br>
>> inside the group layer it duplicates.<br>><br>> Well, not if d&d check whether the drop area is allowed.<br><br>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.<br>
<br><br>>> 3) The type of the layer will be passed not by QString, but by an object<br>>> prototype, so there will be needed some changes for KisNodeManager and<br>>> (less) KisSelectionManager.<br>><br>
> Can you elaborate on that?<br><br>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. <br>
<br>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.<br>
<br>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).<br>
<br><br>> One thing I'm not getting is how you will handle clones from grouplayers with a clone layer inside. Will that be possible?<br><br>Sorry, I haven't go the question.<br>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.<br>
<br><br>-- <br>Dmitry Kazakov<br>