While testing I noticed that the movement after the pause will
first move the head down and then move to the position before
the pause. This could result in noticeable artifacts or
accidentally push thin towers from the bed.) See the code below.
```gcode
;TYPE:CUSTOM
;added code by post processing
;script: PauseAtHeight.py
;current z: 5
;current height: 5.0
M83 ; switch to relative E values for any needed retraction
G1 F300 Z6 ; move up a millimeter to get out of the way
G1 F9000 X190 Y190
G1 F300 Z20.0
M84 E0
@pause now change filament and press ; Do the actual pause
G1 F300 Z5
G1 F9000 X30.759 Y30.759
G1 F1800 ; restore extrusion feedrate
```
I have switched the lines in the script such that it will first move to the correct X, Y and then move down
```python
prepend_gcode += self.putValue(G = 1, X = x, Y = y, F = 9000) + "\n"
prepend_gcode += self.putValue(G = 1, Z = current_z, F = 300) + "\n"
```
As shown in the code below
```gcode
;TYPE:CUSTOM
;added code by post processing
;script: PauseAtHeight.py
;current z: 5
;current height: 5.0
M83 ; switch to relative E values for any needed retraction
G1 F300 Z6 ; move up a millimeter to get out of the way
G1 F9000 X190 Y190
G1 F300 Z20.0
M84 E0
@pause now change filament and press ; Do the actual pause
G1 F9000 X30.759 Y30.759
G1 F300 Z5
G1 F1800 ; restore extrusion feedrate
```
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.
When working with --external-backend, the engine just stops responding, and the operating system cleans up its socket connection. From Cura's front-end we then just see the socket reset. So we should interpret a reset socket to mean that the slicing process was halted.
When not working with an external backend, a crash would always give a response code and we can base it on that instead (as previously implemented).
Contributes to issue CURA-6568.
