Linux AppImage -> FLATPAK notes in 2.8.1-rc1

[eduncan911]

A serious caution about the Flatpak note for Linux AppImages users here in the latest 2.8.1-rc1 release notes.

By design, Flatpak purposely does not have access to the standard XDG config directories - where all PrusaSlicer config profiles live and are stored today. E.g. ~/.config/PrusaSlicer. There are a few decisions to make when switching to Flatpak, and this issue is opened to start those discussions publicly so we can have a word in how this is developed. :)

Basically, we are hoping to avoid the ugly additional steps such as:

flatpak run \
  --filesystem=xdg-config/:create \
  --filesystem=xdg-cache/:create \
  --filesystem=xdg-data/:create <pruaslicer-app-id> 

But to keep PrusaSlicer sandboxed, that may be an acceptable upgrade path to those with previous prusaslicer installs. And one that should be noted in the release notes.

Other users may have some other gotchas, but that's the biggest I've ran into over the years.

[buhman]

This could be best solved by implementing #12968 , keeping AppImage builds, and disabling webkit by default on AppImage builds.

[CRCinAU]

Ya know, I've sang Prusa's praises for keeping AppImage around and making it a small, self-contained package that 'just works' everywhere.

It's be a shame if it came to relying on flatpak due to developer laziness. It pulls in entire ecosystems of stuff that's already on systems in package format.

[Pitel]

I also thought that including WebKit was just a quick hack to integrate PrusaConnect (which I'm actively using). But the next step should be to implement the proper API, so we don't need this huge library just to upload a file and show some icons. From what I remember, when integrating OAuth login, you'd just need to temporarily run a local web server to receive the tokens.

[novaplusplus]

My own 2cents... I decided to try the flatpak version after being disheartened by the news appimage was going away (appimage is my preferred way of getting and keeping software on linux, I like having a drive full of applications I can just load up anywhere without needing to worry about repositories and such)

So... to set it all up properly, I had to figure out a few things. First it took a while to get it rendering in a dark theme, I ended up installing Flatseal to change an environment variable that it seems to have set at first. Eventually I found where the config folder ended up (more my fault, I forgot there was a menu item to open it). But I am also still trying to figure out why it can't network properly, I assume some flatpak permissions thing... it doesn't seem able to access zeroconf .local addresses like my klipper host uses.

In other words: Please don't get rid of the appimage... if it comes down to "we can't offer prusa connect in the appimage version" then so be it.

[TheAssassin]

(Disclaimer: AppImage project maintainer and long-time PrusaSlicer user here.)

The issue appears to be related to three facts:

• a) Prusa decides not to bundle WebKit
• b) WebKit >= 4.1 apparently is not backwards compatible to WebKit <= 4.0
• c) Prusa added this "Phyiscal Printer" feature

Let's have a look at these one by one.

We probably cannot do a lot about b). I'm sure Prusa's engineering tried to work around those issues they are seeing, but have not found a solution. I may have a look at the issue tracker to understand what the problem is (maybe we can solve those problems).

Regarding c), I'm sure many people could live without this tab in PrusaSlicer 2.8+ for the AppImage only. From a product perspective, I don't think it's desirable for Prusa as a company to offer such a special build that lacks features (because that then needs to be explained to users again), but on the other hand, that can be solved by showing a short explanatory text within PrusaSlicer on said tab in the UI. People already pursue this, see, e.g., this PR.

Reversing the decision behind a) would be the way to pursue anyway, though, at least in my opinion. AppImages are designed not to depend on non-system libraries. WebKit certainly does not qualify as a system library, it's almost always installed as a dependency of some application. The AppImage really should ship it either way. It should(!) be possible given that any Electron-based AppImage and a lot of other applications do so, but I'm not familiar with PrusaSlicer's build to promise anything.

There have been attempts at improving linuxdeploy-plugin-gtk (linuxdeploy being one of many tools to make creating AppImages and other portable bundles easier) and other linuxdeploy plugins to ship WebKit. See, e.g., https://github.com/linuxdeploy/linuxdeploy-plugin-gtk/pull/37, where it is shown that the people behind Tauri managed to implement a portable method to ship WebKit with the help of linuxdeploy. We know that shipping Qt's WebKit integration also works fine.

TL;DR: Prusa should try to include WebKit. That'll solve the problem and it'll make PrusaSlicer more portable. If that is too much effort, I wouldn't mind AppImages that just do not ship the WebKit-based features.

Please don't hesitate to reach out if you have questions. The AppImage folks have seen the wildest problems and in most cases, we found a solution.

[vega-d]

I don't see desktop applications on linux going any other way than flatpak. It's a large ecosystem of apps that allows the developer to actually do the development and not have to do silly things with packaging for multiple distros. While having a portable application format sounds nice in theory, in reality when people install prusa slicer they usually install it for a long time since they now own a printer and use the slicer for it, so is the portable executable really necessary?

Having it in a repository like flathub would simplify updates - instead of being nagged for updates on launch (and dismissing the update because you just want to get to slicing) it can be updated along with everything else in the software store application.

Using flatpak's runtimes (like the gnome runtime that already includes WebKitGTK) would reduce the size of the slicer for linux users as flatpak would handle the dependencies in the runtime (you the developer develop against a certain version and the flatpak client keeps that version for the application, if multiple apps use the same runtime you only need to have the runtime once).

I didn't even know prusa slicer does an appimage until I visited the github repository, because instead of hunting the web for executables I just looked it up in the software store which gave me the unofficial flatpak. And i've been using it for the longest time with it working just fine. While I can't say my experience is universal, it does appear to involve less friction than keeping up with updates by downloading appimages all the time.

appimages are not really the universal "applications that run anywhere" format they claim to be if you have to package and test multiple packages for different distros. Flatpaks are, anywhere there's a working flatpak client you can run any flatpak.

• S pozdravem Vega Č.

[johnolinda]

Hello! I am sure I am in an extremely small minority, but I am a Linux user who also uses post-processing scripts. With the Flatpak version of PrusaSlicer I am unable to run them since PS is not able to see the entire filesystem or execute arbitrary code. The Appimage version works perfectly. I understand there are packaging issues with Webkit that are probably going to lead to the Appimage being deprecated. Will there be instructions on how to properly configure the Flatpak version to run post-processing scripts?

JimB over at the Prusa forums has been helping me troubleshoot and as far as we can tell, the only way to run post-processing scripts based on Perl is to basically do an install of Perl inside the Flatpak sandbox. This doesn't seem to affect Bash or Python scripts in the same way though. I would appreciate some feedback on this, and how to work around this with the Flatpak version (without doing a whole separate Perl install) if this is the way things are going moving forward.

[SachCZ]

Hello @johnolinda, you should be able to achieve what you want by running slicer like this:

flatpak run --talk-name=org.freedesktop.Flatpak com.prusa3d.PrusaSlicer

and in the Post processing scripts window:

flatpak-spawn --host dostuff

where dostuff is what you had there previously.

[johnolinda]

OK, just for documentation's sake, here's what I did (using Flatseal) to make this work normally through the GUI. First, I enabled the Socket > D-Bus session bus setting, then added /tmp to Filesystem > Other files. Then I reconfigured the script command with flatpak-spawn --host as recommended and everything appears to work normally now. I'll test the Flatpak and report back if I notice further issues.