Instead of updating the storage path every time you add or remove a removable drive, we now update the storage path every time you press the button to sync. That way this detail has no impact on performance of other parts of Cura if they don't use this button. It also makes the code a bit simpler.
The only downside is that this FileDialog then contains state, instead of automatically syncing with the MaterialManagement property for its folder property. I see that as a lesser of two evils.
Contributes to issue CURA-8055.
This background colour is the same as the main background, on which these buttons almost always are situated. However in the cases where they are not, such as the post-processing scripts button, this makes the text easier to read than a completely transparent background colour.
Done as a 5 minute fix.
This will make the translations more reasonable (instead of translating "open file" and "from Disk" separately, which could make the some translation results making less sense.
CURA-8411
QtSVG doesn't support clipping paths. QtSVG only supports the SVG 1.2 Tiny specification. See https://doc.qt.io/qt-5/svgrendering.html for more information on exact support.
* Update anycubic_i3_mega_s.def.json
Adapted Deviation to ATMega2560 of Anycubic Mega S
* Update resources/definitions/anycubic_i3_mega_s.def.json
Good points. Thanks!
Co-authored-by: Konstantinos Karmas <konskarm@gmail.com>
Co-authored-by: Konstantinos Karmas <konskarm@gmail.com>
There's a suspicion that this is causing a crash on exit. From the traceback it seems like it's attempting to find a certain property on a deleted item. I'm thinking it might be trying to update properties on an item that was already deleted by the system here because the item got moved to a system-specific menu. Qt doesn't realise that. By not translating that property, it's not necessary to update and hopefully this prevents the need to look up data on the deleted item.
Not translating it is not an issue anyway, since the menu will also be renamed by Qt to some system-specific name, which is then also translated to the user's system-language by MacOS itself.
It's not at all sure if this will fix it. Tests are necessary.
Contributes to issue CURA-8245.
* Added prelim support for the BX
* Revert "Added prelim support for the BX"
This reverts commit 923fbdbbb617d000663f04d08d468ed0c560517c.
* Added prelim support for the BX
* Revert "Added prelim support for the BX"
This reverts commit 923fbdbbb617d000663f04d08d468ed0c560517c.
* Added BIQU BX printer def
* Updated the platform name.
* Minor update to the start code. Ready for merge.
* Initial FLSun Super Racer profile setup.
* flip has_machine_quality to false as suggested by @konskarm.
* tabs vs spaces! Space is the final frontier!
* Enumeration value should be in inner single quotes as requested by @konskarm.
If the user had specialised settings fixing the number of walls or skin layers to an integer number, this fixed value would get copied over from the extruder settings, causing infill meshes to have walls by default.
This is unintuitive. We want infill meshes to behave like it's only infill by default. So remove all of those overrides so that only infill gets printed there, by default.
The user may still change the number of walls or skin layers or their parent settings. But by default it should now behave like infill within infill, regardless of the user's setting overrides.
Fixes issue CURA-8393 and fixes#9815.
When working with --external-backend, the engine just stops responding, and the operating system cleans up its socket connection. From Cura's front-end we then just see the socket reset. So we should interpret a reset socket to mean that the slicing process was halted.
When not working with an external backend, a crash would always give a response code and we can base it on that instead (as previously implemented).
Contributes to issue CURA-6568.
If the user has auto-slicing enabled, this causes the indeterminate progress bar to appear.
If the user doesn't have auto-slicing enabled, this causes the slice button to reappear.
Both of these indicate that something has caused slicing to be interrupted. The message should make clear why.
Contributes to issue CURA-6568.
The slicing engine should never crash. If it does though, it's best to show something to the user. Otherwise the slicing process just halts and the user will wait a long time for it to never finish.
Contributes to issue CURA-6568.
When the `_onGetProjectsFirstPageFinished` is reached, the pagination manager already contains the correct pagination metadata and links, so calling `clear()` there resets them giving the impression that there is no next page.
This commit fixed that by calling the `clear()` function should when the search filter is applied, instead.
CURA-8009
