Problem with making a brush with brush tips from bundle resources

I guess it’s not something you can fix with the current resource system, I just hope it’s being taken care of with the rewrite.

It’s simple. When you
1 create a new brush with a brush tip(predefined) from any resource bundle
2 and then deactivate the bundle or delete it
3 the new brush doesn’t load a tip from the next startup. It’s missing.


Isn’t that to be expected?
What do you think should happen in that situation?

I think the next version might just not show this brush preset at all in this case… I’m not sure actually, what do you say @halla?

Um… May I ask why it is expected?
It’s creating a completely new brush separated from the bundle, so I think it’s natural for that brush to be independent from whether the bundle is active or deactive.

What I can imagine would be : Saving the specific tip from the bundle to the default resource data if there’s a new brush created based on that tip.

Are you imagining creating a new brush for/inside the bundle? It makes sense if that’s the case, but I didn’t even know that was going to be able to be possible(if that’s the case you are referring to.). And that would be a separated topic from this thread.

It’s expected (by me anyway) because the brush preset is using (probably via a pointer of some kind) an asset (brush tip) in a bundle. If that bundle is deactivated then it is not available for use and so the brush preset can’t be provided with the asset it is supposed to use.
This is a technical explanation of why I expect it to happen.

The simplest way to deal with this, as @tiar indicated above, would be to regard the brush preset as ‘invalid’ in this situation and not show it in the brush presets docker.
At the moment, you have the brush preset icon showing but with a cross overlaid to indicate that it can’t access the required brush tip but this does at least give an indication of what’s happened and a clue as to how you might get a working brush preset back in action. That depends on people being aware of this convention which may not be the case for many.

I’m not imagining what you suggested in your final paragraph. I prefer to keep things simple if possible.
Whatever alternative behaviour you’d like will of course have to be discussed and explained before any changes are made, if any, and that seems to have started :slight_smile:

1 Like

Yes, technically I understand why it happens and it’s just like as you explained. That’s why I said I guess it’s not something you can fix with the current resource system.

It makes it a bit bumpy to create brushes. When you deactivate some bundles after dozens of brush creations you’ll see a mess. Which means, you basically need to keep the bundle and have it active forever if you want to use the brushes you created with any tips from that bundle(Unless you manually unpack the bundle zip and find/load the individual asset each times to create brushes).

I think that the current situation and behaviour is very suitable for many if not most users, especially new users who want to draw/paint without worrying or wondering how it all works. (Disregarding the bugs in the tagging system etc.)

If you’re very interested and committed to making your own set of resources that are independent from the default bundles but still building on the assets of the default bundles, then you can do that.
When krita is running, you can copy the default bundles out from the temporary folder and then unzip them and pick out the bits you want and then treat them as personal resources to be manipulated and organised as you wish. It would be a good idea to deactivate the default bundles if you do that to avoid naming clashes.

The first paragraph and the second paragraph are the two extremes of use and both are quite simple, though the second requires a lot more work.

In between is more complicated, which is where you are. I have no opinion about what is best and how things should change if at all.

1 Like

I think you do have an opinion about what is best. Since you said the current situation and behaviour is very suitable for many.

When we use the word ‘suitable’ we have to be a little careful. When I first suggested the flow/opacity change in the KDE forum in 2016 there were many developers and users who defended the old behavior saying that’s ‘already enough’. And everybody liked the new behavoir when someone actually came up with the patch.

I am not saying I’m right here. I believe I understand the reaction considering the devs have been struggling with a very tiny budget. But plz note that these are just suggestions, not blaming.

I believe the solution(mechanism-wise) to this would be

  • Make the default brushsets(in this case, ‘Krita_4_Default_Resources’) not as a bundle and just treat them as individual brushes.
  • Make sure a new brush created has a brush tip data separated from any bundle.

This will reduce confusion if new/light users want to play creating brushes without worrying about ‘missing assets’.

There might be reasons why the default brushsets is made as a bundle. But I don’t think that must be something fundamental. If it’s about resetting the brushtips to the default, I think krita can store the defualt bundle data somewhere and load them after removing everything.

1 Like

There are changes on the horizon for the resources system and I’ve had little if anything to do with those discussions because I regard them as over my head and I really do have no opinion about what is or will be best.

