Summary: | [Brush-Presets] appear again if deleted/ blacklisted ("~" at the start of Windows blacklist location) | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | ZeroFrost <zerofrost.pl> |
Component: | Resource Management | Assignee: | Halla Rempt <halla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | halla, randum, scottpetrovic, ta-as |
Priority: | NOR | ||
Version: | 4.0.1 | ||
Target Milestone: | --- | ||
Platform: | Microsoft Windows | ||
OS: | Microsoft Windows | ||
Latest Commit: | Version Fixed In: |
Description
ZeroFrost
2018-04-16 12:31:57 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 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) |