Bug 443875

That's how overwrite works now in Krita 5.0... I mean, it makes a new version of the resource. There has been quite a bit of heated discussions on that topic, including "but what if the user first changes this brush tip to something else, and then imports a set of brush presets that use that tip, and they don't look like the creator promised because the brush tip is changed now" etc.

I wonder if it would be a big trouble if it still worked the way it does now in Krita 5.0, and you'll have to use a bit tedious workaround of Saving As to some other place and then move the brush tip to the resource folder and restart Krita, and we'll think of some good way to resolve those issues from GUI in Krita 5.1?

Ok, so let's simplify the problem to a simple user scenario:

I do a draft brush tip in Krita (using '+Import', '+Stamp', '+Clipboard'). I create with this new brush tip a brush preset. But then, I see the brush tip isn't contrasted enough. I want to keep improving it. What is the right way to do it in Krita 5.x?

In theory, you should just save as you did, and then use it to create a new brush preset. It should show up in the Brush Tips widget.

Now I see that it only works once (so if you first create a brush tip, then edit it and save, then it works, but if you save again, it won't work). Probable reason:
It uses `QVector<KoResourceSP> resources = model.resourcesForFilename(QFileInfo(path).fileName());`. This only looks for a current active resource which *current* filename is the same as the as the provided filename. Here the problem is, it looks for `Tip_A.gbr` but the filename of the `Tip A` resource is now `Tip_A.0001.gbr`. I guess either changing the filename of the document, or using a better function (that looks up resources with filenames no matter which version they were) would fix this issue.

So yeah, there is a very clear bug and regression there as well.

Good to know. Thank you for your investigation. 

Btw, I'm not against (at all) if workflow for brush creation happens in the future only via Krita interface (and so, if it prevent user to do mess in files/database complexity).

A wish for later, a 'edit' command somewhere to open the brush tip directly as a document in Krita. This way, user might not be exposed to filenaming versioning strategy of Krita in backstage.

I fixed the main issue here: https://invent.kde.org/graphics/krita/-/merge_requests/1116 which means, now this workflow should work fine.

That means, if you follow this workflow:
- open the gbr file
- edit it
- save
- make sure the name is correct
- edit more
- make sure the name is correct
- etc.
Then you'll end up in this situation:
- your old brush presets would use the old brush tip (Ok, I'm not 100% sure of that because there has been lots of sheningans with md5 sums recently, but last time I understood that part of Krita, the assumption was, it should work. In the worst case scenerio, all of the presets created in recent Krita 5.0 builds should work, because they embed their tips)
- the brush tips chooser will only show you the brush tip with the changes you made. So if you want to create a new brush preset, you only have access to this tip with new changes.
- yes, the brush tip file will be named weirdly, "brushtip.0014.gbr" or something like that, according to the version.

---

There are still three issues left, which for me seem a bit "maybe after Krita 5.0":
- the document is still marked as modified, despite just being saved (it would be easy to fix but I would like to first know where standard documents are marked as not modified before I fix it here...)
- if you open a version that is not the first one, for example if you open "brushtip.0014.gbr", it will ask you to name the brush tip and the suggested name is "brushtip.0014", not "brushtip"
- you can't simply overwrite over the brush tip file without making a new version

Also something I noticed, but probably is not a regression - the "Auto" part of spacing is forgotten before saving.

---

@David Revoy, please let me know if this compromise (main issue fixed, minor issues left) is good enough to warrant removing "release_blocker" tag from the bug report.

Hi, Good enough to me and thanks @tiar for all the detailed description of the behavior. 

I believe tweaking inside the preferences directory is a move only advanced user does; and will disapear in time (except maybe only to move pref, move files). Most manipulation of the resources and editing might happen in Krita directly in the future (and I'm fine, and would encourage that).

Ok, so I removed the "release_blocker" tag.

Also just to be clear:
- if you don't keep the name the same, it's not a big problem because it will still replace the old unchanged brush tip, it will just look uglier in the brush tip chooser because the name shown will be "brushtip.0014", and not "brushtip". But it's only aesthetic difference. (I realized I said "make sure the name is correct" but I haven't said what would be the consequence if you forget/change name/etc.)

Git commit a6fbd9de7b2f5b009952e5a922ed037c6c034971 by Agata Cacko.
Committed on 22/10/2021 at 12:56.
Pushed by tymond into branch 'master'.

Fix updating brush tips or other resources

Before this commit, if the user created a new brush tip,
then opened it in Krita, edited, saved, then edited and saved again,
Krita would save that brush tip over the original brush tip,
leaving a backup file behind, circumventing the versioning system.
This commit ensures that Krita recognizes the need to update the
resource using the resource system.

M  +1    -0    libs/resources/KisResourceCacheDb.h
M  +6    -6    libs/ui/KisDocument.cpp

https://invent.kde.org/graphics/krita/commit/a6fbd9de7b2f5b009952e5a922ed037c6c034971

Git commit 7e93354772f9693570ab01225eb317718cb0aea8 by Agata Cacko.
Committed on 26/10/2021 at 18:22.
Pushed by tymond into branch 'krita/5.0'.

Fix updating brush tips or other resources

Before this commit, if the user created a new brush tip,
then opened it in Krita, edited, saved, then edited and saved again,
Krita would save that brush tip over the original brush tip,
leaving a backup file behind, circumventing the versioning system.
This commit ensures that Krita recognizes the need to update the
resource using the resource system.

M  +1    -0    libs/resources/KisResourceCacheDb.h
M  +6    -6    libs/ui/KisDocument.cpp

https://invent.kde.org/graphics/krita/commit/7e93354772f9693570ab01225eb317718cb0aea8

A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1473

Git commit d69cf1960352612f12095aee62c1632b45dd6caa by Dmitry Kazakov.
Committed on 15/06/2022 at 09:24.
Pushed by dkazakov into branch 'master'.

Fix issues when saving the bruhs into resource folder

The patch fixes leftovers of bug 443875 of Krita behavior when
the resource is saved directly into the resource folder:

1) The "modified" flag is now reset (and well as modification date)
2) The name of the image is updated to the real versioned resource
   filename