Your ‘solution(mechanism-wise)’ would work but would have problems, as you’ve spotted and proposed further solutions for.

I’m just an old engineer who’s happy to have something cool, fun and useful to play with and I’ll settle for what I’m given, sticking my opinion in now and then, as I do.

1 Like

Sure. But in the case you really don’t have any opinion on that I don’t think any discussion can happen because there’s nothing to discuss. :thinking: If your purpose was to explain how the current system works, I appriciate it, although I already knew…

Well, I already added a link to this discussion to our working document in the “Design Decisions” section. It is a valid concern, but I don’t know how to resolve this.

Btw, it is already sure that if you make a bundle with presets, the brush tips will be included there, too: so the easiest solution that doesn’t require any new work from us would be: just make a new bundle with all your presets, then disable everything else and import that bundle. Although that would require disabling the Local Resources, which would be not great. So I guess it would be better to just remove (which means: “mark as inactive”) all of the presets that went into the bundle… Hmmm this is a bit of work :confused:

Correct me if I’m wrong.

At this point I get the feeling that, in the current system, technically every brushes ‘borrow’ their tips from outside(e.g bundles, resource folder included in krita). And that’s where the problem arises because a ‘brush’ file doesn’t have its tip data for itself.

If that’s the case, I think it’s better to

  1. make every brushes(.kpp) have their own tip data.

  2. make the resource folder(which stores brush tips) a library database(so to say) for people to add/remove tips they want for brush creation, like a vector library or a material library.
    *Which means, you can use the tips from the library to create new brushes but those brushes(.kpp) will have their own tip data independent from the library.

And then this will become possible :

I think this approach would be the cleanest to avoid all the further complications, but it’s your choice. :slightly_smiling_face:

tbh I expect an explosion of new brushes after releasing Krita 5. And I hope Krita doesn’t produce many confused people and bug reports related to this.


One concern over this(from a user’s perspective who doesn’t have any programming background), is that it would make it longer to load all the brushes at Krita startup, but I’m not sure. :neutral_face:

Well it is making a derivative brush from a brush made from scratch? Well it might be the case of those bundles but with others it might create some copy right issues? Even though they might be free but not cool to copy? I imagine this to be the only reason not to do it. Or else a full copy would be a good idea. But sounds like a conservative move as is.

What copyright issue exactly? If you mean creating a brush from a preexisting brush in a bundle, it’s technically already possible as others mentioned above.

Images can be copyrighted. A reference is different from a copy.

By ‘image’ do you mean tips? Yes, it is technically already possible to make independent brushes using tips from any bundle. (As mentioned above, you need to unpack the bundle zip and load the tips manually.)

If you think it’s a ‘copyright issue’ for krita to allow that happens, it means Krita already has a problem.

Hmm. But maybe it’s possible to say my suggestion makes the copying process easier.

I’m curious. Has there been any actual copyright claims related to this? tbh I doubt it because I’ve never seen anything like that in other painting application communities. But maybe I’m missing something here.

no because it already exists in your krita system.

a reference is not a duplicate/copy! it is just reusing the same information (a derivative) of what you already got so it does not exist without the original. I think for you can think of it more as a tweak of the original than a “new brush” on your system. that might be easier to understand.

that is why once you uninstall the bundle (original) it disappears there is no reference in your system. the whole point of this thread…

If anything I think allowing it causes less people to make brushes as all your work would be purely pirated away just because the system works that way. Making good brushes requires work too and not everyone might be okay with that. Krita settings however only exist because of krita itself so those kinda fall flat as they are a derivative of Krita and created with their engine and that is what remains on your system.

Again, I know this! And what I’m saying is that Krita already allows ‘copying’, technically.

Moving on,

1 if what you’re worrying is that my suggestion would encourge more people to ‘pirate’ brushes, I honestly think it’s an overreaction because it basically has nothing to do with how the application works. And no major painting application intentionally try to prevent the brush piracy from happening on this level as far as I know(Correct me if I’m wrong).

There are priced materials and priced brushes for sure, and all you have to do is just copying the original file and share it if you want to ‘pirate’ it. It doesn’t have anything to do with the application itself.

2 If it’s about more private, subtle usage like duplicating or making something new out of preexisting brushes, I can see why some people would feel that their work is getting stolen, but I still believe it would do more good than harm.

I’m open to further discussions.