We encountered an issue yesterday that we had to find in a log file when a user was importing a material. Nothing is shown in the log when importing a material, so it was impossible to find.
Now we'll log this action. It is a direct user action, so info is a good log level.
It's possible that a profile is no longer in the registry by the time it gets to that point in the list if this clean-up is triggered by the very action of deleting a profile.
Fixes Sentry issue CURA-1T5.
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
The user doesn't know what a global stack is. This is a message that more clearly specifies what is really happening as far as the user can see.
The global stack may be None if this code is executed while there is no active printer. Normally the only time there is no active printer is:
- during first launch, while in the welcome screen
- during start-up until the profiles have been loaded
- if there was a profile corruption of some kind with the active printer.
So this function should not get called during those times. It probably isn't called except for the last case (in which case it's acceptable I guess).
This change is made after a request from a translator what the hell this means.
Contributes to issue CURA-7783.
The addMachineExtruders function assumes that this is a new printer (first time the printer is activated since a restart of Cura) and it needs to add the extruder stacks to it. However most of the time when we're switching, it's not to a new printer. If it's not a new printer, this function would get called anyway and we'd be adding the extruders multiple times. This then does a lot of unnecessary work and eventually fails a couple of calls deep.
This change prevents it from adding the extruders if there are already extruders associated with the printer, thus preventing this unnecessary work (switch is faster) and preventing the error from happening.
Discovered during work on CURA-7501.
When importing a profile that doesn't much the current nozzle combination (e.g. importing a 'high'
quality when we have AA0.8 and AA0.4 nozzles), the profile was being accepted and a success message
was shown to the user, but the quality did not show up in the profile list.
This commit fixes that by accepting the quality profile and informing the user that the profile is
not visible due to the current configuration.
CURA-7691
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
Since the amount of times that the key is in there is orders of magnitude
larger, it's better to catch the exception when it doesn't (as that is
slightly faster)
If the machine_extruder_count is not taken into consideration on machine creation, calling the
extruderList of that machine will return an incomplete list of extruders (since it considers the
default machine_extruder_count). This causes problems in machines with settable number of extruders
where the default machine_extruder_count is 1 while the machine may have more than 1 extruders.
The problem becomes especially visible when opening a project file with e.g. a CFFF with multiple
extruders, because when the machine is created we do not know yet how many extruders the printer
actually has.
CURA-7646
