(I'm using Krita 4.1.0-pre-alpha (git d0e6714) on Ubuntu 14.04)

Should a bundle stay inactive at the next start?

Example:

1) menu > "Settings" > "Manage Resources..." > move the bundle to the "Inactive Bundles" pane
2) restart Krita

Actual Results: the bundle returns active at next start.
Expected Results: I wonder if the bundle should remains inactive instead ?

Thanks


EDIT: This doubt arose when I tried to disable the "Krita_3_Default_Resources" bundle, which is active by default in the forthcoming Krita 4.
Documentation says: "If you don't need the bundle you can temporarily make it inactive by selecting it and clicking on the arrow button, this will move it to the Inactive section.". I guess my doubt is about the meaning of "temporary" in the sentence...

It needs to stay inactive, if it isn't doing that, there's something odd going on.

Could you check what is happening with the resource bundles blacklist file in your resource folder?

Hi, and thanks for the reply.

TheraHedwig wrote:Could you check what is happening with the resource bundles blacklist file in your resource folder?

I've checked the resource folder but it seems that the bundle blacklist file is not even generated.

EDIT: I've just created a new report here: https://bugs.kde.org/show_bug.cgi?id=391750

I tried this on krita-4.1.0-pre-alpha-d0e6714-x86_64.appimage and there is some strange behaviour associated with activating/inactivating the Krita_3_Default_Resources bundle.

I found that the bundle source location will not be written to the kis_resorcebundles.blacklist file unless another bundle has been made inactive (which puts it properly in the blacklist) and then activated (which removes it from the blacklist).

Then, the Krita_3_Default_Resources will be added to the blacklist. However, it is located in a /tmp mount with a randomly generated name, at each restart. So, it would seem that, at each restart, it can't be recognised as inactive.

Using the 'trick' of forcing writing to the blacklist file, by means of inactivating then activating another 'normal' bundle, you can get successive Krita_3_Default_Resources bundles written to the blacklist file as the following example shows:
.................................................................................
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE m_blackListFile>
<resourceFilesList>
<file>
<name>/tmp/.mount_krita-TN2KOV/usr/share/krita/bundles/Krita_3_Default_Resources.bundle</name>
</file>
<file>
<name>/tmp/.mount_krita-RCppO4/usr/share/krita/bundles/Krita_3_Default_Resources.bundle</name>
</file>
<file>
<name>~/.local/share/krita/bundles/Rad's.bundle</name>
</file>
</resourceFilesList>
...............................................................................

I used Rad's bundle as the 'normal' bundle to do the inactivate/activate thing to force writing of the blacklist.
I assume that at the next restart, the /tmp/.mount_krita -abcxyz/..... name will change and so the bundle will not be blacklisted.

That's what it seems like anyway.

Yes. the ".mount_krita-TN2KOV" will change, so it's a temporary solution.

I wonder why Krita needs the full absolute path of the bundle; it's not like someone will try to blacklist a bundle outside of the bundle folder?
Why this under is not sufficient to blacklist any bundle with this filename ?...

Code: Select all

<name>Krita_3_Default_Resources.bundle</name>