480718 2024-02-02 04:51:03 +0000 [master] Opening documents always selects the Background layer 2024-04-10 16:12:07 +0000 1 1 2 Applications krita Layer Stack nightly build (please specify the git hash!) Appimage Linux RESOLVED FIXED regression NOR normal --- 1 tomtomtomreportingin krita-bugs-null acc4commissions lynx.mw+kde penguinflyer2222 https://invent.kde.org/graphics/krita/-/commit/4ded66b083057cb4e574f2f21159a19279d7da49 0 oldest_to_newest 2285298 0 tomtomtomreportingin 2024-02-02 04:51:03 +0000 git a8f6ca2 SUMMARY Opening documents always selects the Background layer, which is often locked. Note: this does not occur when creating new documents. STEPS TO REPRODUCE 1. Open a recent document with two layers. 2. Observe the layer stack. OBSERVED RESULT The Background layer is selected. EXPECTED RESULT The last used layer should be selected. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Sid KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 (appimage) 2285490 1 penguinflyer2222 2024-02-02 19:16:07 +0000 Confirmed, regression of commit 8dc97144. With a single layer document (.png file for example), there is instead no layer selected at all. That leads to the crash mentioned here: https://invent.kde.org/graphics/krita/-/commit/8dc97144531e42055a2d31918c4674e30e1a7026#note_860048 when selecting the Transform Tool in Fast mode. May be related to bug 480331. 2301021 2 penguinflyer2222 2024-03-14 20:27:58 +0000 The exact change that caused this regression seems to be this in KisSynchronizedConnectionBase::postEvent() : > - if (QThread::currentThread() == this->thread()) { > + if (s_instance->enableAutoModeForUnittests && QThread::currentThread() == this->thread()) { which causes the 'else' path to be taken. In that path, the order of events when loading the document seems to change from > KisDummiesFacadeBase::slotNodeAdded, KisDummiesFacadeBase::slotContinueAddNode, KisDummiesFacadeBase::slotNodeAdded, KisDummiesFacadeBase::slotContinueAddNode, KisDummiesFacadeBase::slotNodeActivationRequested, KisView::slotLoadingFinished to > KisDummiesFacadeBase::slotNodeAdded, KisDummiesFacadeBase::slotNodeAdded, KisView::slotLoadingFinished, KisDummiesFacadeBase::slotContinueAddNode, KisDummiesFacadeBase::slotContinueAddNode, KisDummiesFacadeBase::slotNodeActivationRequested KisView::slotLoadingFinished being where the current node is set. I'm guessing this reordering is the cause of this bug. 2305452 3 penguinflyer2222 2024-03-25 16:23:33 +0000 *** Bug 481924 has been marked as a duplicate of this bug. *** 2310024 4 lynx.mw+kde 2024-04-10 08:51:56 +0000 This bug seems to have more confusing side effects too. If you create a new image from clipboard (Ctrl+Shift+N), then the layers docker has no active layer at all, and while you can for some reason paint on it with the brush tool, transform tool says "Cannot transform empty layer", and trying to copy a selected area will even error out with a safe assert. 2310113 5 bug-janitor 2024-04-10 15:39:50 +0000 A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2115 2310132 6 dimula73 2024-04-10 16:11:30 +0000 Git commit 1079c7f1f7e32aace1fcf7a5155d2841ca25ab7e by Dmitry Kazakov. Committed on 10/04/2024 at 15:34. Pushed by dkazakov into branch 'master'. Fix activation of the node on opening .kra document Since KisDummiesFacadeBase::setImage() is now executed asyncronously the node activation that used to happen in KisView::slotLoadingFinished() now doesn't work anymore. Hence we should just instruct KisDummiesFacadeBase::setImage() itself, which node it should activate at the end of image loading into dummies graph. M +2 -2 libs/ui/KisDocument.cpp M +1 -1 libs/ui/KisDocument.h M +0 -11 libs/ui/KisView.cpp M +10 -1 libs/ui/flake/kis_dummies_facade_base.cpp M +2 -1 libs/ui/flake/kis_dummies_facade_base.h M +2 -2 libs/ui/flake/kis_shape_controller.cpp M +2 -1 libs/ui/flake/kis_shape_controller.h M +22 -2 libs/ui/tests/kis_dummies_facade_base_test.cpp M +1 -0 libs/ui/tests/kis_dummies_facade_base_test.h M +3 -4 plugins/impex/kra/kra_import.cpp M +2 -4 plugins/impex/ora/ora_import.cc https://invent.kde.org/graphics/krita/-/commit/1079c7f1f7e32aace1fcf7a5155d2841ca25ab7e 2310133 7 dimula73 2024-04-10 16:12:07 +0000 Git commit 4ded66b083057cb4e574f2f21159a19279d7da49 by Dmitry Kazakov. Committed on 10/04/2024 at 16:12. Pushed by dkazakov into branch 'krita/5.2'. Fix activation of the node on opening .kra document Since KisDummiesFacadeBase::setImage() is now executed asyncronously the node activation that used to happen in KisView::slotLoadingFinished() now doesn't work anymore. Hence we should just instruct KisDummiesFacadeBase::setImage() itself, which node it should activate at the end of image loading into dummies graph. (cherry picked from commit 1079c7f1f7e32aace1fcf7a5155d2841ca25ab7e) M +2 -2 libs/ui/KisDocument.cpp M +1 -1 libs/ui/KisDocument.h M +0 -11 libs/ui/KisView.cpp M +10 -1 libs/ui/flake/kis_dummies_facade_base.cpp M +2 -1 libs/ui/flake/kis_dummies_facade_base.h M +2 -2 libs/ui/flake/kis_shape_controller.cpp M +2 -1 libs/ui/flake/kis_shape_controller.h M +22 -2 libs/ui/tests/kis_dummies_facade_base_test.cpp M +1 -0 libs/ui/tests/kis_dummies_facade_base_test.h M +3 -4 plugins/impex/kra/kra_import.cpp M +2 -4 plugins/impex/ora/ora_import.cc https://invent.kde.org/graphics/krita/-/commit/4ded66b083057cb4e574f2f21159a19279d7da49