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.
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.
We want to keep it this way so people can still make plugins work for older versions of Cura, like 3.6, where the 'api' field with just a single major version, instead of the 'supported_sdk_versions', which can be either a version-string like '7.6.0' or a list of version strings.
The Cura 4.9 release will have expanded functionality. If you have a plug-in that uses this functionality, marking it as using SDK 7.5.0 will notify older Cura releases that they can't use that plug-in.
This reverts commit 35d6aad6cd7e8a16fbb829dcf8f0b70db12d0028.
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.
Circumvents the snapshot/thumbnail not working when the focus is not on the main window, even if the thread is main. This was an issue when writing a file to Digital Factory becasue that workflow uses a modal window.
Thanks for the idea Jelle!
In some cases, UFP-writing is going to be done when the OpenGL-context is off the main window. This doesn't work. That unfortunately also goes for this commit, but it's a work in progress.
This is causing a crash if self._application is used before the __init__ has finished (or at least passed the definition of self._application). That can happen in this class since some functions are called asynchronously.
It would also make writing tests easier because you can mock the getInstance() function to return a mock object, and only need to monkeypatch that for the function under test rather than also for the constructor.
Fixes Sentry issue CURA-1B5.
