If Brush Preset were created and deleted without restarting Krita between those actions Deleted Brush Presets will appear after restarting Krita. Steps to recreate bug: 1. Open Krita 2. Create new document 3. Click on Edit Brush Settings 4. Click Save New Brush Preset and Apply 5. Delete created Brush Preset using Choose Brush Preset menu 5. Restart Krita 6. Create new document Occured Unwanted Outcome: Deleted Brush Preset is visible again. Entry in kis_paintoppresets.blacklist doesnt work. Wanted outcome: Deleted Brush Preset mantain deleted Workaround #1 7. Delete unwanted Brush Preset using Choose Brush Preset menu again. (This will add duplicate entry to kis_paintoppresets.blacklist that will work) Workaround #2 4a. Restart krita before deleting created Brush Preset Workaround #3 Manually delete unwanted Brush Presets from Krita folder C:\Users\"UserName"\AppData\Roaming\krita\paintoppresets Summary: If Krita was not restarted between Creating and Deleting Brush Preset added Entry to kis_paintoppresets.blacklist wont work.
Is this separate than your other bug report? It seems you are describing the same thing. https://bugs.kde.org/show_bug.cgi?id=392196
After inspection youre right. My pevious bug was about the same code problem just different steps to recrate it. I we cant merge those two we can close older one and leave this (i feel this is more indepth).
*** Bug 392196 has been marked as a duplicate of this bug. ***
This is the "~" blacklist problem that only exists on windows. Blacklist files are getting a tilde character at the beginning which is messing things up on Windows
(In reply to Scott Petrovic from comment #4) > This is the "~" blacklist problem that only exists on windows. Blacklist > files are getting a tilde character at the beginning which is messing things > up on Windows Windows reads"~" correctly overall. Issue occurs when brush was created and deleted(blacklisted) in one Krita session (without restarting Krita). Krita then proceed to ignore blacklist entries of those brushes.
Could you explain what you mean? it definitely is not reading the ~ correctly on my Windows 10 machine for finding a location. It decides to open the location in a web brower because it doesn't know what to do with it.
(In reply to Scott Petrovic from comment #6) > Could you explain what you mean? it definitely is not reading the ~ > correctly on my Windows 10 machine for finding a location. > > It decides to open the location in a web brower because it doesn't know what > to do with it. There may be some issues with "~" on windows but if that would prevent krita from recognizing paths to brushes blacklisting would never work (all paths start with ~) but in some cases blacklisting works perfectly with "~" in path (cases are describled as workarounds #1 and #2 in main ticket). I did many tests and Imo there is problem with how/when krita reads kis_paintoppresets.blacklist and apply it to memory, not how blacklist entites are written. Simple restarting krita fix issue and restarting doesnt change kis_paintoppresets.blacklist file at all.
*** Bug 393279 has been marked as a duplicate of this bug. ***
I am seeing what I believe is the same bug (blacklisted brushes showing up in the Brushes Docker on Windows 10 installations of Krita 4.0.1), and have a relatively simple repro case. To reproduce: 1. Select any existing custom brush. Note that the custom brush should have been saved previously with "Save New Brush" and then Krita should have been restarted to avoid a different bug. 2. Edit brush slightly (I changed spacing value) and "Overwrite Brush". 3. Edit the brush slightly again and "Overwrite Brush". 4. Shut down and relaunch Krita. Result: Even though both backup brush files are written into the blacklist file, one of the them will still show up in the Brushes Docker. This is very problematic for users as doing multiple edits of a brush during one session can result in what look like many duplicates in the Brushes Docker. If I should have created a new bug for this please let me know.
This has been fixed with the resource system rewrite (tested with 891c50ad013d1a3ddbd144227a3f6d5ad944a704)