Proposal for global selections

[Boudewijn Rempt]

On Sunday 15 May 2011 May, Dmitry Kazakov wrote:
> We have a bug with out global selections system.
> https://bugs.kde.org/show_bug.cgi?id=273260
> 
> The point is, we store global selection as a KisSelection inside a KisImage
> object. Most of our actions like Crop/Resize/Scale the image do not take
> this selection into account. That is why after most of them selection
> becomes shifted and non-transformed. And we can't apply a visitor to it,
> because it is not a node.

Well, that's not really true. We apply a visitor on a layer, so we can get the image from the layer and from the image we should get the global selection. Or we could pass the global selection to the visitor's constructor arguments. So every visitor can access the global selection. If they don't that's a bug. Or pass the image to the constructor of the visitor, which would be nicer than trying to get the image from the layer, since we should be able to have a layer tree without an image.

> I propose a solution for this problem:
> KisImage will store a KisSelectionMask inside and will put this mask as a
> child to the root node. 

With root node, you mean the root group layer, right?


I'm not sure about this. I know we've tried this before and given up on it, but I don't know why anymore. But I really, really, really want to stop going back and forth between solutions. Our handling of selections has a horrible history where we refactor time and again back to an earlier stage and then forward and backward again. We nead to break that pattern.

> This assignment will be done in two functions
> setGlobalSelection() and setRootNode().

And will setRootNode replace setRootLayer? 

> After this change, all our node visitors will work as usual, they will just
> process all the children of the root node, so the global selection will be
> transformed as a regular selection mask.

That sounds good.

> No change will be needed for the visitors (except for some of them, those do
> not work with masks at all).
> 
> UI problem:
> If the mask is added to the node graph, then it is shown in a KisLayerBox.
> So we will have to add an option to KisConfig to hide it as we do for the
> root layer. Actually, we may leave a way for a user to show it. It worked
> quite well, when i tried to add it in a hardcoded way. The only trouble i
> got was that it was impossible to toggle "Active" property of the mask.
> Everything rest was working very well.

If we go this way, I think we should remove the option to show the root group layer from Krita. Showing the global selection on the root group layer will make all kinds of interactions possible that we haven't designed for and that will make krita more buggy, like dragging away the global selection to another layer.

> Why we can't do it in another way:
> Because all the visitors and most of the commands in Krita work with nodes.
> So, for example, to shift a global selection (setX(), setY() methods) we
> will have to create one more command. We will have to modify/duplicate all
> our visitors/commands to let them work with selections.

Modify, yes -- but duplicate? Of course not. And it's by no means impossible to do. And having the global selection as a selection on the root group layer can cause other bugs as well, for instance by code that takes the global selection from the image, and uses it, but also takes the selection mask from the root group layer.

I'm not against this plan, but I'm not sure it has been thought through enough, and I'd like other people's opinions as well.

> How it is done in other editors:
> I tried Gimp. It transforms global selection with the image. And PS7, as far
> as i remember, crops the selection alongside with the image as well.

For crop, the selection's bounds should become the initial crop rect.

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