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?

[kate-shine]

On a modern Linux system you need to update flatpak, apt, and snap (among others) and missing a single one of them is putting your system at risk.

On a modern Linux system, you usually have some update manager, that does that for you, including snap and flatpak. If you don't have one, you are probably using some more DIY distro like Arch, and then you should be experienced enough to handle it yourself.

Of course I recommend you to use the official release channel. I'm not sure you are aware of the process a package maintainer needs to go through to update the package. That PS flatpak doesn't automatically update itself. This kind soul that offered to do so must:

You are literally answering under the issue of people asking upstream to start maintaining flatpaks as well. So, your objections about the unofficial package are quite offtopic. Yes, it's slightly outdated, but what point are you exactly trying to make here in this thread?

[mrjohnc]

I'm unsubscribing due to toxicity, hope this gets completed but not going to stay

[NOVATechnocrat]

I have no objections of the unofficial package, I think it's great that they took up that project. I think it would be great for Prusa to package the slicer in Flatpak among every single other platform/runtime imaginable.

But you know how to update Flatpak now, right?

[kate-shine]

@NOVATechnocrat I am maintaining an official flatpak build of one app. So, what do you think?

But obviously, you did have nothing to say to the topic of this issue and just went here trolling, so whatever.

[NOVATechnocrat]

@NOVATechnocrat I am maintaining an official flatpak build of one app. So, what do you think?

But obviously, you did have nothing to say to the topic of this issue and just went here trolling, so whatever.

All I was saying is that many people advocate technologies they don't understand. You are not disputing that. You are flaming me because I pointed it out. I mentioned a tell-tale sign of a person that does such a thing, is one that doesn't know how to update flatpak.

What would you call a person that -after using flatpak for years- just realizes you have to manually update it? I call that person an utter noob, a liability to any network that person is on, a person breaking the number one rule of security which is failing to UPDATE a system.

I mean it in a good way. A "get it together, TIGHTEN UP" type of way.

Why are YOU taking offense to that? I don't want to insinuate you are just finding that out, but you are acting like it.

I'm not trolling. After reading every comment here, I am certain there are misconceptions about flatpak technology. Such as that flatpak provides some automagic update mechanism. If Prusa were to release an update, nothing would happen at all. You would NEVER receive an update notice through flatpak.

Until when? At what time would you receive a notification to update the package? When does this notification to update appear?

After you pointed out the necessity to update, your proposed solution is to use the release channel that doesn't allow for simple updating and doesn't allow the update of runtime environment independently from the packaged app. Amazing.

The best way to have an up-to-date Prusa Slicer application is to keep checking yourself, everyday, sign-up for their newsletter, their RSS feed, whatever you have to do to be alerted that they updated it, and then download it yourself. This is because Prusa (it appears) doesn't natively offer flatpak support. They offer appimage. I'm not saying appimage or flatpak is better than one another. I'm saying Prusa supports appimage and because of that, you are best served getting it from their release channel: Full Stop.

You are putting 100% faith that the maintainer will check for updates every day? How often is a suitable response time for a package maintainer? If PS releases an update and the package maintainer doesn't get around to it for a month, meaning you don't receive a notification in flatpak that there is an update available, is that suitable for you? I has to be. The maintainer is doing it from their own good graces and you have no control over it -at all-.

With that being said, in order to have the most up-to-date (and most secure) appimage possible, you will check Prusas site as often as possible and download it directly from there. Unless you have an argument to that, please leave me alone and no I'm not trolling you.

You flamed a guy and said he was "sealioning" (laff) when he made an entirely coherent and accurate statement:

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.

The only valid argument against that comment is: "I just wish Prusa would support flatpak, rather than appimage."

Well, they don't -yet- and as this person points out:

"cautious users should always download software dirrectly from the official website".

You all started arguing THAT and THAT is why I interjected myself in to your argument. If you argue that, then you are wrong and I will not permit you to derail this topic with your hurt feelings without interjecting. Any person that states otherwise should be challenged and be removed from positions of important decision making.

I support the original posters request for Prusa to support flatpak.

[bubnikv]

@kate-shine @xarbit

