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
This file should take care of downloading the C++ and Python binding
dependencies. It uses the PythonVirtualRunEnv to generate a Virtual
Python Environment, setting the Paths and installing the requirements
specified in the requirements.txt
Contributes to CURA-9365
Our requirements.txt was never fully utilized.
For our builds we use a requirements.txt
specified in the cura-build-enviroment repo.
But that file contained all the Python requirements
including, testing and dev tools.
This requirements.txt should contain the bare minimum
for running Python. Since these dependencies are shipped
we need to specify the hashes as well.
These hashes aren't necessary for build and test requirements
Contributes to CURA-9365
The solution is to do only one of these options.
Removing the disallowed area works fine when scaling models from their center. However we scale 2 or more models from the buildplate center rather than the model center. This means that the models can go outside the buildplate without it being obvious from the visualization.
The better solution is to remove the buildplate x/y scaling and keep the disallowed areas.
Removed shrinkage factor build volume scaling on x and y. This information is shown already by scaling the allowed areas around the objects.
Kept the bounding box scaling for z. This shows the max height a model can be. The objects disallowed area does not show this information.
Also removed scaling on non model disallowed areas on the build plate since this does not need to scale with the build plate anymore.
CURA-9271
Swapped the loading order of Marketplace extensions so SyncOrchestractor is not fetched by PluginRegistry.getInstance().getPluginObject("Marketplace") in WorkspaceDialog.
CURA-8610
Otherwise it crashes here. The ContainerManager should be flexible enough to allow that sort of thing.
It works with plain entries, but crashed with subentries (like 'properties/diameter') if those weren't present yet in the metadata.
Fixes Sentry issue CURA-3FH.
The solution here is to check first if a material file is inside "secure_paths" (these are install directory resource paths). If it is, it must be a bundled material.
CURA-8610
This adds a new function to the API of the Marketplace plug-in.
It's not pretty, but it's going to be how it is for a while.
Done to fix a critical build issue. The 'import plugins' thing works from source but not on the build.
When running from source, 'import plugins' works since it's working from the directory where the plug-ins directory is located. However in a build this doesn't work since the source code is in a different location there.
