My experience has been mostly positive. I hit a situation a couple times where a particular app hanging will prevent other flatpaks from launching. That took a while to figure out, but otherwise it’s pretty good. In general things work the way they’re supposed to.
Most apps worked out of the box. It feels like gimp is a little bit (very tiny) slower at starting. For OpenTTD i had to manually add the x11 access in flatseal. And for osu! it is the only way i can play the current version, and that just works.
All the problem I haven encountered with flatpak is short-term (GPU passthrough, wayland support etc), and all of them either dont work or require a one time fix.
Basically if I dont encounter problem on the frist day, I have never encounteted any problem after that, unless a update introduced some bug in the software, of course.
Aside from philosophical issues my experience with Flatpak has been excellent. There’s some theming steps you need to do to make them feel like regular apps, which I feel is clunky design. No Flatpak-induced instability from what I can tell. Setting up directory permissions is sometimes slightly annoying but Flatseal makes it trivial, and most Flatpak permissions are set up properly out of the box these days.
I haven’t noticed any start-time delays when launching Flatpaks as opposed to regular apps - I don’t know if they’ve fixed that or if my system is just too powerful. The only app that I’ve personally noticed is weird is VSCodium, which has trouble escalating to admin permissions when you’re trying to edit privileged files. I still use the regular version for that reason.
I wasn’t able to get the gsettings method to work (I’m on Wayland KDE), and that article doesn’t say anything about theming QT Flatpaks. Also, after “installing” my GTK theme as a flatpak via the method described, it still wasn’t available to my GTK Flatpaks via the GTK_THEME method. The steps in the itsfoss.com article do work, though there’s been a lot of squabbles about the “proper” way to expose themes to Flatpaks. Regardless, this all goes back to my point that theming Flatpak is clunky and should be much smoother.
GTK_THEME is a development env var, it’s not expected to work in many cases. For example GtkSettings:gtk-theme won’t even contain it so apps can be confused.
The post details exactly how it works but yes it’s only about GTK.
Right, I understand it’s not supposed to be used in “proper” usage, but it does work for all my GTK apps and the gsettings method does not work for me. Unless I’m supposed to store it somewhere else because I’m on KDE.
I do have xdg-desktop-portal-gtk on Debian Stable, which is currently at 1.14.1-1. I’ll look around to see if there’s more documentation on this method, because I would prefer to not use the debug variables if possible.
Edit: I launched with GTK_DEBUG=interactive and I can see the theme inside the Flatpak gets set to Adwaita-empty instead of my actual theme, which does get properly returned via gsettings get org.gnome.desktop.interface gtk-theme
That gets my normal GTK theme properly. I found a little more discussion on this here. Nothing very actionable but I did also confirm that my xdg-desktop-portal-gtk is running. It seems like this is supposed to be working, but I have a mostly stock Debian 12.1 KDE install and something seems to be wrong somewhere in the chain. I’ve also tried multiple GTK Flatpaks with the same results.
Edit: Also, I have both my themes folder exposed and the theme installed as a Flatpak via the linked script.
The couple of apps I use through flatpak has not had any issues as far as I can tell. Other than maybe being a little slow to get pushed to the newest version.
I do as well. I really appreciate the information density, key bindings, and optional web UI. Although I found if I leave glance is running for a prolonged amount of time, it has a tendency to crash from some python issue I haven’t dissected yet, as it takes so much time to reproduce.
I always use Flatpaks when available, I have been using it for about 1~2 years and honestly, I haven’t found any issues that are deal breakers, mostly some missing storage permissions, but KDE makes this easy to deal with. I know some apps have some issues, but the biggest one that I had is that Steam Flatpak still requires Steam-Devices to be installed as a package, but that’s more to do with the way Steam Input works.
The only issue that I have is that uninstalling Flatpaks should present an option to delete the app data.
And does uninstalling a flatpak app also uninstall flatpak dependencies that came with it?
from what I have seen, NO it does not do so automatically. there is a flatpak command option to clean out unused runtimes, and another to remove user data.
delete app data after uninstalling?
you either manually delete the data, or there’s some flatpak command option, or you can use a tool such as warehouse which is available as a flatpak.
Image transcription. Pasted from source, Reddit Post
Despite having just 5.8% sales, over 38% of bug reports come from the Linux community
Article
38% of my bug reports come from the Linux community My game - ΔV: Rings of Saturn (shameless plug) - is out in Early Access for two years now, and as you can expect, there are bugs. But I did find that a disproportionally big amount of these bugs was reported by players using Linux to play. I started to investigate, and my findings did surprise me.
Let’s talk numbers. Percentages are easy to talk about, but when I read just them, I always wonder - what is the sample size? Is it small enough for the percentage to be just noise? As of today, I sold a little over 12,000 units of ΔV in total. 700 of these units were bought by Linux players. That’s 5.8%. I got 1040 bug reports in total, out of which roughly 400 are made by Linux players. That’s one report per 11.5 users on average, and one report per 1.75 Linux players. That’s right, an average Linux player will get you 650% more bug reports.
A lot of extra work for just 5.8% of extra units, right?
Wrong. Bugs exist whenever you know about them, or not. Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone - the thing is, the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. Just like having your own 700-person strong QA team. That was not 38% extra work for me, that was just free QA!
But that’s not all. The report quality is stellar. I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed.
And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.
Worth it? Oh, yes - at least for me. Not for the extra sales - although it’s nice. It’s worth it to get the massive feedback boost and free, hundred-people strong QA team on your side. An invaluable asset for an independent game studio.
The only thing keeping me on X11 at this point is Slack screen share feature. It doesn’t work on Wayland to share the entire screen (specific apps do) and it is entirely Slacks fault here.
X11 also has slightly higher FPS for gaming but not much.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.