Bug 480718 - [master] Opening documents always selects the Background layer
Summary: [master] Opening documents always selects the Background layer
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layer Stack (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: regression
: 481924 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-02-02 04:51 UTC by tomtomtomreportingin
Modified: 2024-04-10 16:12 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tomtomtomreportingin 2024-02-02 04:51:03 UTC
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)
Comment 1 Freya Lupen 2024-02-02 19:16:07 UTC
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.
Comment 2 Freya Lupen 2024-03-14 20:27:58 UTC
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.
Comment 3 Freya Lupen 2024-03-25 16:23:33 UTC
*** Bug 481924 has been marked as a duplicate of this bug. ***
Comment 4 Lynx3d 2024-04-10 08:51:56 UTC
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.
Comment 5 Bug Janitor Service 2024-04-10 15:39:50 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2115
Comment 6 Dmitry Kazakov 2024-04-10 16:11:30 UTC
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
Comment 7 Dmitry Kazakov 2024-04-10 16:12:07 UTC
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