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
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.
Although not used in this project.
This policy is needed by our cura-build-environment
because the conan_toolchain requires this to be set.
Since we use CMake for all our repo's even pure
Python or resource repos such as this, we need to
set in regardless.
Contributes to CURA-9365
This provides control over how the header (the header is newly introduced in this commit) and footer components are rendered. The footer is the area where the `leftButtoons` and `rightButtons` are rendered. Having control over how this is rendered introduces for instance the possibility to render the buttons within a warning area (an example of this can bee seen in the WorkspaceDialog).
CURA-6990
