Had to implement this a bit differently as stated in the ticket. This field is returned when uploading the project file.
Logic needed a bit of a change as the new behavior dictates a sequence (we can only upload the print file after the project file is uploaded, and we know the correct `file_id`/`source_file_id`) where before these two api calls were done in parallel.
CURA-8555
And otherwise show the intent and quality level selectors.
This is currently quite broken because the list of quality levels is not correct. It should only show a quality type if it is supported by all extruders.
Contributes to issue CURA-8849.
Looks more harsh than it should be, perhaps. I'd prefer if we could add some text that says that you can create your own custom profiles too...
Contributes to issue CURA-8849.
Before the first pulse, the _previousResolution property was still bound to the activeQualityType property of the MachineManager. When it then checks if it changed, it finds that it didn't change because it checks against that same property, but the _previousResolution automatically updated with it. After that it loses its binding because it's set in the function itself to a fixed value.
Instead, we'll now give it its initial value with the Component.onCompleted function so that it doesn't bind, and then doesn't change along with the first change.
Contributes to issue CURA-8849.
For now it does nothing. But I'm adding a function that should cause the combobox to pulse. That'll be a new feature so I'm implementing it in a separate commit.
Contributes to issue CURA-8849.
For some models we'd like to have the possibility to have rich text in the combobox. For some we'd like to prevent that, for instance to prevent the user from using colours in their profile names, or boldface, or even images.
Contributes to issue CURA-8849.
We are now selecting intents first and then quality, however the container hierarchy quality -> intents. This is the reason for the new functions inside machine manager.
CURA-8849
Although net technically needed by Cura, our other Python binding
modules (such as pynest2d, pyArcus, pySavitar) might need it if
the need to be build on the host machine
Contributes to CURA-9365
When running `conan source .` on ubuntu the `.git` folder
was removed, happens with cona 1.47 ... 1.49
This seems to be a bug in Conan, I will try to reproduce
it and create an issue in their repo.
Contributes to CURA-9365
This will be generated if you do a conan install with devtools
It assumes that the projects `cura-binary-data`, `fdm_materials`,
`uranium`, `libcharon` are installed along side the `cura` project.
It will automatically install the fdm_materials when running
conan source.
The pyinstall dist can be created with:
```
# Windows Powershell
conan install . -pr:b cura_build.jinja -pr:h cura_release.jinja --build=missing --update -o cura:devtools=True
conan source .
.\venv\Scripts\Activate.ps1
pyinstaller Ultimaker-Cura.spec
```
```
# bash
conan install . -pr:b cura_build.jinja -pr:h cura_release.jinja --build=missing --update -o cura:devtools=True
conan source .
source venv\bin\activate
pyinstaller Ultimaker-Cura.spec
```
Contributes to CURA-9365
Since we're no longer running from `master` branch
It is more fitting to rename it to either dev or
main. This version is only used when running from
source when the CURA_VERSION variable isn't set
while performing the `conan install`
Contributes to CURA-9365