Happens on both Linux and MacOS When no file is open, if you open a file, krita will reset the selected brush preset. STEPS TO REPRODUCE 1. Close all documents or open a new krita instance 2. Open a kra file 3. Observe you systematically switch to the same brush preset when opening a "first file" (if it's not selected already) OBSERVED RESULT For example in my case, I always switch back to a brush I never use: b) "Basic-5 Size Opacity" and which is not even in the active bundle EXPECTED RESULT Krita doesn't switch the brush preset when opening a "first" document SOFTWARE/OS VERSIONS macOS: Big Sur 11.6 (20G165) Linux/KDE Plasma: Linux Mint 20.2 64-bit
I can't reproduce on 94dbdca9e6 (Krita Plus), can you please download Krita Plus and check if it's still an issue for you?
Krita plus following the website link ? https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/ Why is it called beta 02? Am I wrong ? (5.0.0-beta2 (git 03c30c6)) Otherwise yes, reproduce at first try :/
I tried Krita next as well: 5.1.0-prealpha (git a3029b7) (https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/). Same thing. Krita beta 2 on macOS also does the same.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
I tried to reproduce this bug report but I cannot make it happen, I thought maybe because of testing I was using extra clean configs so I tested with my painting configs and old resources folder and could not reproduce the issue either. I tested with Krita 5 beta5 and master on macOS Is this issue still happening for you? Can you test with fresh configs? (make sure to backup you current ones so you can return to them).
Yes it's still happening on both systems. By clean config do you mean I should drop the krita preferences folder and let it regen ?
I recall having a similar problem after moving from beta 1 to beta 2. Deleting/backing up resourcecache.sqlite resolved the issue for me.
Yes it did indeed. Should that be added to a sort of clean up routine/operation ?
do you have the original resourcecache.sqlite so we can try and see what was wrong? It may be that it got corrupted on an earlier state of the resource managament work. Which could mean the likelyhood of this happen again is very low (or impossible) and th ebug can be closed.
Yes I do have it. I'll join it here. The issue did happen again and I deleted the file a few times but I just can't pinpoint how to reproduce it...
Sorry, my file is way too big to be attached.
I think this might've been fixed in the meantime, I cannot reproduce it anymore with master at 930da6975e9aacef7e78513d35c314481cf6026e
Brings back some memories. It seems I don't reproduce in 5.0.2