The solution is to do only one of these options.
Removing the disallowed area works fine when scaling models from their center. However we scale 2 or more models from the buildplate center rather than the model center. This means that the models can go outside the buildplate without it being obvious from the visualization.
The better solution is to remove the buildplate x/y scaling and keep the disallowed areas.
Removed shrinkage factor build volume scaling on x and y. This information is shown already by scaling the allowed areas around the objects.
Kept the bounding box scaling for z. This shows the max height a model can be. The objects disallowed area does not show this information.
Also removed scaling on non model disallowed areas on the build plate since this does not need to scale with the build plate anymore.
CURA-9271
Also fix the highlight colour of the border. The highlight colour was changed in a later design but it was not changed here yet.
Without a theme colour it's going to use the system colours for the highlighting of text, which may be a very light grey that matches the background, making it impossible to see what part of the text is selected.
Hopefully fixes issue #12286.
Previously we would only accept intents that had a translation. If we
could not find one, we would use "unknown" as the intent category. However,
we didn't really do this consistently. In some places it would show unkown
and in others we'd show the intent type.
This should make the behavior the same across the board. It will try to get a
translation for the intent category and show that. If it's unable to find that
it will use the category instead. Note that it will use the python title function
to ensure it has nice capitalisation
CURA-9297
This old function is only necessary for upgrading from before v3.4. Best not let it crash in any other case, even if that would sometimes make very old machine instances corrupt if I made a mistake in thinking here.
Fixes Sentry issue CURA-3XG.
Add function to fetch package_id using only information from XmlMaterialProfile material container.
The only piece of information associating the material container and the package together is the file_name. To find the package that owns a material we have to search each of the material package paths.
It would be great to find a cleaner solution (preferable one that doesn't require invalidating the cached containers).
CURA-8610