Created attachment 103322 [details] example I was playing with bursh presets/settings (with installed bundles/brushes/presets form the resource page in the docs), deleting some .blacklist files etc. and all of a sudden the paintoppresets using internal patterns don't work correct any more. Example, if I use `Pastel_texture_thin`, it uses the internal pattern `3-rock-soft.png`. I close krita and reopen, after it starts, all other paintoppresets that use internal patterns start using this `3-rock-soft.png` pattern. I tried with cazu's brushes as well then. I select for example `Paint Pastel` from cazu's pack and then close krita. When I reopen every other pantioppreset that uses an internal pattern starts using `cazu-paper.pat` which is the settings that `Paint Pastel` uses. It isn't always consistent, sometimes krita overwrites all paintoppresets with the second to last used brush before closing, or something on these lines... It makes brushes unusable... please help? I tried everything, deleting all settings in share/krita, kritarc, install a different version (v3), install from ppa instead of using the appimage... nothing works. Brushes using internal patterns are unusable any more since the original pattern never gets loaded so I can't even search for it in the pattern list... I've attached a picture to maybe exemplify better.
Well, it's extremely annoying because I need to remember which brushes have internal patterns but at least if I delete the pattern from the f5 menu before I select a paintop that uses an internal pattern then the correct pattern is indeed loaded, but I need to remember to delete this internal pattern now for every brush that uses it...
Can confirm the bug. On my config, both Bristle_frottis.kpp and Pastel_texture_thin.kpp use the same pattern: "3-mini-rock-soft.png" While, according to imagemagick, they should respectively use 3-mini-rock-soft.png and 3-rock-smooth.png
> identify -verbose /usr/share/krita/paintoppresets/Bristle_frottis.kpp | grep 'Pattern\/Name' </param> <param type="string" name="Texture/Pattern/Name"><![CDATA[3-mini-rock-soft.png]]></param> > identify -verbose /usr/share/krita/paintoppresets/Pastel_texture_thin.kpp | grep 'Pattern\/Name' <param type="string" name="Texture/Pattern/Name"><![CDATA[3-rock-smooth.png]]></param>
Created attachment 103333 [details] fix that works for me It's probably not the correct fix, but it seems to work for me. The only thing is that instead of being only one pattern added to the pattern list at the end (I don't know if it's the intended behavior), all embedded patterns are added one by one if they're not in the list, but it does get the job done
Yes, I can confirm the issue. I will push the patch, but keep the bug open since I'm pretty sure that the patch breaks other things. This needs a couple of days of careful consideration.
I don't think it breaks anything, instead of trying to remove the texture it just appends what's needed if it's needed then retrieve it later and leaves them be in the system. It's a bad way of handling stuff, but I don't think this way of doing it breaks anything. In my opinion this whole system needs to be rewritten... a pain.
Pushed the patch, but cc'ed the wrong bug. commit 912aee6f2381819b8bf6fc0ec40e79811d2b01cb Author: Boudewijn Rempt <boud@valdyas.org> Date: Mon Jan 23 16:20:12 2017 +0100 CCBUG:374745 Always store the embedded pattern in the pattern manager This will lead to duplicated patterns, but at least not every brush will paint with the same pattern. This bug still needs careful fixing. Patch by Razvanc, thanks! CCMAIL:razvanc87@yahoo.com
I guess in the new resource system, this should just look for patterns by both md5 and a name. Although I'm not sure why searching for md5 wouldn't work - does pattern not have md5 calculated at all? What might have been another reason for all/random patterns having the same md5?
The embedded resource system has been completely rewritten, and I cannot reproduce these issues with patterns any more.