Bug 391025 - overwriting a brush setting remove the tags of the brush
Summary: overwriting a brush setting remove the tags of the brush
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tagging (show other bugs)
Version: 4.2.9
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Halla Rempt
URL:
Keywords:
: 401634 418808 428255 428538 429958 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-02-24 21:14 UTC by Peter Mueller
Modified: 2021-08-19 17:27 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Video showing the issue described (2.85 MB, video/mp4)
2018-02-24 21:14 UTC, Peter Mueller
Details
Video showing brush tag issues (3.47 MB, video/mp4)
2018-02-27 20:06 UTC, Peter Mueller
Details
Krita 4.1.1 Brushpreset overwriting bug (2.01 MB, video/mp4)
2018-08-11 06:46 UTC, Julian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Mueller 2018-02-24 21:14:58 UTC
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
Comment 1 Scott Petrovic 2018-02-25 15:15:41 UTC
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. :)
Comment 2 Peter Mueller 2018-02-27 20:05:30 UTC
(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. :)
Comment 3 Peter Mueller 2018-02-27 20:06:20 UTC
Created attachment 111064 [details]
Video showing brush tag issues
Comment 4 Peter Mueller 2018-02-27 20:08:25 UTC
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?
Comment 5 Andreas Resch 2018-04-10 13:33:06 UTC
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
Comment 6 Beatrice 2018-05-17 15:31:42 UTC
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.
Comment 7 Julian 2018-08-11 06:46:10 UTC
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
Comment 8 KDE Neon user 2019-06-04 16:37:34 UTC
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"
Comment 9 Tiar 2020-03-13 10:43:23 UTC
*** Bug 401634 has been marked as a duplicate of this bug. ***
Comment 10 Tiar 2020-03-13 10:43:55 UTC
*** Bug 418808 has been marked as a duplicate of this bug. ***
Comment 11 Hikari 2020-06-03 10:50:06 UTC
(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.
Comment 12 Halla Rempt 2020-06-03 10:59:49 UTC
Please don't change the status of a bug; assigned means that there's someone who is working on it, namely me.
Comment 13 andreiba 2020-08-22 12:18:03 UTC
4.3.0 win64

Please. Fix it.
Very annoying bug!
Comment 14 Tiar 2020-11-04 20:41:52 UTC
*** Bug 428255 has been marked as a duplicate of this bug. ***
Comment 15 Halla Rempt 2021-03-25 13:44:01 UTC
This is fixed in master. Tested with 60caab4673f157d62671ff3c734281b3ad4db755
Comment 16 Tiar 2021-08-19 17:27:10 UTC
*** Bug 429958 has been marked as a duplicate of this bug. ***
Comment 17 Tiar 2021-08-19 17:27:21 UTC
*** Bug 428538 has been marked as a duplicate of this bug. ***