3) The bursh **name** (the one saved **inside** the resource) is now
   kept the same and doesn't include the version suffix. It is done
   by passing the resource name into the saver using exportConfiguration
   object.

M  +6    -0    libs/resources/KisFolderStorage.cpp
M  +1    -0    libs/resources/KisFolderStorage.h
M  +14   -0    libs/resources/KisResourceLocator.cpp
M  +5    -0    libs/resources/KisResourceLocator.h
M  +5    -0    libs/resources/KisResourceStorage.cpp
M  +7    -0    libs/resources/KisResourceStorage.h
M  +5    -0    libs/resources/KisStoragePlugin.cpp
M  +1    -0    libs/resources/KisStoragePlugin.h
M  +15   -0    libs/resources/tests/TestFolderStorage.cpp
M  +1    -0    libs/resources/tests/TestFolderStorage.h
M  +59   -21   libs/ui/KisDocument.cpp
M  +1    -1    plugins/impex/brush/KisWdgOptionsBrush.cpp

https://invent.kde.org/graphics/krita/commit/d69cf1960352612f12095aee62c1632b45dd6caa

Git commit 77bf57e11f496e2218af7d8e75c114067f173fcb by Dmitry Kazakov.
Committed on 15/06/2022 at 09:25.
Pushed by dkazakov into branch 'krita/5.1'.

Fix issues when saving the bruhs into resource folder

The patch fixes leftovers of bug 443875 of Krita behavior when
the resource is saved directly into the resource folder:

1) The "modified" flag is now reset (and well as modification date)
2) The name of the image is updated to the real versioned resource
   filename
3) The bursh **name** (the one saved **inside** the resource) is now
   kept the same and doesn't include the version suffix. It is done
   by passing the resource name into the saver using exportConfiguration
   object.

M  +6    -0    libs/resources/KisFolderStorage.cpp
M  +1    -0    libs/resources/KisFolderStorage.h
M  +14   -0    libs/resources/KisResourceLocator.cpp
M  +5    -0    libs/resources/KisResourceLocator.h
M  +5    -0    libs/resources/KisResourceStorage.cpp
M  +7    -0    libs/resources/KisResourceStorage.h
M  +5    -0    libs/resources/KisStoragePlugin.cpp
M  +1    -0    libs/resources/KisStoragePlugin.h
M  +15   -0    libs/resources/tests/TestFolderStorage.cpp
M  +1    -0    libs/resources/tests/TestFolderStorage.h
M  +59   -21   libs/ui/KisDocument.cpp
M  +1    -1    plugins/impex/brush/KisWdgOptionsBrush.cpp

https://invent.kde.org/graphics/krita/commit/77bf57e11f496e2218af7d8e75c114067f173fcb