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
There could be an environment error when saving that file because of access rights or insufficient disk space. Catch that error and display an error message to the user. The log then contains more information on exactly why it failed, but the user just knows it fails.
Fixes Sentry issue CURA-21W.
When using the visibility of the progress bar to detect if a job is already being sent, then make actually sure the progress bar is visible the moment the job starts, not at some unspecified time later in a method that might not even trigger if there is already a mesh ... so it's unlikely to even work, since the thing it was intended to prevent _very_ likely has the same mesh anyway.
CURA-8004
Took a while to figure out exactly what to do here. But the task itself is simple.
The Ultimaker software apparently doesn't accept special characters here. The regex here is exactly the inverse of the regex that they use to accept job names.
Done as a 5 minute fix.
One of the reasons this bug (see parent of this commit ... or the issue nr if you have internal access) was so vague is that A. the user was insufficiently prompted, and B. no one could find anything in our logs.
CURA-8004
Since we use that to detect when the mesh is already uploaded, and thus can be reprinted, this could cause problems, since, while we do properly set it to None when an error is returned, if the request never returns to us, or if a reprint is started while the mesh is still uploading, the print-job cache could be set while the mesh wasn't actually there yet. Which could in theory have maybe caused the problems we see.
CURA-8004
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.
There could be other methods of connecting than the network connectivity of the UM3NetworkPrinting plug-in. For instance, perhaps other network connection plug-ins can provide information in this monitor stage. Or the user might want to use a USB cable.
I'm explicitly quite vague about how it should be connected because this label should work for all types of connections except UM3NetworkPrinting.
Fixes#9444.
