This should not happen, but we've seen some cases where it would cause a crash, usually
when a previous upgrade did something a bit weird (in this specific case; a printer
with an empty variant, whereas it should have a variant).
Since any change that the user will make will ensure that the variant is no longer empty (eg;
any selection of a variant will mean it's no longer empty) and that there is no way back,
it should be pretty safe to ignore the situation as it will resolve itself eventually
CURA-6992
Otherwise it usually only iterates over the one that the model is printing with or something. We want to iterate over all extruders that are not deactivated.
Contributes to issue CURA-6597.
We want the intents for basically any extruder, not just the one that would get used by a slice using the current settings for extruder_nr.
Contributes to issue CURA-6597.
Can't import CuraApplication because we create instances of IntentManager from the IntentsModel which is created in CuraApplication.
Contributes to issue CURA-6597.
Very rudimentary at the moment, need to split the method into 3, and make a class for the setup.
This also uncovered that the currentAvailableIntents doesn't (unless the global stack is missing) retrun any default intents, while currentAvailableIntentCategories does do that.
Since it's not clear how we're going to handle that right now, I made a TODO in the code, which of course will have to be fixed before this/these branch/es are merged.
part of CURA-6091
Slightly more complex than the original pseudocode was indicating: It needs to filter on the available quality types first in order to only show the quality types that can be printed with all extruders, but still show the union of all intents for those quality types.
Contributes to issue CURA-6091.
This won't run. Don't try to import this class yet. It's outlining what we need to implement to get intents per stack.
It does no form of caching at this point. Build first, optimise later, right.
Contributes to issue CURA-6091.
