If the user account scope is outdated, delete it when upgrading from 4.8 to 4.9. This means that
the user will have to log in again, to make sure they get the correct account scope.
CURA-8093
If the 4.8 is started from a clean install and no category gets expanded in the settings panel,
then the "categories_expanded" key will not exist in the [cura] preferences in cura.cfg.
As a result, when the 4.9 gets started in this specific case, the version upgrade 48 to 49 will
produce a crash and will be considered as "failed", which will then lead to cura requesting from
the user to go from the entire onboarding flow instead of landing on the "What's new" pages (even
though everything else has been properly updated).
This commit fixes that by checking whether the "categories_expanded" key exists in the cura.cfg.
The Cura 4.9 release will have expanded functionality. If you have a plug-in that uses this functionality, marking it as using SDK 7.5.0 will notify older Cura releases that they can't use that plug-in.
The DisplayProgressOnLCD script was changed and the "time_remaining" was split into two settings:
the "time_remaining" and the "time_remaining_method". If the "time_remaining" was enabled, the
"time_remaining_method" should be set to "m117".
The VersionUpgrader48to49 was changing the "time_remaining" to "m117" instead of changing the
"time_remaining_method", which was leading to the "time_remaining" having a wrong value and not
being interpreted as a boolean.
This commit fixes that by setting the "time_remaining_method" into "m117" when the "time_remaining"
was True.
CURA-8110
It is known that will cause some user scripts to default behaviour.
But this is accepted behaviour, and the benefits of not upgrading
the Cura Application version outweigh this.
The actual package name internally will still have the spaces.
People were using this to get ahead in the sorting of packages, which is a little unfair. This doesn't make that impossible, but prevents it for the most part.
After installing a package and hitting the "Close Ultimaker Cura" button, the Toolbox window
was remaining open for a few seconds, even though the Cura window was instantly closing.
This is not fixed by explicitly hiding the Toolbox dialog once that button is pressed.
CURA-8126
We generally disabled the clicks in the mouseArea of the tooltips.
In this case though it should still accept the left click since it acts as a button.
CURA-8125
The Connections in qml is a QObject and it has an enabledChanged signal by default.
Therefore, we cannot really use the Connections to connect to the enabledChanged signal of e.g.
a python class, because qml complains that there is already a function named enabledChanged() in
the Connections.
To circumvent that, we can simply rename the enabledChanged() signal of the Toolbox to
toolboxEnabledChanged().
Encountered as I made a failed attempt at solving the issue with rendering transparent support. I tried to order vertices appropriately but failed miserably.
This fixes a very old bug in Cura where sometimes after re-slicing it would display the layer as if you've been going horizontal through the path slider, even if you never touched the horizontal path slider.
This was caused by a tracking flag in the SimulationPass, _switching_layers. This bit of state in the SimulationPass was tracking whether the user is going through the vertical layer slider (True) or the horizontal path slider (False). If False, the nozzle mesh is drawn and lower layers get drawn in a shadowy shader. The state of this flag was being updated on every render by looking at whether the previous render has the same current layer number but a different path index. If so, it changed to False, meaning that it assumes you're going through the paths on a layer and things get shadowy.
However if you slice a different object such that the number of layers stay the same (or at least the current layer) but the number of paths on a layer change (e.g. by reducing Maximum Resolution, or by loading a different model that happens to be equally tall) then it would falsely think you were going through the horizontal path slider.
This change effectively resets this state flag when any layer data is changed in the scene. So if you re-slice, it always goes back to _switching_layers = True.
The side effect is that if you were going through the paths of a layer and you re-slice, you won't end up on the same path even if the number of paths on your current layer didn't change due to the reslice. But I think that is more towards what the user would accept a re-slice to do anyway.
I decided to take a look into this bug because I'm making a script to automatically refresh the screenshots of the Settings Guide plug-in. This script frequently hits cases like this, and it's easier to fix this bug than to work around it in my script.
The code is clearly written to take into account that 'addresses' may be null. But not that the whole 'addresses' attribute may not exist. And then instead of printing one warning (Could not get information about XX) it instead printed a stacktrace and retried and printed a stacktrace and retried and printed a stacktrace and.... It ended up driving me a bit nuts when looking at the logs for unrelated reasons. So Ifinallay fixed it. Could end up as a speedup in some cases as well I suppose?
This metadata has been changed to contain other information. Readers of information from 3MF need to adjust their stance too to filter out the information they need from the metadata of the metadata.
Contributes to issue CURA-7615.
