* Fix PermissionError when importing http.server
Instead of crashing, now it'll just not start the server. This means that you won't be able to receive the response from the log-in so you won't be able to log in. The browser gives an error that it can't find the page on localhost. But at least it doesn't crash.
Fixes crash CURA-3Q.
* Log an error when the HTTP server can't be started
Contributes to crash CURA-3Q.
* Indicate that types are optional
Attempt to fix the typing issue with MyPy. I can't run this locally so the CI server will have to tell me if this fixed it.
Contributes to Sentry issue CURA-3Q.
See CURA-3M in sentry. It most commonly happens with the anycubic,
since it had some weird stuff with it suddenly supporting materials.
This change will make it so that no crash happens. Old profiles will still have
an empty material. This isn't really an issue, since the interface will mark this
as an error (prompting users to switch).
Prevent unpacking of possibly spoofed backups (as a last line of defence if other security has failed).
Zips with partially known content are a lot harder to spoof.
Thanks WhiteHats :-)
It's mostly a theoretical problem, but 16 could theoretically be brute
forced. Bumping it up to 32 won't break anything, but it does make it
exteremely unlikely that it gets broken
Now that we subscribe for all situations where a package is installed,
it makes sense to watch package installs and create a 1:1 relation that
way. Prevents code duplication.
CURA-7099
If it's not used that way we want to know about it and fail.
If plug-ins use it this way, the plug-in won't get initialised so it'll be as if the plug-in is disabled or that function doesn't work.
Contributes to issue CURA-7135.
The setting print_sequence was not being resetted to all at once
whenever the 2nd extruder was reactivated.
This commit fixes that by explicitly resetting print_sequence
when reenabling an extruder, if it has been changed by the user.
CURA-6914
It could happen that the selection pass is not initialised because you're right clicking on the screen before the first render has happened.
Hopefully this fixes#6976.
The container registry was incorrectly being searched with a
variant_name == None, which always returned an empty printer-specific
materials list. As a result, the generic material settings were always
being loaded if there was no variant specifically indicated inside
the fdm_material file. The printer specific values were consistently
being ignored.
This commit fixes that by removing the search with a variant_name==None
which correctly returns the printer-specific materials list while
loading the materials from the variant nodes.
CURA-7087