Bug 393191 - [Brush-Presets] appear again if deleted/ blacklisted ("~" at the start of Windows blacklist location)
Summary: [Brush-Presets] appear again if deleted/ blacklisted ("~" at the start of Win...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Resource Management (show other bugs)
Version: 4.0.1
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Halla Rempt
URL:
Keywords:
: 392196 393279 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-04-16 12:31 UTC by ZeroFrost
Modified: 2021-03-30 12:39 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ZeroFrost 2018-04-16 12:31:57 UTC
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.
Comment 1 Scott Petrovic 2018-04-16 13:16:47 UTC
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
Comment 2 ZeroFrost 2018-04-16 13:54:44 UTC
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).
Comment 3 Scott Petrovic 2018-04-16 15:31:48 UTC
*** Bug 392196 has been marked as a duplicate of this bug. ***
Comment 4 Scott Petrovic 2018-04-16 15:35:13 UTC
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
Comment 5 ZeroFrost 2018-04-17 13:47:26 UTC
(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.
Comment 6 Scott Petrovic 2018-04-17 14:08:25 UTC
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.
Comment 7 ZeroFrost 2018-04-17 14:37:09 UTC
(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.
Comment 8 Scott Petrovic 2018-04-19 16:40:30 UTC
*** Bug 393279 has been marked as a duplicate of this bug. ***
Comment 9 Tarn Faulkner 2018-04-23 17:08:09 UTC
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.
Comment 10 Halla Rempt 2021-03-30 12:39:42 UTC
This has been fixed with the resource system rewrite (tested with 891c50ad013d1a3ddbd144227a3f6d5ad944a704)