This was a bit more tricky then it at first seemed, since the information wether this is a 'secure version' comes from the user-application and is not known in the Uranium library. This is not normally such a point, but both the theme and the preferences objects are loaded _very_ early in the process, and that information needs to be injected before then. (Well, in the case of the Theme object it's less important, since in the implementation choseen that is now security wise at least only in charge of wheter or not to even show the theme as selectable in the interface, so that it only needs to be aware of the 'security' status any time before the user can see a preference screen, but not nescesarily earlier.)
SEC-255 | CURA-8966
This was recently added. However it appears that we have the same path multiple times in the resources, leading to the resources being found twice. This would normally get removed by virtue of being a set, but not this time since it's a different way of writing the same path.
For the themes, it finds the following paths (in my unpacked directory): {'/home/trin/tempy/cura5/UM/../share/uranium/resources/themes', '/home/trin/tempy/cura5/cura/../share/cura/resources/themes', '/home/trin/tempy/cura5/share/cura/resources/themes', '/home/trin/.local/share/cura/5.0/themes', '/home/trin/tempy/cura5/share/uranium/resources/themes'} For both Cura and Uranium, this points to /home/trin/tempy/cura5/curanium/resources/themes twice. So let's remove this one.
Contributes to issue CURA-9147.
The problem was probably 'max', but cast the others just to be sure. (This would cause the C++ part of Qt to think it wasbeing given a float from Pyton somehow.)
should fix CURA-9196
It seems that in Qt5, the update loop was triggered a lot more often than in qt6.
Since we used that to handle the error checking, this made it so that you sometimes had to wait
for quite some time untill the slicing would start (as that is blocked by the error checker)
Only the X/Y shrinkage influences the convex hull collision area. Not the Z, nor the parent setting.
Also, don't scale the collision area to 0. This value is not allowed by the setting system, so it'd indicate an error when slicing, but before slicing the convex hull gets calculated which results in degenerate polygons. Don't do that. Instead, we'll just let it pretend the scale factor is 1.
Contributes to issue CURA-9091.
material_shrinkage_percentage_xy and material_shrinkage_percentage_z cannot depend on material_shrinkage_percentage otherwise their resolve function will not execute properly.
I noticed that the shrinkage factors do not get the correct value if a wrong nozzle is chosen for a material. However, in that case the slicer will also not slice, so in practice this is not an issue
Relates to PP-77
We've removed a bunch of settings and transformed others. To allow profiles to be checked for these and edited if necessary, we now need to increment this version number.
Contributes to issue CURA-8466.
