PostProcessingPlugin: Inconsistent scripts location when running AppImage

[jypma]

In #2645 (and, linked from there, nallath/PostProcessingPlugin#48) it's suggested that when running from the (immutable) AppImage, one can add custom scripts to the PostProcessingPlugin. The actual location used may however depend on the concrete linux distribution and/or python.

For arch linux, ~/.config/cura/3.2/scripts seems to be auto-created and used; for other distributions, ~/.local/share/cura/3.2/scripts may be correct. It should be noted that, even on arch, other user data files (like the log) indeed are in ~/.local/share/cura/3.2/.

Documentation could be updated to reflect this; however, one could argue that the more appropriate script location is indeed ~/.local/share, and not ~/.config.

Application Version
3.2.1

Platform
Linux, Arch

[fieldOfView]

I’ll create a PR tomorrow

[fieldOfView]

See #3359

[JPFrancoia]

I'm on Archlinux as well. Cura breaks at almost every update when installed from the package manager, and I would like to use the appimage as a "long term support" version of Cura. Since the libraries are embedded in the app, it won't break each time pyqt, qt or any other dependency is updated with the system. I rely on Cura for my work so it's important I can trust it.

The problem is I sometimes need to use custom scripts (mainly the PauseAtHeight plugin, which was buggy until I fixed it, see nallath/PostProcessingPlugin#59).

I don't understand what's going on with the directory structure of the AppImage. When it's started from scratch, it creates a directory ~/.local/share/cura/3.2, with the following empty folders:

cura.log
variants/
user/
themes/
quality/
plugins/
materials/
machine_instances/
extruders/
definitions/
definition_changes/

If I copy my baked up files in the corresponding directories, the appImage loads them normally (profiles, machines, etc). But not the plugins.

If I copy my plugins in the plugins directory, they are not loaded. Which is weird, because all the other parts are loaded properly.

Also I don't think the location of the scripts should be ~/.local/share/cura/3.2/scripts. I think the AppImage should load the plugins in the pluginsdirectory.

[fieldOfView]

plugins != scripts

PostProcessing scripts should be loaded from ~/.local/share/cura/3.2/scripts, but currently they are loaded from ~/.config/cura/3.2/scripts. #3359 fixes that. It might be merged before 3.3. It might not be. At this point, I don't know anymore.

Plugins such as the OctoPrintPlugin that are downloaded from the plugin browser go into ~/.local/share/cura/3.2/scripts.

[JPFrancoia]

a) I'm trying to load a custom PauseAtHeight plugin from ~/.config/cura/3.2/scripts/PauseAtHeight.py, nothing happens, the AppImage seems to always use the same PauseAtHeight in Extensions > Post Processing > Modify G-code.

b)

plugins != scripts
PostProcessing scripts should be loaded from ~/.local/share/cura/3.2/scripts

I'm confused. I think they should be loaded from cura/plugins/PostProcessingPlugin/scripts, that's the path used in the official repo for Cura.

EDIT:
a) -> I can now load the script, I just had to rename it, and change some lines in the python script.

[fieldOfView]

b) No, as I said, scripts should be loaded from ~/.local/share/cura/3.2/scripts, but currently they are loaded from ~/.config/cura/3.2/scripts.

resources/plugins/PostProcessingPlugin/scripts is the path inside the app bundle, but as you know you cannot easily add scripts there.

[JPFrancoia]

resources/plugins/PostProcessingPlugin/scripts is the path inside the app bundle, but as you know you cannot easily add scripts there.

Well I don't know why haha. Why couldn't we load scripts from resources/plugins/PostProcessingPlugin/scripts ? It would make sense to me, since we can load for example from resources/machine_instances.

What's the reason ?

[fieldOfView]

Because that would be two needless levels of folders.

[JPFrancoia]

Ok. I suppose it makes sense, if only the scripts from PostProcessingPlugin are concerned.

Thanks, I can now use the AppImage and my custom scripts, it should make my workflow more reliable.