Polygons don't change when in layer-view. There's already an analogous elementCount property anyway, so a vertexCount property can't do much harm. Just keep in mind that when the polygons are altered, it should be either done via build, or the lineMeshXXXCount methods should be used instead.
The `tooltipWidth` property is not available in 4.9 and 4.10. This property was added to make sure that the tooltip has a smaller width than the DigitalLibrary window, or else the tooltip doesn't get drawn at all, which is confusing. Since it was not available in 4.9 and 4.10, the tooltip text smaller had to become smaller to make sure that it will fit.
CURA-8444
The `leftIcon` property, which is not available in 4.9 and 4.10, so the DigitalLibrary window wasn't getting drawn. To keep having the icon, I manually added the RecolorImage in the search textfield.
CURA-8444
This will hopefully prevent people from messing with the installed files (and then getting confused when they upgrade) when they should be using the configuration (sub-)folder(s) instead. If I read cura-build correctly, just placing the files here will already copy them to the right directory, since that happens for all folders (and hopefully files) for those directories anyway.
Instead of re-uploading the mesh each time the range changes, handle the range in the shaders with the new draw-range parameters. This does however, mean the range has to be in vertices, not in elements. This necessitates some changes to the simulation-view, and some added bits deeper in the base code. Mainly, since each time the type of a line changes, there is an extra vertex, there needs to be a type-change count available to get from 'paths' to range indices.
This will make the translations more reasonable (instead of translating "open file" and "from Disk" separately, which could make the some translation results making less sense.
CURA-8411
QtSVG doesn't support clipping paths. QtSVG only supports the SVG 1.2 Tiny specification. See https://doc.qt.io/qt-5/svgrendering.html for more information on exact support.
If the user had specialised settings fixing the number of walls or skin layers to an integer number, this fixed value would get copied over from the extruder settings, causing infill meshes to have walls by default.
This is unintuitive. We want infill meshes to behave like it's only infill by default. So remove all of those overrides so that only infill gets printed there, by default.
The user may still change the number of walls or skin layers or their parent settings. But by default it should now behave like infill within infill, regardless of the user's setting overrides.
Fixes issue CURA-8393 and fixes#9815.
