Bit of an ugly hack. At later point in the code it is assumed the first element of the list is the main part and the remaining elements form the suffix. Intent and the profile form both the main part so these need to be grouped together.
Cura-9773
Generation quality display names in `CustomPrintSetup.qml` and `PrintSetupSelectorHeader.qml` were so similar that I decided to combine the logic.
Cura-9773
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
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
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
This is very annoying if switching profiles. This is not a critical message. The message should disappear after the default amount of time.
Discovered while working on CURA-8584.
If for some reason the print sequence is set to one-at-a-time be default in the printer definition
and the number of extruders of the printer is set to >=2, then the print_sequence won't show up in
neither the quality changes nor the user changes, yet it will still have "one-at-a-time" as a
value. In a such case, it will still need to be set to "all-at-once" in the user changes.
This is a theoretical case, as it is very unlikely for a printer to have "one-at-a-time" set by
default in its definition (.def.json) file and still be able to support more than one extruders.
But it is a world full of possibilities out there, so you never know...
CURA-7827
Previously, the print sequence would be always set to all-at-once in the user container whenever
the second extruder would be enabled. This was causing an interface issue, where the circular
reset-setting arrow would appear next to the setting, even if the quality changes already had the
correct value ("all-at-once").
This is now fixed by checking the following:
- If print_sequence == "one_at_a_time" in the quality (so it is already saved in a quality profile)
then set the print_sequence to "all_at_once" in the user changes so that it will be displayed as
an unsaved change
- If print_sequence == "one_at_a_time" in the user changes container only, meaning that it is not
saved in any quality profiles, then just reset the print_sequence in the user changes, so that it
will have the correct value ("all-at-once") without the reset-setting arrow appearing next to it.
CURA-7827
This is a bit of defensive coding. If the position is out of bounds for Cura it should now ignore those extruders.
This could be due to broken firmware, or maybe someone MITM-ing the connection and changing it, or perhaps because the printer was changed while the sync was ongoing? Whatever the cause, it now puts a warning in the log about it and doesn't crash any more.
Fixes Sentry issue CURA-156.
The QML profiler showed me that it was causing a *lot* of issues
when switching between extruders. More than 10% of the time in QML
was spent on just updating ine property in the workspace summary dialog.
There were other properties that were also being updated without there being a point.
Contributes to #8250
In some situations this could cause a slowdown, since halfway through
calculating the values the extruder switch would happen. If this is
split up a bit, it's at least less noticeable
Contributes to #8250
All the settings that are changed get a notification from the settingRelation.
There should be no need to re-fire all of those settings again!
Contributes to #8250
