Otherwise it would crash with a BadZipFile error. We should be robust against that. This will trigger a generic message that we couldn't read that file to the user, and put more information in the log.
Fixes Sentry issue CURA-NH.
The code was moved to uranium, so no need to test them in a plugin.
In some cases they were also testing a specific implementation artifact and not
actual expected behavior.
CURA-7388
If it happens at just the wrong moment, Cura could crash. Hopefully no longer, though I fear that now it would maybe crash somewhere else with the same error then. We'll find out through new error reports, I hope.
Fixes Sentry issue CURA-K8.
The plug-in ID is set once the register function is completed, so after initialisation. If the _createSocket function is called in between, Cura would crash.
I don't know why the _createSocket function would be called in between, but possibly another plug-in causes an event that calls it since it's being called on many events (everything that would initiate a reslice).
Fixes Sentry issue CURA-K4.
This could happen because a material is deleted right at that moment, since the SendMaterialJob is done on a separate thread.
Fixes Sentry issue CURA-JZ.
Properly close the welcome screen if the user has signed in and has
cloud printers linked to his/her account. If he doesn't have any, move
to the next page of the welcome wizard.
CURA-7019
The welcome dialog was not closing because when pressing the "Sign up"
button in the cloud page, a signal is emitted that is forcing the
welcome wizard to move to the next page. Therefore the currentPageIdx
was detected as cloud_page_idx+1.
This commit fixes the check by checking whether the welcome dialog is
in the page after the Cloud page.
CURA-7019
If the user signs in during the welcome process, if he/she has cloud
printers connected to his/her account, then the welcome wizard will
close so that the user will not be asked to add local printers.
CURA-7019
The renderer isn't active when the view is activated. As such,
no opengl context *ever* exists. In some cases this might cause it to get
stuck in an indefinate loop.
The comments around it are explaining a situation that can't occur. The activateView
event of SolidView isn't triggered when switching to another view...
Otherwise if a retracted move had a different Z coordinate, this would not be put in the final print. It's pretty simple to extend it this way.
Fixes#7458.
