Package Details: anycubicslicernext-bin 2.0.0.5-1

Git Clone URL: https://aur.archlinux.org/anycubicslicernext-bin.git (read-only, click to copy)
Package Base: anycubicslicernext-bin
Description: Anycubic Slicer is an open source slicer for FDM printers
Upstream URL: https://github.com/ANYCUBIC-3D/AnycubicSlicer
Licenses: AGPL-3.0
Submitter: demitriusbelai
Maintainer: demitriusbelai
Last Packager: demitriusbelai
Votes: 5
Popularity: 0.50
First Submitted: 2025-09-02 02:36 (UTC)
Last Updated: 2026-09-21 03:13 (UTC)

Pinned Comments

demitriusbelai commented on 2026-09-05 01:07 (UTC) (edited on 2026-09-05 01:08 (UTC) by demitriusbelai)

Guys, please only flag the package if there is a new version available for Linux. The last DEB package does have this version number; it’s not V1.3.9.4 as listed on the website. I follow the version number of the DEB package.

V1.3.9.4: develop_AnycubicSlicerNext-1.3.96_20260319_224609-Ubuntu_24_04_3_LTS.deb
V1.3.96:  develop_AnycubicSlicerNext-1.3.96_20260131_153250-Ubuntu_24_04_3_LTS.deb

Latest Comments

1 2 3 4 Next › Last »

enderst commented on 2026-09-30 01:50 (UTC)

I don't know about the others but in this latest 2.x version I no longer need to start it with: __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json

kyonlion commented on 2026-09-21 01:41 (UTC)

v2.0.0.5 debian binary is released. https://cdn.anycubic-cloud.anycubic.com/file/2026/09/16/deb/178954445581729900/AnycubicSlicerNext_linux-v2.0.0.5-20260913065625.deb

demitriusbelai commented on 2026-09-05 01:07 (UTC) (edited on 2026-09-05 01:08 (UTC) by demitriusbelai)

Guys, please only flag the package if there is a new version available for Linux. The last DEB package does have this version number; it’s not V1.3.9.4 as listed on the website. I follow the version number of the DEB package.

V1.3.9.4: develop_AnycubicSlicerNext-1.3.96_20260319_224609-Ubuntu_24_04_3_LTS.deb
V1.3.96:  develop_AnycubicSlicerNext-1.3.96_20260131_153250-Ubuntu_24_04_3_LTS.deb

mafri commented on 2026-08-02 19:26 (UTC)

Sorry, I was not clear, English is not my first language.

The relevant database is the per-user one, not the system one: ~/.local/share/mime, not /usr/share/mime. A user-level mapping of *.html to anything other than text/html is enough, and it takes precedence over the system database. Your strace shows that order, ~/.local/share/mime/mime.cache is the first file opened. A live session or a fresh install has no user database yet, which is why it renders there.

Such mappings are written automatically by desktop tools and are legitimate. The point is that the slicer sends Content-Type: text/html as a header but never calls webkit_uri_scheme_response_set_content_type(). WebKit does not use that header for scheme responses, it derives the type from the file name, so rendering depends on the user's MIME database instead of on what the application sends. The patch removes that dependency.

demitriusbelai commented on 2026-08-02 13:33 (UTC)

@mafri There is no html entry in my ~/.local/share/mime/globs, but there is one in /usr/share/mime/globs. It comes from /usr/share/mime/packages/freedesktop.org.xml, which is provided by the shared-mime-info package. That package is required by libxml2, which in turn is required by webkit2gtk-4.1. "xdg-mime query filetype <some.html>" returns text/html here. You may have another MIME package with a higher priority that is overriding it. Please check:

grep -R x-extension-html /usr/share/mime/packages

I tested this on a Manjaro live environment and observed the same behavior. I also reproduced it on an fresh Arch Linux installation on my old PC.

I investigated which MIME files WebKit loads at runtime:


