Bug 345601

Summary:	On deleting a layer, the layer under the deleted layer should be selected, not the one above
Product:	[Applications] krita	Reporter:	Loren Dias <loren>
Component:	Usability	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	halla, herrkjeldsen
Priority:	NOR
Version:	2.9.1
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:	http://commits.kde.org/krita/e1da917aac6211d744ace01fe206314f30f89288	Version Fixed In:
Sentry Crash Report:

Description Loren Dias 2015-03-28 07:12:20 UTC

In Krita 2.8.7 the item selected after deleting a layer would be the next one down in the list.
** Eg: In a list A - Z, when Item C was deleted item D would be selected afterward.
** In Krita 2.9.1 when Item C is deleted item B is selected afterward.

This functions contrary to users existing expectations, another example of how this functions strangely is that in a list A - Z where each letter has 3 children, eg:
A (Group)
A1
A2
A3
B
B1
...etc

When Item B is deleted the Layer Selected after the delete doesn't ascend to A3 but skips all the way to Group A.

I marked this as a bug because it would not be logical for this functionality to change users workflow for no good reason. Please consider and weigh if this new behavior is actually intended, I'm sure most people would prefer a smooth transition to 2.9.x branch from the 2.8.x branch instead of a crunchy upgrade.

Reproducible: Always

Steps to Reproduce:
1. Create 5 layer groups with 3 layers each
2. Begin deleting layers and watch which layer Krita decides to select after deleting a layer, and a group.


Expected Results:  
See Krita 2.8.7

Comment 1 Marcus Kjeldsen 2015-06-20 14:05:01 UTC

I can confirm, it seems to work the same way for me. 2.9.5, win8.1.

Comment 2 Halla Rempt 2016-03-19 12:04:26 UTC

Yes, this still happens in 3.0. I'm still not sure whether it is a good or a bad thing... Haven't got access to photoshop at the moment check what that does, but gimp selects the layer below.

Comment 3 Dmitry Kazakov 2016-03-24 09:35:54 UTC

Git commit e1da917aac6211d744ace01fe206314f30f89288 by Dmitry Kazakov.
Committed on 24/03/2016 at 09:35.
Pushed by dkazakov into branch 'master'.

Fix layer selection after removing a node

See a comment in KisLayerBox::slotAboutToRemoveRows()

Fixes T1871

M  +38   -0    plugins/extensions/dockers/defaultdockers/kis_layer_box.cpp
M  +1    -0    plugins/extensions/dockers/defaultdockers/kis_layer_box.h

http://commits.kde.org/krita/e1da917aac6211d744ace01fe206314f30f89288

Comment 4 Dmitry Kazakov 2020-08-19 22:09:17 UTC

Git commit 8fd316da11d6ec5c8a129bc88dd042fb0bcdc659 by Dmitry Kazakov.
Committed on 19/08/2020 at 22:08.
Pushed by dkazakov into branch 'krita/4.3'.

Fix temporary wrongly selected layer when merging down huge layers

The problem happened because of our workaround for Qt's removed
item avoidance algorithm. On element removal, Qt selects an item above
that, but we need a reverse, below it.

The previous implementation just tried to fix Qt's behavior after the
removal, but that didn't seem to work correctly in case of merge down.
Therefore, this patch implements a special signal that is fired *before*
beginRemoveRows(), that fixes the selection before Qt can lay its hands
on it.
Related: bug 418922

M  +15   -0    libs/ui/kis_node_filter_proxy_model.cpp
M  +4    -0    libs/ui/kis_node_filter_proxy_model.h
M  +1    -0    libs/ui/kis_node_model.cpp
M  +1    -0    libs/ui/kis_node_model.h
M  +9    -9    plugins/dockers/layerdocker/LayerBox.cpp
M  +1    -1    plugins/dockers/layerdocker/LayerBox.h

https://invent.kde.org/graphics/krita/commit/8fd316da11d6ec5c8a129bc88dd042fb0bcdc659

Comment 5 Dmitry Kazakov 2020-08-19 22:09:33 UTC

Git commit 87d27964b5893f67c95deb03d73198a8acb6849a by Dmitry Kazakov.
Committed on 19/08/2020 at 22:09.
Pushed by dkazakov into branch 'master'.

Fix temporary wrongly selected layer when merging down huge layers

The problem happened because of our workaround for Qt's removed
item avoidance algorithm. On element removal, Qt selects an item above
that, but we need a reverse, below it.

The previous implementation just tried to fix Qt's behavior after the
removal, but that didn't seem to work correctly in case of merge down.
Therefore, this patch implements a special signal that is fired *before*
beginRemoveRows(), that fixes the selection before Qt can lay its hands
on it.
Related: bug 418922

M  +15   -0    libs/ui/kis_node_filter_proxy_model.cpp
M  +4    -0    libs/ui/kis_node_filter_proxy_model.h
M  +1    -0    libs/ui/kis_node_model.cpp
M  +1    -0    libs/ui/kis_node_model.h
M  +9    -9    plugins/dockers/layerdocker/LayerBox.cpp
M  +1    -1    plugins/dockers/layerdocker/LayerBox.h

https://invent.kde.org/graphics/krita/commit/87d27964b5893f67c95deb03d73198a8acb6849a