FYI
https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Linux%20et%20al.md#desktop-integration-prusaslicer-24-and-newer

If PrusaSlicer is compiled with SLIC3R_FHS enabled, then a desktop integration support will not be integrated. One may want to disable desktop integration by running

cmake .. -DSLIC3R_DESKTOP_INTEGRATION=0

when building PrusaSlicer for flatpack or snap, where the desktop integration is performed by the installer.

[bubnikv]

I have created a Wiki page with the 3rd party provided builds.
https://github.com/prusa3d/PrusaSlicer/wiki/PrusaSlicer-on-Linux---binary-distributions

Also the differences in UI look raised by @NOVATechnocrat may be due to a different version of wxWidgets being used by our static builds vs. 3rd party builds.

As wxWidgets 3.1.xx is still considered unstable (binary API is not considered stable), Linux distros often contain old wxWidgets 3.0 only. While PrusaSlicer compiles against wxWidgets 3.0, one may experience some user interface glitches.

[ivocavalcante]

@kate-shine @xarbit

FYI
https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Linux%20et%20al.md#desktop-integration-prusaslicer-24-and-newer

If PrusaSlicer is compiled with SLIC3R_FHS enabled, then a desktop integration support will not be integrated. One may want to disable desktop integration by running

cmake .. -DSLIC3R_DESKTOP_INTEGRATION=0

when building PrusaSlicer for flatpack or snap, where the desktop integration is performed by the installer.

Thanks for pointing out, @bubnikv . Will check on next Snap build.

[xarbit]

@bubnikv thanks .. the flatpak for the upcoming 2.4 is being reworked on and will use the wxwidgets and other dependencies provided by prusa3d and not like before from the flatpak repo.

Its already being built and made available in the beta branch and will be tested.

[xarbit]

Here is the first working PrusaSlicer 2.4-alpha1 as flatpak which uses the dependencies provided by Prusa3d.
The new build also adds the separate Prusa G-Code Viewer and adds Desktop Action (right-click) to open G-Code Viewer.

Please give it a shot and let me know what you think:

flatpak install https://dl.flathub.org/beta-repo/appstream/com.prusa3d.PrusaSlicer.flatpakref

@bubnikv once #6875 is merged, ill remove the desktop files from flathub repo.

[bubnikv]

@bubnikv once #6875 is merged, ill remove the desktop files from flathub repo.

merged

The new build also adds the separate Prusa G-Code Viewer and adds Desktop Action (right-click) to open G-Code Viewer.

That is cool. We may want to update our manual desktop integration in the same fashion. We wonder whether this kind of integration will work on Chrome OS as well, two Desktop files pointing to a single binary did not work.

[xarbit]

@bubnikv does ChromeOS follow the feedesktop.org specifications for .desktop files?
If so, then I don't see why it wouldn't work.. Unfortunately I don't have ChromeBook/ChromeOS to test.

https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

Feel free to look in the desktop file I provided. You might be able to use Desktop Actions.

PrusaSlicer/src/platform/unix/flatpak/com.prusa3d.PrusaSlicer.desktop

Line 16 in c232dec

[Desktop Action GCodeViewer]

[ivocavalcante]

Hi @xarbit and @bubnikv ,

I see the code contains desktop files specific for Flatpak; I really know nothing about Flatpak build system, but wouldn't it be possible to have a single set of desktop files on the code, so Prusa official versions and also Snap package could benefit? I mean, having GCode viewer action is a really cool addition and I plan to bring it to Snap, but since it was added to Flatpak's file version (and I use a buildtime modified version of the "official"), Snap won't get it by default (I can make it get it, but that's not the point). Also, you're including translations, which is also really cool, but again: duplicate files. Is there a way to join these two, so we can all benefit (having actions and adding translations in a single point) ?

I'm not sure this is the right place to post this discussion, but since you're all here, I took the chance. Feel free to move it somewhere else, if you see fit. :)

[xarbit]

@ivocavalcante yes, I agree .. there is a way, even if I have to use "sed" .. I need to do some restructuring and testing to make that possible. But it's doable.

Let me try ..

[ivocavalcante]

Let me try ..

Great, Jason. Let me know if you are successful, so I start adjusting things here too. Thanks!

