It should be working, I think…
The bundle creation function seems to be broken in Krita 5 right now. When I create a bundle it’s only a empty bundle a few kilobytes in size. Importing bundles work fine though
Thanks for info, I will check out what’s wrong.
Thank you! Not related to the bundle problem but also I noticed that loading brush tips that are within folders in /brushes/ doesn’t seem to work anymore. It still works fine for brush presents and patterns
Weird, I see that Halla fixed it quite recently on March 18th, so I guess at that point it worked. Are you sure you checked on the latest build? If yes, then I guess it got broken again (it happens )
If you find anything else, you can write here or anywhere, while we still have two months before the beta phase, the earlier we know about something broken, the earlier we can address it. (Though we do know about some things that are broken already, of course, there is a whole list of issues and whatnot).
I just tested the latest windows and linux appimage nightly build. Loading brushes that’s within other folders in the /brushes/ folder still doesn’t work.
I’ll be sure to post any other bugs I think find
@fizzyflower - I fixed creation of the bundle, it seems like it got broken by accident somewhere in the past. Note that adding brush tips from .abr files still doesn’t work. (And I haven’t checked the inside folders). But for example embedding tags should work just fine.
The fix should be in the current daily build, I think.
I tested mostly the nightly build linux appimage with that large brush pack I created. Before I imported a new bundle, I completely deleted the resource folder so I could test if it really worked. What I observed is this:
- Krita actually does load the brush tips and patterns that are within subfolders in /brushes/ and /patterns/. When I open the brush editor I can see them. But they don’t automatically work with brush tips or patterns in subfolders that was created with them unlike Krita 4. They default to using the “triangle.svg” brush tip
- When I try to create a bundle with brush presents, brush tips, or patterns that are within another subfolder in the resource folder, it doesn’t work. Although they appear to be technically in the bundle from looking at it’s filesize, when you import the bundle into Krita, none of the brushtips, presents, or patterns, show up in the program. It’s blank when you look at them from local resources
- When I create a bundle that has one resource like brush presents within a subfolder and another resource like brush tips in no subfolder, the brush presents will not appear and the brush tips will appear after I import it into Krita.
When I finally created a bundle that had none of the resources in subfolders, I was able to successfully create the bundle. All of the brush presents seem to work with no problems. And creating another bundle from the resources in the bundle worked too. I can see that the tagging works too. I just wish that the bundle creator GUI had the search bar that the “manage resources” section has too
Hmm can you elaborate?
I guess there might be a problem because it only remembers filename, but not the path, so then it cannot actually find the resource… so it thinks it should be in /brushes/ despite the fact that when the database was created, it was inside a subfolder…
Thank you for testing; it’s really really helpful, I’ll check how to fix it
This is interesting… can you share the bundle, maybe? Or at least check if the preset is there in the bundle? I wonder if it even got saved there, or Krita noticed there is some issue with brush tip and just didn’t save it… weird. But thanks!
Oh yes - I plan to add there the same exact widget as in the resource manager. However, the string freeze is in two weeks, so I’m afraid it might not be ready for Krita 5.0. I prefer to have all things working than pretty, at least for now. You can see in “Artists Feedback” there is a design for layer styles manager; it’s not implemented yet either. But I’m already quite happy with new things that got implemented (like the new resource manager) so I hope it’s already better than it was (if you ignore some bugs and issues, that I hope to get fixed before Krita 5.0 ).
as unlikely as it seems to me (and because nothing is impossible), but when I just read your report (see quote) I suddenly had the impression that you might not be aware that you can open *.bundle files (Krita bundles) with any ZIP program, as they are simply ZIP files with a different extension? So it is enough to change the file extension to *.ZIP to view the contents with a ZIP capable unpacker to check the contents.
Sorry! I meant that brush tips and patterns that are in subfolders don’t automatically work with the brush presents that they were created with. In Krita 4, if a brush tip or pattern that was assigned to a brush present is within a subfolder, it will work. This doesn’t work in Krita 5.0
Here’s the unsuccessful bundle.
It’s about the same filesize as the successfully created bundle and has the same resources in it.
When the bundle was created, the patterns and brush presents used were within a subfolder (example: /krita/paintoppresets/subfolder/). The Brush tips were not in a subfolder. So when the bundle is installed you can see the brush tips in the resource manager but the patterns and brush presents don’t show up.
I’ve also noticed in more testing that when there’s resources that are within a subfolder, it disappears every time Krita 5 is restarted. Then for it to appear again, Krita will need to be restarted again.
I hope that I can see the redesigned bundle manager in a future version of Krita after Krita 5 is released! I don’t think the redesigned bundle creator manager is that important either right now compared to making sure that artist’s brushes will stop randomly disappearing from their tags when they open Krita.
Thank you! I can see in the filemanager that all the presents, patterns, and brushtips are still there even if they don’t all show up in Krita 5 after installing the bundle.
Hi @tiar, The 5.0.0-prealpha creates (backup?) copies of palette files every time you add a colour to a palette.
This happens for the default installed palettes as well as personal palettes.
They are persistent and cumulative and are written to the same folder as the appimage:
Hmm, it shouldn’t happen always, only on switching to another palette or closing Krita… Are you sure it happens always?
And I don’t know why it happens in the same folder as appimage. I’ll check it out, thanks!
I noticed it a few days ago and assumed it was a temporary glitch as part of the development. It always happens now but it’s been a while since I added colours to palettes so I don’t know when it started.
@tiar : Since I define fill patterns as resources, I post here. If there is already a topic for it or it should be better listed in a separate topic please move it, if necessary after creating the new topic.
In Krita 5 (Windows 10) the search function for patterns is missing in the fill layer properties (accessible via the F3 key), in Krita 4 it was available. Given the size of my pattern collection, this is very “inconvenient”.
Probably it was just forgotten and is not a bug in the strict sense.
Krita 5 build from today
It’s a bit more complicated than I originally described:
Personal palettes and default palettes are multi-duplicated in the appimage folder.
Default palettes are also duplicated in the resources folder.
What I meant by “it doesn’t happen always” was: it doesn’t happen as soon as you add the color, but in some other cases. The files you see are “versions”. The theory is that a new version is saved when you: 1) switch to another palette, 2) save it manually using the save icon, 3) close Krita. Would it be possible for you to check if it works as I described?
(The saving into the appimage folder is obviously some kind of a bug though).
And if it works as I described, is it fine if it happens only in the resource folder? If not, what would be better solution (considering that it was made to make changes to palette “safer”, it’s like with any other resource now, if you overwrite, a new resource file is created instead of replacing the old one; only layer styles work weirdly)? Note that in future versions, though not 5.0 (couldn’t find time to do it yet ), there will be a button saying “Delete backup files” and it would delete all the older versions.
For the personal palette ‘ahab-1’, if I add four colours to it, then each time I add a colour then an index numbered copy of ahab-1.kpl is made in the resources palettes folder.
For the default palette ‘concept-cookie’, if I add four colours to it then an index numbered copy of concept-cookie.gpl is made in the resources palettes folder.
These index numbered copies are persistent between sessions.
The last time I tried this, it was only the default palettes that had many copies in the resources palettes folder. This time, I tried it with a fresh resources folder and had many personal palette copies.
It may be that my previous manual deletions of the ‘excess’ palette files had confused the SQLite resources management. But I’m guessing here.
If it only happens once per session, for each changed palette, would multiple sessions that involve palette changes give multiple indexed copies of a palette file?
What would be the process for ‘restoring’ the previous palette state if you wanted to do that? Is that the purpose of maintaining previous versions?
Ideally, you don’t need to look in the resources folder and everything is taken care of by the Resources Manager and the content is displayed in the dockers (and Brush Editor for the brush-tips) and can be added/created and deleted from those places.
However, I’m quite used to manually adding or deleting individual resource items or editing blacklist files to get ‘deleted’ resources back.
Would that be a bad thing to do when it’s all managed via the SQLite database?
Just for the record: in the previous sentence you said “then each time I add a colour”, but here you don’t add it; do you get 4 copies of the palette or only 1?
It will be implemented, but it isn’t yet, but it’s planned…
The database should see that you changed something and kinda refresh… but… this needs extensive testing, tbh. Even the things in GUI need extensive testing, and they are prioritized over actions in the folder.
I should have expressed myself more precisely:
If I add a colour to a palette, a copy of the palette file, as an incrementing index numbered copy, is immediately written to the resources folder.
This happens every time I add a colour to the palette.
If, in one session, I add four colours to a palette file, this results in four index numbered copies of the palette file being present in the resources folder (as shown in the posted image earlier for the appimage folder).