Bug 399152 - [feature request] create new layers above the selected group
Summary: [feature request] create new layers above the selected group
Status: RESOLVED DUPLICATE of bug 399103
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: 4.1.1
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-27 17:47 UTC by katearcher89
Modified: 2018-09-28 15:27 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description katearcher89 2018-09-27 17:47:54 UTC
When creating new layer with the selected group the layer is created inside the group, i.e. one level down.

how to reproduce:
1. Create a group.
2. Select it.
3. Create a new layer(via hotkey or a button at the bottom of the layer docker).
4. The layer is created inside the group, one level down from the selected position in the layer stack.

Expected: As with the creation of the layers with a layer already selected in the layer docker, I expect it to create a layer above the group layer, not inside/under. 

This is bothering me for three reasons: 

First is inconsistency, since creation of the layer with a layer selected works in one way(creates a layer on the same hierarchy level as firstly selected and placed above it) and creation of the layer with a group selected works in other way(creates a layer one hierarchy level down inside the group under the selected position in the layer docker). 

The second is that it can be pretty frustrating to pull that created layer back to the top hierarchy level if there are no individual layers there since the gaps between groups are too small and seven times of ten tries you'll drop that layer not between groups but inside of them. 

The third one is it's an extra action where it shouldn't be. If I want to create a layer inside a group I choose a layer inside a group and I'll be fine. If I want to create a layer on the same level of hierarchy I'll choose the element on the same level and I'll be fine. But with this behaviour I spent one extra action to get where I want to for now reason, since the only use case I can imagine this behaviour is make sense when you have an empty group and that is in my opinion is far more rare situation than a creation of the layer without wanting it to go under, not above the selected element of the layer stack.

I know that it's kinda debatable but nonetheless kinda bothering me every time when I fight with the layer docker over trying to place the layer where I want in to be(Both in terms of logic of the placement and not-so-refined margins of the drop-zones).
Comment 1 Halla Rempt 2018-09-27 17:51:09 UTC
Um... Creating the layer inside the group when the group is selected is consistent with other applications like Gimp and Photoshop. It also provides for a common workflow (create a group, populate it with layers). But we've been getting patches and wishes for this for some time now, so I'm wondering: what is making people ask for this right now? 

See https://bugs.kde.org/show_bug.cgi?id=399103 and https://phabricator.kde.org/D15523

*** This bug has been marked as a duplicate of bug 399103 ***
Comment 2 katearcher89 2018-09-27 18:09:53 UTC
(In reply to Boudewijn Rempt from comment #1)
> Um... Creating the layer inside the group when the group is selected is
> consistent with other applications like Gimp and Photoshop. It also provides
> for a common workflow (create a group, populate it with layers). But we've
> been getting patches and wishes for this for some time now, so I'm
> wondering: what is making people ask for this right now? 
> 
> See https://bugs.kde.org/show_bug.cgi?id=399103 and
> https://phabricator.kde.org/D15523
> 
> *** This bug has been marked as a duplicate of bug 399103 ***

Well, in my experience its a combination of two things: Different expected behaviour for seemingly the same elements in terms of logic and, more importantly -- the kinda cumbersome drag'n'drop behaviour: it has very small gaps between the layers/groups on the same level(i.e. you have to be veeery careful when trying to drag and drop the layer to the new position in the stack) and laggy feeling when after you have missed and drop a layer in the wrong group krita starts to refresh the preview/structure of the image and on large files(like 50+ layers 7k+ size) it's very noticeable and a little disruptive.

I've just tried to drag'n'drop im phiotoshop and yes, it has much more large margins for drag'n'drop and a task of placing a layer anywhere in the stack where you want it to be is totally no-brainer. Nut in krita if you have groups placed one next to each other it's like a minefield :(

So an easy fix for this that comes to mind first is to synchronize the logic between the layer-on-layer and layer-on-group behaviour and so I suspect each of the people who report it is thinking about it. But of course the more fluid drop zones will make that minefield-trip much more tolerable too :)
Comment 3 Halla Rempt 2018-09-28 15:27:40 UTC
The drag and drop margins in Qt don's seem to be very tweakable, though.