They'll be generated and then tossed away. I'm specifying that there will be normal support in its place, unlike the minimum support area setting that replaces the support with air. It won't be air here, but normal support.
It's a quality container, not a material container. This was a copy-paste mistake.
Also added that this may be a global quality container, not always a per-extruder quality container.
Found during testing & tooling.
These are used by the code. Otherwise there would be an AttributeError of 'intent' not existing, and the quality type in the quality node wouldn't match because it's a magic mock.
This has been infuriating me for the past few weeks. The result of this change is that when you use Cura as built from source or via thopiekar's PPA the Gnome shortcut will act only as a launcher for potentially infinite instances of Cura. That is, if you keep clicking it, it will open up more and more instances of Cura. This is because the class cura.real is not present or specified in the desktop file. See this askubuntu thread on the topic;
https://askubuntu.com/questions/367396/what-does-the-startupwmclass-field-of-a-desktop-file-represent/367851#367851
Simply adding "StartupWMClass=cura.real" allows Cura to behave like a normal application in all desktop environments that implement .desktop. Cura can now spawn children and in gnome in particular has options for spawning a New Window, rather than a runaway "Spawn more instances" as you click the launcher. This has been particularly annoying for me, as in a makerspace I attend where I have set up a dedicated Cura machine people have been opening several instances of Cura because of this flaw.
BIBO and members from the BIBO group on Facebook say this printer should be run at 40-45mm/s and not the FDMprinter default of 60mm/s. BIBO provided test gcode files also show that they are setting 40mm/s in the slicer to create their test files.
This change sets the print speed override so the printer profile does not start at the FDMPrinter print speed default of 60mm/s but at the reccommended value of 40mm/s
... instead of crashing.
Not _really_ part of a ticket, but I'm solving this now because otherwise I can't even _reproduce_ the steps for the bug in CURA-6807
Otherwise they don't get loaded.
These profiles didn't use any of the settings that were renamed or removed, so they can be upgraded with just their setting version.
Contributes to issue CURA-6774.
