Use rich desktop file

[Peter Uithoven (peteruithoven)]

Description

Uses the richer .desktop when creating the AppImage so that MimeTypes are included in the .desktop file, so that Cura is suggested when opening .stl files or when trying to open cura:// links.

Fixes: #21358

Big preface: I've relied a lot on GPT Codex and I have not yet figured out how to generate the AppImage locally. Currently looking into using Act to run the relevant workflow locally.

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Pending progress in running github workflow locally using Act.

Test Configuration:

• Operating System: elementary OS 8.1 (Built on Ubuntu 24.04.3 LTS)

Checklist:

• My code follows the style guidelines of this project as described in UltiMaker Meta and Cura QML best practices
• I have read the Contribution guide
• I have commented my code, particularly in hard-to-understand areas
• I have uploaded any files required to test this change

[Peter Uithoven (peteruithoven)]

I'm having a hard time creating an AppImage locally.

I needed a GPG_PRIVATE_KEY

gpg --quick-generate-key "Act Test Key <act@example.com>" default default 1y
gpg --armor --export-secret-keys "Act Test Key" > /tmp/my-test-key.asc
base64 -w0 /tmp/my-test-key.asc > /tmp/gpg.b64

Running:

gh act workflow_call --job linux-installer \
  -W .github/workflows/linux.yml \
  --input conan_args="-c user.sentry:token=dummy -c user.sentry:environment=local" \
  -s GPG_PRIVATE_KEY="$(cat /tmp/gpg.b64)"

But I keep running into it not finding user.sentry:token:

| ERROR: There are invalid packages:
| arcus/5.11.0: Invalid: Unable to enable Sentry because no user.sentry:token was configured (use '-c user.sentry:token=token')
| clipper/6.4.2@ultimaker/stable: Invalid: Unable to enable Sentry because no user.sentry:token was configured (use '-c user.sentry:token=token')
| curaengine/5.12.0-alpha.0@ultimaker/testing: Invalid: Unable to enable Sentry because no user.sentry:token was configured (use '-c user.sentry:token=token')

[Erwan MATHIEU (wawanbreton)]

Hi, and thanks for feature !
The workflows are designed to be run in their daily environment, i.e. on the proper runners and with the proper arguments. I would suggest to extract the relevant commands from the workflows and execute them manually. Then you should be able to drop the user.sentry arguments

[Peter Uithoven (peteruithoven)]

This is a lot to ask. I'm probably spoiled with projects I can build with npm install && npm run build.

I've switched to following the Running Cura from Source docs.

Ran into some trouble, but with GPT-5.1-Codex I figured out I needed to do the following to get the conan install . --build=missing --update -g VirtualPythonEnv to finish.

• Install gitpython and modern SIP tooling into that venv (python -m pip install gitpython "sip>=6,<7"), which resolved the initial ModuleNotFoundError and supplied the sip-build command required by pyarcus.
• Install the system package libnsl-dev so the final link of pyarcus can satisfy its -lnsl dependency.

I'm now able to build and start Cura from source. On to figuring out how to build AppImage.

[Peter Uithoven (peteruithoven)]

I'm having a hard time figuring out how to build AppImage.
Can anyone point me to relevant docs?

I've tried to start 2 workflows from my repo, but they have been queued for a long time.
https://github.com/peteruithoven/Cura/actions/workflows/linux.yml

[Erwan MATHIEU (wawanbreton)]

Ran into some trouble, but with GPT-5.1-Codex I figured out I needed to do the following to get the conan install . --build=missing --update -g VirtualPythonEnv to finish.

* Install gitpython and modern SIP tooling into that venv (python -m pip install gitpython "sip>=6,<7"), which resolved the initial ModuleNotFoundError and supplied the sip-build command required by pyarcus.

* Install the system package libnsl-dev so the final link of pyarcus can satisfy its -lnsl dependency.

Thanks for the feedback, I'll see to update the documentation to make it easier. I'm sorry that this does not work out of the box, but our workflows keeps changing because of elements being updated, and since we all have different environments, keeping the doc up-to-date is a difficult task 😞

I'm having a hard time figuring out how to build AppImage. Can anyone point me to relevant docs?

I've tried to start 2 workflows from my repo, but they have been queued for a long time. https://github.com/peteruithoven/Cura/actions/workflows/linux.yml

There is no documentation to build the AppImage, since this is not really a common workflow. Your best option is to look at the GitHub workflow and adapt the commands to your local setup, which I sometimes have to do.

Also the workflow you are trying to run uses our self-hosted GitHub runner by default, which you are not allowed to use. Maybe that is why it did not start. Now it has expired, I can't see the details, but I can take a look if you restart it and it still fails.

[Erwan MATHIEU (wawanbreton)]

I have updated the "building from source" documentation. In order to get the proper version of the tools, I suggest that you re-run the step 3 of Install Python dependencies and setup Conan in your venv. The pointed requirements file is updated regularly so the documentation should not require any further update.

[Peter Uithoven (peteruithoven)]

Thanks for the effort, but I don't really know how to run lines like the following locally, this requires a lot of translation and understanding of git workflows.

https://github.com/Ultimaker/cura-workflows/blob/502ab4acb3e74ec887ddfac6d48e595aa18888eb/.github/workflows/cura-installer-linux.yml#L83

For now I'm aborting this effort. I hope someone else with more understanding of the toolchain can pick this up. The

[Erwan MATHIEU (wawanbreton)]

Thanks for the effort, but I don't really know how to run lines like the following locally, this requires a lot of translation and understanding of git workflows.

https://github.com/Ultimaker/cura-workflows/blob/502ab4acb3e74ec887ddfac6d48e595aa18888eb/.github/workflows/cura-installer-linux.yml#L83

For now I'm aborting this effort. I hope someone else with more understanding of the toolchain can pick this up. The

Ok, I understand. I do see value in this change, so I will try to find some spare time to work on it.