Since the bed-temp (for example) might be unfluenced by unused but (probably accidentally) enabled extruders, we want to be able to warn the user of such.
part of CURA-12622
This could cause slicing to hang forever until settings where changed. So stop too-early slicing, but keep a memo of wether we've already been requested to slice in the initialization interval, so auto-slice doesn't fail either.
CURA-11815
Following the removal of the get/setMessage methods in the Job class, the StartSliceJob has not been updated and still used them. We now use a specific variable for storing the disabled extruders and properly display them.
CURA-11904
... 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.
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.
The slicing engine should never crash. If it does though, it's best to show something to the user. Otherwise the slicing process just halts and the user will wait a long time for it to never finish.
Contributes to issue CURA-6568.
This reverts commit 35d6aad6cd.
This is causing a very weird crash when autoslice is enabled:
2021-01-28 12:12:35,379 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [66]: An uncaught error has occurred!
2021-01-28 12:12:35,379 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: Traceback (most recent call last):
2021-01-28 12:12:35,379 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: File "/home/trin/Gedeeld/Projects/Cura/plugins/CuraEngineBackend/CuraEngineBackend.py", line 270, in slice
2021-01-28 12:12:35,380 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: self._createSnapshot()
2021-01-28 12:12:35,380 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: File "/home/trin/Gedeeld/Projects/Cura/cura/Utils/Threading.py", line 31, in _call_on_qt_thread_wrapper
2021-01-28 12:12:35,380 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: return func(*args, **kwargs)
2021-01-28 12:12:35,380 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: File "/home/trin/Gedeeld/Projects/Cura/plugins/CuraEngineBackend/CuraEngineBackend.py", line 254, in _createSnapshot
2021-01-28 12:12:35,380 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: if not CuraApplication.getInstance().isVisible:
2021-01-28 12:12:35,380 - CRITICAL - [MainThread] cura.CrashHandler.__init__ [69]: AttributeError: 'CuraApplication' object has no attribute 'isVisible'
The property exists all right. It's in the dir() of the CuraApplication instance. PyCharm's debug mode also gives a traceback when trying to evaluate the property. It clearly thinks it's there, but then it's not or something. Very weird. We need to take a better look at this than this quick fix.
