Proposal for Clone layers.

[Dmitry Kazakov]

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.


>> 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.


>> 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).


> 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.


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110517/5aa1d768/attachment.htm