Some brim settings seemed to behave as if they where linked, when in fact for any extruder set to -1 the 'default extruder' was set by some hacky code that supposedly fixes a 'dissallowed area' issue, very likely also related to the skirt/brim settings. Since dissalowed area for skirt/brim will not be a thing anymore, at least in the front-end, due to CURA-9066 (the 'parent' jira ticket that was blocked by this bug); it was sinplest just to remove the hack altogether. (Otherwise we'd have to make an artificial distinction between -1 and None as it relates to 'Not Set/Used' versus 'Not Overridden', only to then force it back to -1 in situations that call for it -- like communicating to the engine.)
CURA-9553
The `numberExtrudersEnabled` property was never updated, as such the checks if the property changed based on the new value being different from this value didn't work.
CURA-8463
Already moslty implemented, but a new approach of the base feature (abstract cloud printers) made a more? elegant and functioning implementation possible.
(re)implements CURA-9422
Having a separate class for the AbstractMachine complicated things; it's behaviour was extremely similar to the GlobalStack so adding one more stack container type in addition to the many similar setting container types we already have adds complexity to the system. Having these different classes for machines and abstract machines also add complexity to the update script as the abstract machines were stored in a separate folder from the machine types.
Because of these reasons we decided to replace the AbstractMachine by a GlobalStack where the is_abstract_machine property metadata property is set to True.
CURA-9514, CURA-9277
Co-authored-by: joeydelarago <joeydelarago@gmail.com>
Made typing more generic to work with an ContainerStack to compensate.
Made AbstractMachine getMachines a classmethod so it can be called with ContainerStacks.
CURA-9514
For now it does nothing. But I'm adding a function that should cause the combobox to pulse. That'll be a new feature so I'm implementing it in a separate commit.
Contributes to issue CURA-8849.
We are now selecting intents first and then quality, however the container hierarchy quality -> intents. This is the reason for the new functions inside machine manager.
CURA-8849
Otherwise it crashes here. The ContainerManager should be flexible enough to allow that sort of thing.
It works with plain entries, but crashed with subentries (like 'properties/diameter') if those weren't present yet in the metadata.
Fixes Sentry issue CURA-3FH.
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
