Linux 7.2.0.5226: CRITICAL — preset UI still read-only after 3 releases (#552 #565) — fix or acknowledge

[ricksouzaa]

Is there an existing issue for this problem?

• I have searched the existing issues

This is the third public report of the same Linux-only regression. Previous reports were ignored or left open with no fix:

• Linux 7.1.0.4414: settings UI becomes read-only after clean install (filament/process/printer) #552 — 7.1.0.4414 (reported, still broken)
• Linux 7.1.1.4472: settings UI becomes read-only after clean install (filament/process/printer) #565 — 7.1.1.4472 (reported, still broken)
• Linux 7.2.0.5226: CRITICAL — preset UI still read-only after 3 releases (#552 #565) — fix or acknowledge #576 (this) — 7.2.0.5226 stable — still broken

Shipping three consecutive stable/pre-stable Linux builds with core preset editing broken is not acceptable.

CrealityPrint Version

7.2.0.5226 (GitHub release tag v7.2.0 — marked stable)

Operating System (OS)

Linux

OS Version

Ubuntu 24.04.x LTS (Noble), Wayland session (XDG_SESSION_TYPE=wayland)

Kernel: 6.17.0-35-generic

Printer

K2 Pro (Creality hardware — Linux users are paying customers too)

---

Problem summary

On Ubuntu 24.04, Creality Print 7.2.0.5226 makes filament / process / printer settings read-only after normal UI navigation. You cannot reliably create or tune presets — a core slicer function.

This is not a cosmetic bug. It blocks daily workflow for anyone who adjusts temperatures, cooling, speeds, or custom filaments on Linux.

Regression timeline (same machine, same workflow):

Version	Status
7.0.1.4212	Works
7.1.0.4414	Broken — #552
7.1.1.4472	Broken — #565
7.2.0.5226	Still broken — shipped as stable anyway

Windows: same workflow works. This is a Linux-specific regression that Creality has had months to fix.

---

Environment

• Broken build:
  • CrealityPrint-V7.2.0.5226-x86_64-Release.AppImage
  • https://github.com/CrealityOfficial/CrealityPrint/releases/download/v7.2.0/CrealityPrint-V7.2.0.5226-x86_64-Release.AppImage
  • sha256: 76f7b0afb878fee3e12ba984d7ea199f3f49d625a73ed56864fa609ebaad1183
• Last working build: CrealityPrint_Ubuntu2404-V7.0.1.4212-x86_64-Release.AppImage

---

Reproduction steps

1. Open Creality Print 7.2.0.5226 on Linux.
2. Add/select printer (K2 Pro).
3. Create or edit a user filament profile.
4. Switch tab (e.g. Cooling, process, or printer).
5. Try to edit fields again.

Actual result

Fields become locked / read-only. Preset editing is effectively unusable.

Expected result

Same as 7.0.1.4212: fields stay editable; values save correctly.

---

Escalation — what we need from Creality

1. Acknowledge this as a confirmed Linux regression affecting 7.1.0 → 7.2.0, not duplicate/spam issues.
2. Merge/link Linux 7.1.0.4414: settings UI becomes read-only after clean install (filament/process/printer) #552, Linux 7.1.1.4472: settings UI becomes read-only after clean install (filament/process/printer) #565, and this report into one tracked bug with a maintainer assigned.
3. State a timeline for a fix (patch release or hotfix AppImage).
4. Until fixed: publish an official known-issue warning on the Linux download page — do not silently ship broken stable builds.

We upgraded to 7.2.0 in good faith hoping the 7.1.x line would be fixed. It was not. We are keeping 7.2.0 for other changes, but this must be prioritized — Linux users should not be forced to run year-old 7.0.1 to edit a temperature field.

---

Technical notes (for maintainers — same root cause class as #552)

Suspected GUI / preset state regression since 7.1.x:

• src/slic3r/GUI/ParamsPanel.cpp
• src/slic3r/GUI/Tab.cpp
• src/slic3r/GUI/SyncUserPresets.cpp
• src/libslic3r/Preset.cpp

Tab navigation likely leaves UI in “system preset / read-only” state. Unchanged across three releases.

---

Project file & Debug log uploads

Available on request.

Checklist

• Log file
• Project file

Anything else?

Please respond publicly on this issue. Silence across #552, #565, and now 7.2.0 stable is unacceptable for a regression that breaks basic slicer configuration on Linux.

[Arm4g3ddon]

Confirming this is still broken in 7.2.0.5226 — same wxWindowDisabler root cause as #552 / #565.

Honestly it's hard to understand how Linux gets dropped like this: three consecutive stable releases (7.1.0 → 7.1.1 → 7.2.0) shipping with core preset editing broken, while the fix has been sitting in an open PR (#572) for over a month with zero review. It's not an obscure edge case — you literally cannot edit a temperature on Linux. Reports get left open and the PRs don't get looked at.

@ricksouzaa your root-cause instinct is right (ParamsPanel.cpp area). The actual trigger is a wxWindowDisabler that leaves the whole GTK settings dialog insensitive, so every input reads as locked.

For anyone who needs a working 7.2.0 right now, I rebased my fixes onto Creality's fresh 7.2.0 and published a prebuilt AppImage:

https://github.com/Arm4g3ddon/CrealityPrint/releases/tag/v7.2.1

What's fixed on top of upstream 7.2.0:

• Settings/presets editable again (the read-only regression in this thread)
• No more crash on exit — bonus fix: static GLModel destructors were calling glDeleteBuffers() after the GL context was already torn down, segfaulting on every shutdown on Linux. Fixed.
• Builds cleanly under GCC 13 / Ubuntu 24.04 (Creality's new 7.2.0 sources had two MSVC-only constructs that don't compile on Linux)

Would still much rather see #572 reviewed and merged upstream — happy to help. But at this point Linux users shouldn't have to run a year-old 7.0.1 to edit a temperature field.

[ricksouzaa]

@Arm4g3ddon Thank you for the work on this — really appreciated.

We're on Ubuntu 24.04 (Wayland) with a K2 Pro, hit the same read-only preset bug across 7.1.x → 7.2.0.5226 (#552, #565, #576).

We're switching to your v7.2.1 AppImage from https://github.com/Arm4g3ddon/CrealityPrint/releases/tag/v7.2.1 and will test filament/process/cooling edits over the next days. Will report back here whether it holds up on our setup.

Hope Creality merges PR #572 upstream soon — your fork is keeping Linux usable in the meantime. Thanks again.

[Arm4g3ddon]

@ricksouzaa You're very welcome — glad it helps! And sorry I didn't point to the fork earlier in these threads; I honestly didn't expect the PR to sit unreviewed for this long, or Creality to be this slow on a core regression. I assumed it'd be picked up quickly and didn't want to spam.

Please do report back how v7.2.1 holds up on your K2 Pro / Ubuntu 24.04 (Wayland) setup — especially the exit behavior, since that crash-on-shutdown fix (#577) is still not in Creality's builds. If anything misbehaves I'm happy to look into it.

[ricksouzaa]

@Arm4g3ddon Quick follow-up after installing your v7.2.1 AppImage — thank you again, preset editing works on our side so far.

Question: is Portuguese (pt_BR) available in your community build? On our Ubuntu 24.04 setup the UI appears English-only. We extracted the AppImage and resources/i18n/ only contains placeholder.txt (no .mo translation files), so we assume translations were stripped from the Linux packaging.

Would it be possible to ship pt_BR (and ideally other locales) in a future v7.2.x release — e.g. by bundling the same i18n assets from upstream Creality Print?

We're happy to test a build with Portuguese and report back. Thanks!

[Arm4g3ddon]

@ricksouzaa Good catch — you were exactly right. The Linux packaging never compiled the .po files, so resources/i18n/ only had the placeholder.txt and the UI fell back to English.

I've fixed it and re-uploaded the v7.2.1 AppImage in place (same release/URL, just re-download):

https://github.com/Arm4g3ddon/CrealityPrint/releases/tag/v7.2.1

It now bundles all 19 locales, including pt_BR: ca cs de en es fr hu it ja ko nl pl pt_BR ru sv tr uk zh_CN zh_TW. Portuguese should show up automatically if your system locale is pt_BR (or wherever the language is selected in Preferences).

Root cause for the maintainers: the .mo files come from a standalone gettext_po_to_mo CMake target that the default build doesn't run, so the Linux package ships empty translations. I've added that step to the build in PR #572.

(new sha256: 08c4c6f6d676d3086c395c8d27092352cdf03cb323264aa6272f3b28ca2729be)

Let me know if pt_BR comes through on your K2 Pro setup!

[ricksouzaa]

@Arm4g3ddon Thank you so much for your work — everything is working perfectly on our setup now.

Environment: Ubuntu 24.04 (Wayland), K2 Pro, v7.2.1 build with translations (sha256 08c4c6f6…).

Confirmed:

• Preset editing (filament / process / cooling) works — no read-only fields
• UI in Portuguese (pt_BR) after the i18n rebuild

We really appreciate the fork and how quickly you fixed the language issue. Hope Creality merges PR #572 upstream soon. 👍

[Arm4g3ddon]

@ricksouzaa That's great to hear — thanks a lot for testing and reporting back on real K2 Pro / Wayland hardware, it really helps to have independent confirmation (preset editing + pt_BR both working). 🎉

Enjoy the fork, and if you hit anything else on Linux down the line just ping me here. Fingers crossed Creality picks up #572 (and the exit-crash fix in #577) upstream so this eventually lands for everyone without a fork. Happy printing! 🖨️

[pjJedi]

Thanks so much @Arm4g3ddon I have been struggling for the longest time.

Maybe its just me, but the bed print temperature issue is still around. It takes the temp from the first slot in the CFS and uses that temp.

[Arm4g3ddon]

@pjJedi Glad the fixes are working for you!

That bed-temperature behavior isn't a bug — it's an intended, configurable setting. The bed is a single heater, so for multi-material prints the slicer has to pick one temp. Look in Printer settings → Basic information (Advanced toggle on) for "Bed temperature mode". It's currently set to "Use first material" (slot 0), which is exactly what you're seeing. Switch it to "Use max of all materials" to use the highest bed temp among the filaments in the print — usually the safer choice for adhesion.

This is standard upstream (Orca/Bambu) behavior and unrelated to the Linux fixes. If "Use max" still doesn't cover your case, better to open a separate issue than track it here.

[pjJedi]

@Arm4g3ddon thanks. Its just weird, the previous version used to take the bed temp of the filament i was using? I have both PETG and PLA in my CFS, so when i chose PETG it would use that temp and when i chose PLA it would then use that temp. Just a little unexpected.

[deereslv]

@Arm4g3ddon Thanks a lot for the fix. Everything works.
I am on linux mint 22.3 (ubuntu 22.04), default X11, not wayland.
Just a note for someone who wants to use AI feature(I don't), if you open AI chat there's an message :
" Version update required
The current host version is 7.2.1. Please update to version 7.2.0.5226 or later to keep using this feature."

Thanks again

[Arm4g3ddon]

@deereslv Thanks for flagging that — good catch, and you actually pinpointed a real regression in my fork rather than an upstream issue.

Root cause: the AI chat isn't gated locally — the panel loads Creality's remote page (cxagent.crealitycloud.com) and passes the app version as a query param. Creality's backend then requires version >= 7.2.0.5226. To publish clean versioned AppImages I was forcing the fork version to a 3-part 7.2.1, which their backend treats as older than 7.2.0.5226 (it expects the 4-part major.minor.patch.build scheme) — so the AI feature locked you out even though the build was newer. Nothing wrong on your side.

Fixed by reporting the host version as a proper 4-part 7.2.1.5226 (≥ 7.2.0.5226). New release:

https://github.com/Arm4g3ddon/CrealityPrint/releases/tag/v7.2.1.5226

Still includes everything from v7.2.1:

• Settings/presets editable again (Linux 7.1.0.4414: settings UI becomes read-only after clean install (filament/process/printer) #552 / Linux 7.1.1.4472: settings UI becomes read-only after clean install (filament/process/printer) #565 / Linux 7.2.0.5226: CRITICAL — preset UI still read-only after 3 releases (#552 #565) — fix or acknowledge #576)
• No crash on exit (Fix Linux segfault on application exit (dead GL context in global destructors) #577)
• 19 bundled locales incl. pt_BR
• Builds cleanly under GCC 13 / Ubuntu 24.04

sha256: 40fdc1fecd9ddf353cafcef89b52a9c2a4d5d75747ac96d252647749c78b0908

If you (or anyone) do use the AI chat, let me know whether it comes through cleanly now. Thanks again for the report! 🙏