Persistent Post-Processing Scripts #3229
Conversation
Maybe one day someone will encounter it again and decide to fix it, but I'm lazy.
If you switch and such, it'll load these scripts back in. They are now persistent.
This causes the button to display immediately on start-up if there were any post-processing scripts in the current machine. If there weren't, then no button will be shown (as specified in the QML). Previously the QML was only loaded first upon clicking the item in the extensions menu. Now it has to be loaded on start-up in order to display that button.
Just some stuff that I saw and thought were missing.
So that you're not getting into a state of viewing an invalid index. If you switch to a printer with 0 scripts attached, the index is still invalid, but it won't display anything then so you're okay.
This is more efficient, because we're not writing every time you modify the list of scripts. It's also more complete, since if you don't modify the list of scripts but just modify one of the settings, that setting change also gets written to the stack after closing the window.
I think this IDE isn't configured correctly yet.
|
This implements #2796, nallath/PostProcessingPlugin#46, #2854, #3133 and #3217. |
|
Developers, see issue CURA-4623. |
Oops, forgot about this one.
|
Damn, I want this feature so heavy since a long time... PLEASE make it into CURA3.3!! |
|
merge conflict: loadAllScripts needs to be rewritten :-( |
|
The merge conflict is resolved now. |
Removes some code repetition.
Not for every call to loadScripts.
|
This introduces a bug where newlines in the replace string are mangled/removed/lost. Example:
Now save & restart Cura. The newline will be missing. Or the UI simply refuses to display the whole string altogether end empties the field. |
Because they are stored twice: Once in the CFG of the script, and once in the CFG of the machine instance. Fixes an issue reported here: #3229
|
Thanks for the bug report. I've fixed that now in master, so it should be fixed in the next release. |
|
Can we maybe have just a checkbox in the printsetting menu, there we can enable or disable all postprocessing altogether? |
The currently advised workflow (since post-processing scripts are stored with the printer) if you use post-processing scripts that are specific to a print rather than a printer, you can switch them on or off by having two printers and switching between the two. This way you won't have to go into the post-processing scripts list and delete all of them. The use case is small though, since if your post-processing scripts are specific to the print rather than the printer, then there's little reason to store them for the next print anyway; you'll need to remove them for the next print usually, unless you're printing many of the same thing but with small adaptations.
You mean the prime tower? There's a set of settings for that.
Which workflows are user friendly is a function of both the size of the use case (how often is it used) and complexity of the system. We've not yet implemented per-layer settings but we're keeping it open as a possibility for the future in our architecture. For now, ChangeAtZ is a passable workaround but even there we don't see a lot of usage yet. If you actually have an issue with this, please open up a ticket and fill in the template! |
This change will cause the added post-processing scripts to be saved in the user's configuration. Post-processing scripts were one of the few things that did reset when you restart Cura. No longer!
Post-processing scripts are added on a per-printer basis instead of globally. This choice was made because the scripts are quite often printer-dependent, compensating for broken firmware or adding small features to the g-code in the same way as the normal settings.
As such, the post-processing scripts will be removed when you switch to a different printer, and reappear if you switch back. You could view them as global settings.
Implementation details: The post-processing scripts that were added and the settings that belong to them are stored in the metadata of the global stack (as serialised config files). They can never cause a name clash with existing settings (which is a requirement also because you can add multiple of the same script). Their order is retained. It also does not require any version upgrade because the metadata is optional. If the metadata entry is missing it will cause the script list to be empty. If a post-processing script is changed in later versions to have a different setting name, that setting will reset to its default value unless a version upgrade deals with the change, just like our normal settings.