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
I can confirm, it seems to work the same way for me. 2.9.5, win8.1.
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.
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
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
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