Users could still set the option first, _then_ switch to Griffin, giving the same problems before the default was switched to false (since the setting is disabled for Griffin flavour anyway).
part of CURA-10451
Hold-stepper-motor (and maybe beep) options, newly introduced previously, _and on by default_ (even though it was clear they where not meant for Griffin flavour GCode -- because at least the hold-motor option was not even visible for Griffin) where causing UltiMaker printers with prints that had the pause-at-height script enabled to fail.
should fix internal ticket CURA-10451
For non-Repetier and non-Ultimaker printers - Move the prime extrusion so it occurs while the print head is still in the parked position so the blob doesn't happen over the print (GitHub #13584 and #11471 for reference).
Add a user option to use M104 or M109 for the resume temperature to avoid an unnecessary delay if the resume temperature is the same as the standby temperature.
committed as part of CURA-9822
For relative mode, not only needs the retractions created to be actually relative, but it also needs to compensate on the next G1 (as opposed to absolute mode, where you'd want to go to the same absolute E position after). Rather than massively complicating the already gnarly code (once it found a G1 retraction, it scanned forwards to find G0 statements (which it rewrote to G1), so it would go over those _again_ in the middle (layer) loop). While this worked for absolute mode, but would be a nightmare to make work for relative mode as-is (if only because the compensation could _also_ potentially involve keeping track of things over the outer loop). As a bonus I think the resulting code is actually easier to read.
part of CURA-10092 -- should fix#14100
It shouldn't really be nescesary, but you _can_ put any gcode flavour in relative or absolute, so we should also deal with that in the pause-at-height script.
Fonts were looking a bit to thick on when using `Text.NativeRendering`, so using `Text.QtRendering` instead. After this the font weight looks identical to figma (as far as I can see).
In this commit I also changed all `Label`'s to `UM.Label`'s and removed default properties where I could.
CURA-9154
Fonts were looking a bit to thick on when using `Text.NativeRendering`, so using `Text.QtRendering` instead. After this the font weight looks identical to figma (as far as I can see).
In this commit I also changed all `Label`'s to `UM.Label`'s and removed default properties where I could.
CURA-9154
It turns out that the order of these functions matters. So when we created a
function with only one param, it would actually give it the index. Removing
with the index didn't work, so the object would still be there. The Qt objects
would already be deleted which caused segfaults
CURA-9222
