Modified BackendPlugin.py and StartSliceJob.py to allow plugins to decide when they should be used. The 'usePlugin'
method was added to enable a plugin to return a boolean indicating if it should be used or not, e.q.: start up and
connect to the services.
Contributes to CURA-11031
... because the code to terminate them wasn't always called. Especially annoying on Windows, since the sub-program could aparently become a zomboid after termination of the main one(s).
I guess this is still part of the still open CURA-10475 'branch' in a way? There is no other ticket that fits at the moment.
Exception handling in BackendPlugin has been improved by adding
user-friendly error messages for various exceptions. Errors during
backend plugin start or stop will now trigger a message to the user,
providing more context about the cause of the failure. This makes it
easier for users to understand and resolve possible issues. In addition,
the EngineBackend stop function has been modified to forcibly stop all
running backend plugins instead of allowing multiple plugins to run
simultaneously.
This can currently be done by setting the environment variables:
- SIMPLIFY_ENABLE: default disabled, setting this to any value will enable the plugin
- SIMPLIFY_ADDRESS: defaults to localhost
- SIMPLIFY_PORT: defaults to 33700
- POSTPROCESS_ENABLE: default disabled, setting this to any value will enable the plugin
- POSTPROCESS_ADDRESS: defaults to localhost
- POSTPROCESS_PORT: defaults to 33701
Hacky for now
Contributes to CURA-10475
Because we had to rename our Python bindings module from Arcus to pyArcus
we also changed our import downstream (Cura and Uranium). But in order
to limit the changes on our existing code we decided during the review
that we should just import pyArcus as Arcus.
Contributes to CURA-7924
When working with --external-backend, the engine just stops responding, and the operating system cleans up its socket connection. From Cura's front-end we then just see the socket reset. So we should interpret a reset socket to mean that the slicing process was halted.
When not working with an external backend, a crash would always give a response code and we can base it on that instead (as previously implemented).
Contributes to issue CURA-6568.
If the user has auto-slicing enabled, this causes the indeterminate progress bar to appear.
If the user doesn't have auto-slicing enabled, this causes the slice button to reappear.
Both of these indicate that something has caused slicing to be interrupted. The message should make clear why.
Contributes to issue CURA-6568.
