I usually try to stay out of the whole snap vs flatpak discussion. Although I am just really confused as to why flatpak just does not seem to care about usability. You’re trying to create a universal packaging format I would think the point of it is that a user can just install an app and after reviewing permissions it should “just work”.
There are so many issues that yes, have simple solutions, but why are these issues here in the first place.
These are the issues that I have encountered that annoy me:
- Themes, cursors being inconsistent (needs to be fixed manually with flatpak --user override
- IDE’s are unusable without extensions
At least snap provides an option --classic to make the app work. Please explain to me why flatpak just evidently refuses to take this same approach.
It is really quite simple.
Flatpaks (and Snaps, and Appimages and Docker containers for that matter) are essentially designed for app developers who grew tired of distro maintainers demands to fix certain things about their build systems and their applications that broke when their apps were used on distros other than the exact distro and version the developer was using. They are designed to take a “kill the messenger” approach to the problem and now people are wondering why the work that the distro maintainers did before doesn’t get done any more.
The default permissions for each app are up to the package maintainer. If something seems odd about a package, complain there.
Unfortunately this means that sometimes the project maintainers get complaints and not the package maintainer. Two projects I’m involved with don’t officially support Flatpak. With one of them we do want to support it eventually but things just aren’t there are and we have far bigger fish to fry.
The problem is that some well meaning people have created flatpaks and published them to flathub which means every single time something breaks or doesn’t work correctly they come to the actual project to complain about something we didn’t even do.I think it would be good if they expanded the permissions system. Taking inspiration from the android world where it will ask for the permission whenever it needs to access something on the system. This is an ideal world but would take a lot of effort for the maintainers to implement. I guess it needs time to mature. I just hope flatpak devs want to adress the issue eventually… So far I only ever see people just accepting the way it is now and finding workarounds…
Android has the benefit of being greenfield and has an API that everything needs to go through to access the system. Flatpacks and snaps do not have this. They need to work with applications that were never designed to be sandboxed and just expect to have access to everything all the time so is a much harder problem to solve.
No reason why Flatpak can’t create such an API though so that new applications can use it, older applications can eventually switch to, etc. We’re already seeing adoption of things like xdg-desktop-portal so it isn’t that out of the question.
Yes, but this takes time and still has to work with applications that dont support it. Where Anrdoid can just force everyone that wants to create an app to use their API. So it is harder for flatpack to encourage everyone to adpot it.
Themes, cursors being inconsistent (needs to be fixed manually with flatpak --user override
I haven’t had this issue in about 6 months.
IDE’s are unusable without extensions
Yeah, IDE integration is kinda bad. Use containers instead.
Next problem please?
Some apps automatically pick up your theme some don’t. For these I give the specific app access to my theme folder with a :ro at the end of the path.
IDEs should work ootb. If some extension doesn’t work, maybe it’s because of poor support for Flatpak. 9/10 times you’ll find the issue is that app is calling the traditional /usr/bin path etc. when Flatpak installations use different paths.
Well I hate to disagree with all the doomers here, but I don’t think flatpaks are the devil. Flatpaks are as good as the person shipping them, there are not many flatpaks that actually have official dev support so a lot of these programs are packaged by volunteers in their spare time. So no, they may not have the best default settings.
That said, I run flatpaks almost exclusively on Kinoite I’ve never had an issue with flatpak theming or my cursor changing. Some applications are very obviously made for GNOME or KDE explicitly but flatpak doesn’t have anything to do with that. Of course if you are running a WM rice or something with very specific theming then that’s another story. You can customize a Linux desktop in countless ways, you can’t really expect these applications to keep up with that by default (flatpak or not). It’s the same concept as something like Discord or Steam, it will look the same for everybody but you can theme it if you put some effort in.
IDEs are another issue, the whole concept of an IDE is antithetical to a sandbox in the first place so it’s simply not a very good use case of flatpak. Flatpak isn’t a one-size-fits-all solution, that’s why even the Fedora immutable desktops give you additional options like rpm-ostree, podman, buildah and toolbox.
The problem occurred on Brave browser using standard KDE.
Anyway this explains it nicely. I guess flatpak itself is ok but a lot of things are in the hands of package maintainers and if they don’t set things up correctly then there will be issues. Makes sense
It’s pretty simple: RedHat/Gnome developers don’t believe in theming and that you should stick with the default theme and suck it up.
They even made a whole website about it: https://stopthemingmy.app/
@Max_P @ErnieBernie10 This is one of several reasons why I don’t use gnome