Created attachment 143506 [details] Recompressed copy of "j) WaterC Spread-Pattern" SUMMARY Having Krita 4 and Quiralta's bundle enabled at the same time results in an inconsistent state for a single resource, square_rough.png 0 cf1bc7415af3103afcd82f58a2e6fe18 which ends up disabled across all bundles. This breaks export of Quiralta's "j) WaterC Spread-Pattern" brush. I think (though I am not sure) this is because the stock bundle's manifest lists every brush resource twice. STEPS TO REPRODUCE 1. Get and install Quiralta's bundle from https://store.kde.org/p/1295080. 2. Duplicate "j) WaterC Spread-Pattern" by extracting it, and make sure its MD5 changes so that it is enabled by the resource system. (Oxidize it, or use the attached example.) 3. Attempt to export one or multiple copies of the brush. OBSERVED RESULT Export "succeeds" but "krita.general: No resource for id XXX" is logged, where XXX is the ID for filename "square_rough.png". EXPECTED RESULT No error. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION acd7219d31 (upstream/krita/5.0, krita/5.0) Check pointers before derefencing
Checking Quiralta's brush set's manifest reveals that square_rough is listed three times in total (2x Krita, 1x Quiralta) while another duplicated resource, square_rough_lightgrey, is listed four (2x on each bundle). I guess the resource bundle isn't realising they are duplicated and plays a sequential coin toss with the status column.
dlg_create_bundle.cpp, line 271 or around that, instead of: ``` QString resourceTypeHere = ""; QSharedPointer<KisResourceModel> resModel; for (int i = 0; i < resourceTypes.size(); i++) { res = modelsPerResourceType[resourceTypes[i]]->resourceForId(id); ``` It should be: ``` QString resourceTypeHere = ""; QSharedPointer<KisResourceModel> resModel; resModel.setResourceFilter(KisResourceModel::ShowAllResources); for (int i = 0; i < resourceTypes.size(); i++) { res = modelsPerResourceType[resourceTypes[i]]->resourceForId(id); ``` That way it will search in the deactivated resources as well, so it should find that resource. If it doesn't find it *then*, then we have a bit of more trouble.
That's a good workaround, though the real problem is why adding the same resource multiple times ends up with all instances disabled.
(In reply to amyspark from comment #3) > That's a good workaround, though the real problem is why adding the same > resource multiple times ends up with all instances disabled. The reason is that there are three instances of this resource on my database: > select resources.id, filename, storages.location from resources, storages where resources.storage_id = storages.id and resources.md5sum = "cf1bc7415af3103afcd82f58a2e6fe18"; id filename location 207 3_texture.png Krita_3_Default_Resources.bundle 691 square_rough.png Krita_4_Default_Resources.bundle 946 square_rough.png Quiraltas_SM_Brush_Set.bundle So a query by resource ID will obviously target the disabled instances (since they are the ones linked by the selected resources). I'll apply the workaround in my MR.
I, uhh, respectfully disagree with the notion that it's a "workaround" because it is a fix for a real issue. Here we have two issues: 1) deactivating all resources when you have duplicates (probably caused by the fact that the first one is disabled because it comes from a disabled bundle, then the next one is disabled because it's a second one... etc.) 2) not finding the appropriate resource in the model just because it's disabled or comes from a disabled model. Note that or this to happen you don't need issue (1); it's enough if you make a preset with some brush tip and then deactivate that brush tip (note that right now, all presets embed their dependant resources so you might need to create a preset in earlier versions of Krita for it, though I think the bundle still puts them alongside presets anyway...). Hence, issue (2) is a separate issue from issue (1), and a fix that fixes (2) is still a fix, and not a "workaround for issue (1)". Btw. regarding issue (1), yeah, but see bug 439703. I noted the same issue (1) but Halla closed it. There is a general idea that newly coming resources with the same md5 should be disabled by default, and I guess maybe Halla focused on that part when closing that bug report. I think the fact that this automatic system makes *all* of the resources disabled, if the first one come from a disabled bundle, might not exactly be expected or at least, I wouldn't expect it as a user. But in any case, for that you'd need to talk with her. -- Also about issue 2), you might need to also use: resModel.setStorageFilter(KisResourceModel::ShowAllStorages) to be sure to find the resource that comes from the disabled bundle as well.
Git commit 81c04fcbecfb0bdbd196e56831e7d089160e24fb by L. E. Segovia, on behalf of Agata Cacko. Committed on 16/11/2021 at 15:53. Pushed by lsegovia into branch 'krita/5.0'. Ensure potentially linked but disabled resources can be bundled M +2 -0 plugins/extensions/resourcemanager/dlg_create_bundle.cpp https://invent.kde.org/graphics/krita/commit/81c04fcbecfb0bdbd196e56831e7d089160e24fb
Git commit aca869d1f2e4c2d928f09a2cf12b5de9ab8a02a9 by L. E. Segovia, on behalf of Agata Cacko. Committed on 16/11/2021 at 15:55. Pushed by lsegovia into branch 'master'. Ensure potentially linked but disabled resources can be bundled (cherry picked from commit 81c04fcbecfb0bdbd196e56831e7d089160e24fb) M +2 -0 plugins/extensions/resourcemanager/dlg_create_bundle.cpp https://invent.kde.org/graphics/krita/commit/aca869d1f2e4c2d928f09a2cf12b5de9ab8a02a9