🌠 Nightly Build 🌠 (5.10 Alpha)

[wawanbreton]

A Nightly build with upgraded Python 🐍 and Conan 🐸

During the last months, we have been pretty busy upgrading 2 core components of Cura:

• Python has been bumped from 3.10 to 3.12. Athough this is not major, Python is the engine that runs the Cura front-end and even the slightest change in its behavior can have an impact.
• We are now using Conan 2 instead of Conan 1. This tool is the basis of our build system, as it orchestrates the way each component of Cura is built and packaged. Cura uses multiple Python and C++ packages altogether, so assembling them all to a standalone application on 3 platforms is a sensitive task.

Why are these changes required ?

• Python keeps evolving, and we want to take advantages of its upgrades and last features. This also allows new developers to use the most recent version.
• Python 3.12 also comes with native speed improvements, so it is always good to take 🙂
• Conan 1 is on a deprecation path, so we really needed to switch to version 2, which is considered the more mature and robust version. Recent packages are now using Conan 2, so if we want to keep up-to-date, we need to use it.

Why do we need you ?

• We have tested many builds of Cura, on many systems, but we know everyone has a different execution environment. The idea of this Alpha release is to make sure that it still works on all the platforms where it used to work before.
• We don't exactly know how everyone uses Cura. There may be some actions that you do, which will reveal a bug we didn't see in our tests.
• There are tons of plugins, all based on Python code. So we want to make sure that they keep working with the new version.

What do you need to do ?

Well, not much, just download this version, use it as you would usually do, and send a brief feedback on the discussion: describe your environment, and tell us if everything went fine, or if you encountered some crashes or strange behaviors !

⚠️ Remember that this is an Alpha version, which means that only the basic functionalities have been tested. Some features are missing, incomplete or still in development, and may not be usable for production.

---

This discussion was created from the release 🌠 Nightly Build 🌠 (5.10 Alpha).

[jszymon]

Everything fine on Linux.

[kalkishnu]

os: Archlinux
kernel: 6.13.0-2
WM: Hyprland
gpu driver: nvidia-open 570

./Descargas/UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage UM/Settings/SettingFunction.py:244: DeprecationWarning: ast.Str is deprecated and will be removed in Python 3.14; use ast.Constant instead def visit_Str(self, node: ast.Str) -> None: fish: Job 1, './Descargas/UltiMaker-Cura-5.10…' terminated by signal SIGSEGV (Address boundary error)
Additional info: version 5.9b1/b2/r crash the same way, last version i can run on this environment is 5.8.1.
Worth to mention that i tried all this version also on a nested lxqt_kwin_wayland session on the same user and all of them launched.

[wawanbreton]

Hi, thanks for the feedback !
This seems to be related to wayland indeed. In 5.9 we added an environment variable at start to force QT to use the xcb platform:
QT_QPA_PLATFORM=xcb
So you could also try the other platform plugins. Giving the plugin with the environment variable doesn't seem to work though, because it is embedded in the AppImage, but you can do the following:

./UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage -platform ...

In order to get the list of available plugins, just set a wrong one:

$ ./UltiMaker-Cura-5.10.0-alpha.0-linux-X64.AppImage -platform something
...
qt.qpa.plugin: Could not find the Qt platform plugin "something" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-egl, wayland, xcb.

Anyway, if the issue is present since 5.9, it is not a regression related to the Python/Conan changes, which is at least some good news for me.

[glx-seven]

Win11 24H2
Cura 5.10.0-alpha.0

The gradual infill setting seems just to respect the uppermost surface, the lower ones are treated with the reduced density (somehow offsetted tho). Doesn't seem to be affected which material or printcore is selected, the screenshots are from extruder 2 but I included a project with extruder 1 that behaves the same.

One below the uppermost:

Uppermost:

Project file:
Project-files_UMS5_vallejo_multi_rack.zip

[wawanbreton]

Hi, thanks for the feedback !
I'm not very familiar with the gradual infill feature, but I will discuss this with the team to see if this is somehow intended behavior.

This part aside, it seems that the application works pretty well overall 🙂