LANG=C strace -f -e trace=open,openat ./run.py 2>&1 | grep mime
[pid  8493] openat(AT_FDCWD, "/home/demitrius/.local/share//mime/mime.cache", O_RDONLY) = 30
[pid  8493] openat(AT_FDCWD, "/home/demitrius/.local/share/flatpak/exports/share/mime/aliases", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/home/demitrius/.local/share/flatpak/exports/share/mime/subclasses", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/home/demitrius/.local/share/flatpak/exports/share/mime/icons", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/home/demitrius/.local/share/flatpak/exports/share/mime/generic-icons", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/var/lib/flatpak/exports/share/mime/mime.cache", O_RDONLY) = 30
[pid  8493] openat(AT_FDCWD, "/usr/local/share/mime/aliases", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/usr/local/share/mime/subclasses", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/usr/local/share/mime/icons", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/usr/local/share/mime/generic-icons", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid  8493] openat(AT_FDCWD, "/usr/share/mime/mime.cache", O_RDONLY) = 30

mafri commented on 2026-08-02 08:25 (UTC)

Found it, and it explains why you are not affected. The Workbench response carries no explicit content type, so WebKit derives one from the file name. That lookup goes through the shared MIME database, where a per-user database in ~/.local/share/mime takes precedence over the system one. On my machine *.html resolves to application/x-extension-html there, and WebKit refuses to display that type, which is what aborts the load.

grep '\*\.html' ~/.local/share/mime/globs

Anything other than text/html there means a blank Workbench. If the file does not exist, WebKit uses the system database and the tab renders, which is your case. This also explains krumel's observation that it works under sudo. root has a different home, so a different user database.

None of this changes the diagnosis. The app does send Content-Type: text/html as a header, it just never calls webkit_uri_scheme_response_set_content_type(), and WebKit does not take the type of a scheme response from that header. As long as the type is guessed from the file name, the outcome depends on the user's MIME database instead of on what the app intended, which is exactly why guessing is the wrong thing to rely on. The shim sets the type explicitly, which is what the application should be doing.

demitriusbelai commented on 2026-08-02 02:08 (UTC)

I hope I indented the source correctly: https://gist.github.com/demitriusbelai/fc8cbc9463498bc5b1f5c9987400447b

Result:


WebKitGTK 2.52.5

 .html  -> text/html                        displayable=True ok
 .js    -> text/javascript                  displayable=True ok
 .css   -> text/css                         displayable=True ok
 .svg   -> image/svg+xml                    displayable=True ok

NOT AFFECTED: this WebKitGTK types the response as 'text/html' and will display it.

My version: webkit2gtk-4.1 2.52.5-2

Thank you for the minimal test case. I'll try another PC. I once ran into a CPU bug in a zlib optimization.

mafri commented on 2026-08-01 06:05 (UTC) (edited on 2026-08-01 06:06 (UTC) by mafri)

No idea, honestly :( but here is a small script that answers it without needing the slicer. It reproduces the pages:// handler and prints what your WebKitGTK makes of the response. Only needs python-gobject, webkit2gtk-4.1 and a graphical session.

Mine, on webkit2gtk-4.1 2.52.5-2:

WebKitGTK 2.52.5
  .html  -> application/x-extension-html   displayable=False  FAILS
  .js    -> text/javascript                displayable=True   ok
  .css   -> text/css                       displayable=True   ok
  .svg   -> image/svg+xml                  displayable=True   ok

Only HTML fails. Same distro, same kernel, both AMD/Wayland - so the WebKit build is my best guess for the difference. Could you post your output plus pacman -Q webkit2gtk-4.1?

webkit-mime-probe.py #!/usr/bin/env python3 import sys import gi gi.require_version("Gtk", "3.0") gi.require_version("WebKit2", "4.1") gi.require_version("Soup", "3.0") from gi.repository import Gtk, WebKit2, GLib, Gio, Soup HTML = (b"<html><head><title>probe</title></head>" b"<body><div id='app'></div></body></html>") # Extensions the Workbench actually serves over pages://. PROBES = ["html", "js", "css", "svg"] context = WebKit2.WebContext.get_default() def handle_request(request, _user_data=None): """Answer exactly the way the slicer's pages:// handler does.""" stream = Gio.MemoryInputStream.new_from_data(HTML) headers = Soup.MessageHeaders.new(Soup.MessageHeadersType.RESPONSE) headers.append("Content-Type", "text/html") response = WebKit2.URISchemeResponse.new(stream, len(HTML)) response.set_status(200, None) response.set_http_headers(headers) # Deliberately no response.set_content_type() — that is the missing call. request.finish_with_response(response) context.register_uri_scheme("pages", handle_request, None) window = Gtk.Window() window.set_default_size(320, 240) view = WebKit2.WebView.new_with_context(context) window.add(view) window.show_all() results = {} queue = list(PROBES) def probe_next(): if not queue: Gtk.main_quit() return ext = queue[0] view.load_uri(f"pages://localhost/Workbench/probe.{ext}") def on_policy(_view, decision, decision_type): if decision_type == WebKit2.PolicyDecisionType.RESPONSE and queue: ext = queue.pop(0) results[ext] = (decision.get_response().get_mime_type(), decision.is_mime_type_supported()) GLib.idle_add(probe_next) return False view.connect("decide-policy", on_policy) GLib.idle_add(probe_next) GLib.timeout_add_seconds(30, Gtk.main_quit) Gtk.main() print(f"WebKitGTK {WebKit2.get_major_version()}.{WebKit2.get_minor_version()}" f".{WebKit2.get_micro_version()}\n") for ext in PROBES: mime, supported = results.get(ext, ("<no result>", None)) mark = "ok" if supported else "FAILS" print(f" .{ext:<5} -> {mime:<32} displayable={supported} {mark}") html_mime, html_ok = results.get("html", (None, None)) print() if html_ok: print("NOT AFFECTED: this WebKitGTK types the response as " f"{html_mime!r} and will display it.") sys.exit(0) if html_mime is None: print("INCONCLUSIVE: no policy decision was observed. Needs a graphical session.") sys.exit(2) print(f"AFFECTED: WebKitGTK types the HTML response as {html_mime!r} and refuses " "to display it.\nThat is what leaves the Workbench tab blank.") sys.exit(1)

demitriusbelai commented on 2026-08-01 00:30 (UTC)

@mafri Thank you for investigating this issue. I have one question: could you please explain why I am not affected by this problem?

Operating System: Arch Linux KDE Plasma Version: 6.7.3 KDE Frameworks Version: 6.28.0 Qt Version: 6.11.1 Kernel Version: 7.1.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800XT 8-Core Processor Memory: 32 GiB of RAM (31.2 GiB usable) Graphics Processor: AMD Radeon RX 6600 Manufacturer: ASUS

mafri commented on 2026-07-31 21:11 (UTC)

This looks like the blank Workbench tab that krumel, Scaphism and Renard reported below. I tracked down what causes it on my machine.

The application serves the Workbench through its private pages:// URI scheme, but the scheme handler never calls webkit_uri_scheme_response_set_content_type() it only sets a Content-Type header, which WebKitGTK does not use for scheme responses. WebKit therefore guesses application/x-extension-html, webkit_response_policy_decision_is_mime_type_supported() returns false, the wxWebView policy handler calls webkit_policy_decision_ignore(), and the load aborts with "Frame load interrupted". index.html is fetched but never parsed, so not a single script is loaded and the tab stays empty.

This is independent of the EGL/NVIDIA problem discussed here: it reproduces on Mesa/amdgpu with no __EGL_VENDOR_LIBRARY_FILENAMES workaround needed.

Since the binary cannot be patched, an LD_PRELOAD shim that sets the content type for pages:// responses fixes it; it touches no other scheme. I have a patch adding the shim to the PKGBUILD plus one export LD_PRELOAD= line in AnycubicSlicerNext.sh, verified against HEAD with makepkg; the Workbench renders afterwards. Happy to mail it over or paste it here, whichever you prefer. Also reported upstream as https://github.com/ANYCUBIC-3D/AnycubicSlicer/issues/64#issuecomment-5147342284, where the proper one-line fix belongs.

1 2 3 4 Next › Last »