This adds a function 'triggerFirst' to the file provider that triggers the first file provider in the model. That should then be the local file provider, but if the plug-in is disabled for some reason it would use another plug-in.
Contributes to issue CURA-7868.
The action was no longer in the menu, but the hotkey still functioned. Then there were two actions for Ctrl+O, which was ambiguous to Qt.
Contributes to issue CURA-7868.
We can now define plug-ins that specify where to open files from. This is one of the places where you can open files.
This breaks the main button to open files in the interface. It needs to be redirected to trigger the plug-in to show the open file dialogue.
Contributest o issue CURA-7868.
As Ghostkeeper suspected correctly in the review comment https://github.com/Ultimaker/Cura/pull/9012#discussion_r549707433
the binding wasn't working because the model was being retrieved using a function
(CuraApplication.getFileProviderModel()).
Separating this model into a variable allows us to properly bind the "visible" properties of the
menu items with the count property of the model without a problem.
CURA-7868
When there is only one file provider (i.e. the local file provider), the Open File(s) will be a
simple item in the File menu.
When there are more than one file providers, the Open File(s) will become a submenu in the File
menu, which will contain all the file providers as submenu items.
CURA-7868
Previously it was using this 'peak_height' which is the total height of the model in scale_vector.y. However it was then multiplying the height map with that scale vector and adding the base height again a second time. So the scaling part was too thick and included the base height, and the total height of the mesh was also too big.
I also reduced an unnecessary re-calculation of the height_from_base parameter. And as a result we don't need the peak_height variable at all any more.
Fixes#8902.
These formulas were using a setting that didn't exist any more.
Not sure how this got through QA. Oh well, this is what they are intending.
This formula is a little bit weird in how it works with support meshes if support is disabled, but it's more or less as good as it gets. The formula is mirrored from how other Ultimaker printers write it down, but slightly simplified with the same outcome.
After https://github.com/Ultimaker/Cura/pull/8684 raft_airgap and speed_layer_0 existed twice in some of the quality profiles.
This commit fixes that by removing the old (calculated) values.
The draft and ooze shield use the skirt/brim settings to print. So these settings should be adjustable if the draft or ooze shield is enabled. It's a bit weird UX-wise, but it's correct. The UX problem will be tackled later.
Apparently this was already done for the speed/acceleration/jerk settings so no change necessary there.
Contributes to issue #8808.
Two problems with this description:
- It claims that meshes with lower rank override meshes with higher rank. It's the other way around.
- It mentions 'rank' in one sentence and then 'order' in the next. I've corrected this to use the term 'rank' in both sentences for clarity. This is also the term used for the setting label, to be consistent.
Found in issue #8821.
The ProBundle rejects materials which have these values a positive number.
Users should not be allowed to set it to a positive number.
Fixes CURA-7856.
This platform mesh is 3MF (whose texture coordinates we cannot read) and doesn't contain actual texture coordinates either.
Contributes to issue CURA-7852.
