Created attachment 110980 [details] Video showing the issue described Just played with modifying brushes. It seems that thumbnails are not correctly saved. (Also changing the part of the thumbnail does not trigger the flag that the brush has changed.) Additionally, the lists of brush selection dialogues seem not to be updated accordingly with these changes. Please see attached video. Also note that overwriting a brush setting remove the tags of the brush (at least it looks like that so that it is no longer present in my own brush list). When I change a brush and overwrite it, I, personally, don't want that tags get lost. BR Peter
For the points about the tags not saving, can you try the latest nightly and see if it still has issues. We have had a beta 2 as well as some other changes since the 1st beta. I thought that was fixed with saving tags when overwriting. https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ For the changing the icons and it not being modified. We need to have a discussion internally with the developers and artists about that. There are some various UX issues with the current way it is done in the scratchpad. The biggest one being a lot of people don't realize those dotted lines are for the brush icon. You have to manually click the button on the bottom to show the current icon. We are trying to think of solutions on how to do this better. One solution might involve separating the icon from the scratchpad so it is in its own area. This area will auto-load the existing icon and have options to edit it. We need to discuss it more. Other suggestions would be welcome. :)
(In reply to Scott Petrovic from comment #1) > For the points about the tags not saving, can you try the latest nightly and > see if it still has issues. We have had a beta 2 as well as some other > changes since the 1st beta. I thought that was fixed with saving tags when > overwriting. > > https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/ I've picked build #75, "krita-nightly-x64-v4.0.0.51-460-ge72f2bdea2-setup.exe". When installed, it said it's "4.0.0-beta1". Is this the correct version (as I do not see beta2 ...)? I think you do have some tag management issues. I've attached a video showing a sequence of actions with strange behaviour: (1) I create a copy of a brush and assign it to a newly created tag ("ABC"). This works as expected. The brush appears on the respective newly created brush preset. (2) I then modify the brush and use Overwrite. (a) The brush is removed from the preset. (b) the the second tag ("Pencils_(mpe)") is duplicated. (3) Then I assign the brush again to the tag "ABC". However, it is not present on the respective preset list. Although when checked on the brush, the brush seemed to be assign to the tag "ABC". (4) When I then exit Krita (without saving the file) and start it again, the newly created brush (!) is not in the list of brushes anymore. Also tag "ABC" is no longer available. Weird is, that if I name the second brush "AAA Air..." or "AjA Air..." it is NOT deleted from the list of tag ABC when tghe brush is changed. It does happen when I use the name "mpe Air..." (which sorts it more in the middle of the list. > > For the changing the icons and it not being modified. We need to have a > discussion internally with the developers and artists about that. There are > some various UX issues with the current way it is done in the scratchpad. > The biggest one being a lot of people don't realize those dotted lines are > for the brush icon. You have to manually click the button on the bottom to > show the current icon. > > We are trying to think of solutions on how to do this better. One solution > might involve separating the icon from the scratchpad so it is in its own > area. This area will auto-load the existing icon and have options to edit > it. We need to discuss it more. > > Other suggestions would be welcome. :)
Created attachment 111064 [details] Video showing brush tag issues
With respect to the UX for the brush icon, let me know where to put my points as I don't think the bug list is the right place fro it?
I just tested the latest nightly build (Build #119 10.04.2018 08:18:00) and the issue is still there. This makes creating a new brush library very hard to accomplish. Cheers, Andreas
Just dropping in to confirm that this bug is still occurring in last night's build (git 65e24ca), and provide a few additional details. At least for me, the brush stops showing up in its assigned tags, but the tags in question still show up in the "remove from other tag" context menu. Attempting to add or remove tags results in the context menu reflecting the changes, but not the docker itself. Restarting the software seems to allow the brush to be assigned and removed from tags again, but overwriting it causes the issue to reoccur.
Created attachment 114397 [details] Krita 4.1.1 Brushpreset overwriting bug In my attached video you can observe the behaviour in krita 4.1.1
Below is a report submitted by a Krita 4.2.0 user: "Save a brush in a custom tag, then open the tag, make adjustments to the brush and click "overwrite preset". it disappears from the tag but when you open the list with all brushes it's there and is still "marked" as in the tag, even if I try to remove it from the tag and then add it again it won't appear until I restart Krita"
*** Bug 401634 has been marked as a duplicate of this bug. ***
*** Bug 418808 has been marked as a duplicate of this bug. ***
(In reply to KDE Neon user from comment #8) > Below is a report submitted by a Krita 4.2.0 user: > > > "Save a brush in a custom tag, then open the tag, make adjustments to the > brush and click "overwrite preset". it disappears from the tag but when you > open the list with all brushes it's there and is still "marked" as in the > tag, even if I try to remove it from the tag and then add it again it won't > appear until I restart Krita" I'm using Krita 4.2.9 and I still seeing this bug and it's really annoying, I found a workaround without restarting Krita in the meantime. After you overwrite it, rename it so the brush get refreshed, after that you could assign it back into the tag again. But that's pretty much of a pain.
Please don't change the status of a bug; assigned means that there's someone who is working on it, namely me.
4.3.0 win64 Please. Fix it. Very annoying bug!
*** Bug 428255 has been marked as a duplicate of this bug. ***
This is fixed in master. Tested with 60caab4673f157d62671ff3c734281b3ad4db755
*** Bug 429958 has been marked as a duplicate of this bug. ***
*** Bug 428538 has been marked as a duplicate of this bug. ***