[xarbit]

@ivocavalcante
yes, I am done implementing on my side and everything is shaping up pretty good.
When you are done adjusting things on you're side, let me know as well so I can remove this part:

https://github.com/flathub/com.prusa3d.PrusaSlicer/blob/1daf65a3590d799806d079a74ab462019fd42f51/com.prusa3d.PrusaSlicer.yml#L227

[ivocavalcante]

Great Jason, I believe I'm all set here. Waiting for changes to be merged.

Edit: to make things clear, it's my understanding that you have a PR ready for this. If this is not true, just let me know and I'll create one. :)

[ivocavalcante]

Well, there it is, @xarbit and @bubnikv . See if it's up to the task.
#7023

[xarbit]

@ivocavalcante #6879 was already created ;-)

[ivocavalcante]

Great! Would you, please, include pt_BR translation I added on my fork? Or you prefer I open a PR to your repo? I'll close my PR.

[xarbit]

@ivocavalcante please if you don't mind, PR to my branch : merge-desktop-files

Thanks

[ivocavalcante]

Done!

[trainmeditations]

@xarbit I'm having issues with the appimages on Debian so I thought I'd check out the flatpak. The wiki said you managed it and to post issues here. I'm having a problem with it though where if I try to launch it from a file nothing seems to happen. I tried opening it from the terminal with xdg-open and got the following

kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
--------------------------------------------------------------------------
Message: 21:57:39: Starting PrusaSlicer flatpak with entrypoint script
--------------------------------------------------------------------------
Message: 21:57:39: INFO: using dark theme variant
No such file: file:///run/user/1000/doc/e7d834e3/3-each-100-75-50.3mf

The file is in that location when I look, the error seems to be because it's using a file:// path

Seems it might be related that I'm on KDE Plasma. I'm not overly familiar with flatpak but I'm trying to find out of there's some element flatpak is missing to make this work. Would be great for your insight though.

[xarbit]

@xarbit I'm having issues with the appimages on Debian so I thought I'd check out the flatpak. The wiki said you managed it and to post issues here. I'm having a problem with it though where if I try to launch it from a file nothing seems to happen. I tried opening it from the terminal with xdg-open and got the following

kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
--------------------------------------------------------------------------
Message: 21:57:39: Starting PrusaSlicer flatpak with entrypoint script
--------------------------------------------------------------------------
Message: 21:57:39: INFO: using dark theme variant
No such file: file:///run/user/1000/doc/e7d834e3/3-each-100-75-50.3mf

The file is in that location when I look, the error seems to be because it's using a file:// path

Seems it might be related that I'm on KDE Plasma. I'm not overly familiar with flatpak but I'm trying to find out of there's some element flatpak is missing to make this work. Would be great for your insight though.

Hi @trainmeditations

thanks ...
The best would be if you could please open an issue here:

• https://github.com/flathub/com.prusa3d.PrusaSlicer/issues

we will look in to it ..

It would also be helpful if you would paste the commands that you tried to do.

Thanks

Jason

[trainmeditations]

@xarbit I'm having issues with the appimages on Debian so I thought I'd check out the flatpak. The wiki said you managed it and to post issues here. I'm having a problem with it though where if I try to launch it from a file nothing seems to happen. I tried opening it from the terminal with xdg-open and got the following

kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
--------------------------------------------------------------------------
Message: 21:57:39: Starting PrusaSlicer flatpak with entrypoint script
--------------------------------------------------------------------------
Message: 21:57:39: INFO: using dark theme variant
No such file: file:///run/user/1000/doc/e7d834e3/3-each-100-75-50.3mf

The file is in that location when I look, the error seems to be because it's using a file:// path

Seems it might be related that I'm on KDE Plasma. I'm not overly familiar with flatpak but I'm trying to find out of there's some element flatpak is missing to make this work. Would be great for your insight though.

Hi @trainmeditations

thanks ...
The best would be if you could please open an issue here:

• https://github.com/flathub/com.prusa3d.PrusaSlicer/issues

we will look in to it ..

It would also be helpful if you would paste the commands that you tried to do.

Thanks

Jason

Done