Prusaslicer: Feature request: Support Flatpak / Snap / linux 'app store' distribution

[mrjohnc]

Adding Slic3r Prusa Edition to Gnome software would make it easier to install and keep up to date on Linux distributions using Gnome (which many of the most popular Linux distros use)

https://wiki.gnome.org/Apps/Software

[bubnikv]

Slic3r is written using wxWidgets toolkit over GTK2 (or GTK3), so it is officially not a Gnome application. Also there is a Slic3r PE package for Debian, Ubuntu and likely other distros, so if you don't like the AppImage format we provide, you can likely install Slic3r PE from your distro, though it will likely be a bit older version.

Now I don't understand the request. Why should there by a Gnome app repository, if the distribution model for applications on Linux is the distro?

Maybe @vojtechkral has an idea?

[mrjohnc]

Sorry I'm not explaining very well, basically I want to be able to install Prusa Slic3r from the sofware centre thing that comes in Ubuntu (like you can do with Cura). Whilst I know how to install the software in the other ways it would lower the barrier to others to be able to do this and would allow people to keep it up to date easily.

[vojtechkral]

Ubuntu Software Center is discontinued. Gnome Software is active, but it is, as far as I know, more or less just a frontend to distro package managers. So basically better package presence would be likely needed.

[grigorig]

I think what OP might really mean is that Slic3r PE should use a standard distribution mechanism, such as Snap or Flatpak that is portable and independent from a specific distribution. Sort of like AppImage, but more suitable for the "app store" use case and with better security/isolation.

[mrjohnc]

@grigorig yes this is exactly what I meant, thanks very much

[mrjohnc]

@bubnikv feel free to rename to how @grigorig explains

[mrjohnc]

Coupled with this it would be really great to have the software know when it needs updating and be able to update with pressing a button. I've see a lot of software in Flatpack and the Ubuntu Software appstore get behind current versions, and this is a way around the issue

[probonopd]

What would be needed is a Plugin for GNOME Software to manage applications in the AppImage format. I had started writing this some time ago but lost interest in it (since I lost interest in GNOME), anyone is free to pick it up and revive it: https://gitlab.com/probono/gs-plugin-appimage

[grigorig]

Maybe a Flatpak would be a good idea at this point? I'm not sure if that would be a lot of work, probably not. It might even be possible to just package the AppImage inside a Flatpak.

[xarbit]

Just came across this ticket while looking if PrusaSlicer exist as Flatpak. Well, I guess not..
I am willing to do this task and Ill create project for it and if prusa wants, then you can simply take over it any time. :-)

[xarbit]

@bubnikv you can add me as the volunteer for this task :)

[xarbit]

The application is submitted to FlatHub and is awaiting review.
If this is something the Prusa development/release wants to have control over please let me know.

Feel free to try the flatpak bundle from my repository:
https://github.com/xarbit/com.prusa.PrusaSlicer/releases/tag/v2.2.0-flatpak-testing-1

From my view, now I can finally use my new Fedora Silverblue workstation connected to my MK3s printer :-)

[probonopd]

From my view, now I can finally use my new Fedora Silverblue workstation connected to my MK3s printer :-)

Does the AppImage not work for you? If so, which error did you get?

[xarbit]

Honestly I did not use the AppImage because we want to use flatpak. :)
I assume it would have worked, it is just not my way to execute software.

[kate-shine]

From my view, now I can finally use my new Fedora Silverblue workstation connected to my MK3s printer :-)

Does the AppImage not work for you? If so, which error did you get?

I use appimage on Silverblue, but the Flatpak support will be much better. If only for better system integration and automatic updates.

[probonopd]

Just for completeness, if you want system integration you can use appimaged or AppImageLauncher, and for updates the Prusa team could enable update information so that AppImageUpdate can be used.

[grigorig]

Neither of these are commonly available. Flatpak is a much better choice and already used and installed by default on most, if not all, mainstream Desktop-centic Linux distributions.

[kate-shine]

Just for completeness, if you want system integration you can use appimaged or AppImageLauncher, and for updates the Prusa team could enable update information so that AppImageUpdate can be used.

Of course I can, but I really don't like mixing packaging systems on my distro. It's messy. And while Flatpak is widely supported and integrated in many distributions, I don't know about any using appimaged :)

Also, one of main reasons for this is convenience: Plenty of users who aren't experienced can find flatpaks in their package manager.

While Appimage works well, I wouldn't call it convenient or intuitive at all. From the unexperienced user's perspective:

I downloaded the slicer, how do I run it?
Not as easy

How do I add it to the system menu?

So, It runs, but I still have the "installer" in Downloads, I'll just delete it, what could go wrong?

[xarbit]

@bubnikv who can I add to have write access to the flathub PrusaSlicer repo once it is created?

[xarbit]

flathub has accepted the PrusaSlicer application, it should arrive in the flathub channel for anyone to use shortly.

For the time being I will be the maintainer of this package until upstream (Prusa) is willing to take over this (which should be the goal).

