Because we're adding a messgae for the user if the loading of a plugin failed
(which can happen after backing up a plugin in central storage), we can re-enable
the backing up of plugins again.
CURA-8313
I had disabled that in an attempt to fix the bytes-to-str conversion issue, but it turned out to not be the cause. Compression is fine.
Contributes to issue CURA-8055.
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.
This would've gone so wrong if we actually released 4.10 without this, since, as a string, 4.10 is 'smaller than' 4.6 (for example), because alphanumerical-order.
done as part of CURA-8269
Backups are synced with your account anyway. Backing up the plugins means that you
quickly reach the limit of the max size (250mb) that the backups allow.
CURA-8269
The other transformations, in particular rotation, were also influencing the merge. The transformations were not removed when calculating the center position, causing the center position of a mesh to be calculating differently. When the meshes were actually transformed/moved, all of the transformations were removed but this gave the model a different center position. The different center position wasn't properly being compensated for using the previously calculated center position.
Fixes CURA-7873.
The position of the group node should in theory never be included.
We'll return that position only if there is no mesh data and all children have no AABB either. In that case we'll return a degenerate AABB so that handling code has something to work with. But then also make sure that those degenerate AABBs are ignored if we want to get the AABB of a parent node.
Contributes to issue CURA-7873.
When Cura is starting up, it reads the authentication data from the preferences (cura.cfg). If
the auth tokens have previously been stored in the keyring, it means that their values will be null
in the cura.cfg file. Therefore, on startup, Cura reads the tokens as none from the preferences and
then sets the empty values in the keyring as tokens. This leads to the user being signed off every
time Cura restarts on Mac.
On Windows, the access token was still stored in the preferences, so on startup it was safe. The
refresh token, on the other hand, had the same issue as on Mac, which means that on startup it was
read as None from the cura.cfg and was stored in the keyring as an empty string. This meant that,
even though on startup (on windows) the user was kept signed in, the next time Cura was attempting
to refresh the access token (after 7-8 minutes), it wouldn't be able, since its refresh token was
read as "" from the keyring. Also, if the user would close Cura and reopen it after 10 minutes
(so after the access token had expired) then they would be signed off on windows too.
This commit fixes that by making sure that if the given value of the refresh and access tokens are
empty, then they will not be stored in the keyring.
CURA-8178
So libnest2d is giving a segfault when it's being triggered without any disallowed areas. This is because we then give a single disallowed area for the border around the build plate, and give this disallowed area 0 vertices. Because libnest2d doesn't do defensive coding here, it's going to crash, taking Cura along with it. The crash is in libnest2d's function 'libnest2d::_Item<ClipperLib::Polygon>::rightmostTopVertex()'.
This segfault started happening recently in Cura. However it only happens when there are no disallowed areas. Steps to reproduce the error are:
- Use Custom FFF Printer.
- Set the Adhesion Type setting to 'None'.
- Load any two models.
I tracked the segfault down to this commit: 74ddbaab4b . That commit by itself is slightly mysterious but looks fine to me. It did give the hint that this segfault might be caused by empty polygons though. So for that reason, I figured that filtering out the empty polygons here in the arranger might fix it; and indeed it does. Passing empty polygons as fixed/disallowed areas is useless and invalid anyway. Apparently libnest2d doesn't deal well with it, but we might as well not send those polygons over then.
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