The manifest for this can be found:
https://github.com/flathub/com.prusa3d.PrusaSlicer

Dear Prusa Team, if you need write access and want to take ownership, just open a ticket and FlatHub will take care of this.

I assume this also means this ticket can be closed.

[probonopd]

For the time being I will be the maintainer of this package until upstream (Prusa) is willing to take over this (which should be the goal).

While I appreciate your effort, I think cautious users should always download software directly from the official website of the author rather than from any third parties, because only this way one can be 100% sure that the software is delivered unmodified and exactly in the way the author wants it and supports it. This is why I personally avoid downloading applications from anywhere but the original application author's download page.

I mean, looking at the Flathub repository, it seems like the whole application and its dependencies are built on yet another system (as opposed to Prusa's build system). Who is going to guarantee that the exact same versions of e.g., WxWindows are going to be used, and even if they were, that they are going to be compiled using the exact same compilers etc.?

It seems like that Flathub approach means that the result are different binaries which are not covered by Prusa's existing end-to-end tests, and hence would require additional support effort.

[xarbit]

For the time being I will be the maintainer of this package until upstream (Prusa) is willing to take over this (which should be the goal).

While I appreciate your effort, I think cautious users should always download software directly from the official website of the author rather than from any third parties, because only this way one can be 100% sure that the software is delivered unmodified and exactly in the way the author wants it and supports it. This is why I personally avoid downloading applications from anywhere but the original application author's download page.

I mean, looking at the Flathub repository, it seems like the whole application and its dependencies are built on yet another system (as opposed to Prusa's build system). Who is going to guarantee that the exact same versions of e.g., WxWindows are going to be used, and even if they were, that they are going to be compiled using the exact same compilers etc.?

It seems like that Flathub approach means that the result are different binaries which are not covered by Prusa's existing end-to-end tests, and hence would require additional support effort.

I do respect you and appreciate your work on AppImage. But seriously? Those arguments are very extreme and pure FUD. I went through the Prusa documentation applied all the suggestions and followed the cmake files and used mostly the same versions and flags.

Cannot believe this. You know people should use what they want to and I don’t care about politics too much.
I did this because I needed this and obviously others too. That is the spirit of open source.

[kate-shine]

@probonopd so, I guess you don't even use distribution repositories? Because quite obviously, plenty of packages there are linked to libraries with versions different from those used by their developers.

The fact that you prefer appimage is quite obvious from your sealioning, but the reasons why it's not a good option for others were explained here.

This issue was marked as "volunteer needed", so what's your problem with @xarbit doing exaclty that?

[ivocavalcante]

Well, volunteer here. I've created a Snap package for PrusaSlicer, already available here: PrusaSlicer Snap. It would be great if it was merged upstream, and published under an official Prusa account on Snapcraft.

I volunteer to maintain the package as needed, if allowed. Source is here: ivocavalcante/PrusaSlicer/snap.

[bubnikv]

@xarbit @ivocavalcante

Thank you guys for your effort packaging our application as FlatPack and Snap. I understand you would like us to take that over. However as of now we don't have the resources in house to do that. As of now (the PrusaSlicer 2.3 and the upcoming PrusaSlicer 2.4) we would be happy, if you could update your packages after our releases.

In the same fashion, there are deb, rpm and aur packages, that we do not directly support. We help the maintainers if they need our help though.
https://src.fedoraproject.org/rpms/prusa-slicer
https://packages.debian.org/sid/main/slic3r-prusa
https://www.archlinux.org/packages/community/x86_64/prusa-slicer/

It seems like that Flathub approach means that the result are different binaries which are not covered by Prusa's existing end-to-end tests, and hence would require additional support effort.

I do respect you and appreciate your work on AppImage. But seriously? Those arguments are very extreme and pure FUD. I went through the Prusa documentation applied all the suggestions and followed the cmake files and used mostly the same versions and flags.

I did not review the FlatPack by @xarbit. AFAIK the FlatPack is supposed to support the concept of shared libraries packed as FlatPack. I suppose this is what @probonopd mentioned when he expressed his concerns about the binary produced by you to work as well as the binary produced by us. We use a particular wxWidgets library and we do patch the wxWidgets library if needed to patch various quirks and improve performance.

We (Prusa Research) could only guarantee the correctness of our builds only and we really appreciate the simplicity of the AppImage and that AppImage does not require any other dependence. I did not use Linux on desktop for a long time myself. I installed Ubuntu on my company desktop couple of months ago to use it as a daily driver and I think that by default the flatpack server is not there as it is a competing solution to their own snap. Now we have many users who are not very technical and they have no idea what a flatpack is. For them the AppImage is likely a simpler solution then to study and install a flatpack support system on their Ubuntu. I don't claim I am correct as I am not a seasoned Linux desktop user though, take it as an impression of an average non-technical Linux user.

[xarbit]

@bubnikv thanks for your input. I will update the flatpak in the upcoming days.

[ivocavalcante]

Ok @bubnikv , very understandable. I'll keep updating Snap as well.