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.
Of course, it will definitely take time to transition over, but that’s the case for all APIs in the PC ecosystem. I am a firm believer of “if you build it people will come” and I am sure a well integrated Flatpak permissions system with good UX is a convincing argument for a lot of apps to switch over.
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
I honestly wish more programs did the app by app theming thing like steam and discord. I don’t need my desktop theme applied to every program I open. I would much rather the program to have a consistent design language that works, rather than slapping themed buttons all over the place that don’t fit with other aspects of the program.
That theme situation is a bit odd, there should be better documentation about that.
You can help improve the desktop integration documentation at their GitHub repo.
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?
The very concept of them is that they bring along basically everything but the kernel - all their library dependencies, all their config, everything. So they’re ‘reliable’ and ‘easy to start’, but also bloated, slow to start, resource hungry, don’t depend on system libraries that can be updated independently, and as you see, look like crap. Working as intended, nothing to see here.
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/
That’s the thing. The default theme didn’t work. The cursor was like an old looking cursor. Not the default
- That site isn’t RedHat/GNOME. From the bottom of the letter:
Note: Even though some of us are Foundation members or work on GNOME, these are our personal views as individuals, and not those of the GNOME Project, the GNOME Foundation, or our employers.
- They aren’t against user theming. Again, from the site:
If you like to tinker with your own system, that’s fine with us. However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.
They’re against distributions shipping custom stylesheets by default. Which makes sense! If a user has a stock installation, and an app looks broken, they aren’t going to assume the distribution messed it up. They might not even know that the distribution changed the theme. It can also cause confusion for users when their app doesn’t look like the screenshots from the developer. These cause issues for app developers.
That’s it. That’s all the letter is saying. It’s not a crusade against you theming, it’s asking for theming not to be done by distributions.
(P.S. I don’t intend for this to be aggressive. Just wanted to explain a bit more, because the name does sound… not great.)
Agreed, they look like ducks, walk like ducks, quack like ducks and smell like ducks BUT THEY ARE NOT DUCKS
@Max_P @ErnieBernie10 This is one of several reasons why I don’t use gnome
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.
It is curious cause I also had a very bad experience with flatpaks, a lot programs just won’t work and the terminal integration… is just bad, really bad.
I think the container idea is not for everything and ppl should stop pretending that is marvelous. It actually work for most apps after a big improvement in usability but not for everything.
I can’t stand any of the new packages except appimage, flats & and snaps just cop outs
Appimages are nice. I just would like there to be some hub for them which also enables the appimages to be updated through it. I know about zap for example but it’s not up to par with flathub or the snap store.
because they dont exist to make it esier for users.
Tl;dr it’s likely that some of your hardware isn’t well supported in Linux or have vendors downright hostile to open source (fuck you, Broadcom and Nvidia) and causes you weird issues that almost always get fixed by the community but may not always work “out of the box”
I’ve been in Linux since 2008 and have asked this question in many ways over the years. To get a real answer I’d dig more into the errors you’re encountering. I think that a lot of the “simple fixes” you mention are simply options that some hardware configurations need and some don’t.
Flatpak and Linux in general deal with the same huge task as Windows, which is “support any hardware configuration with one universal solution”. While Windows is given every advantages by cooperative hardware vendors releasing official drivers, Linux is mostly supported by open source reverse engineered drivers.
This means that no “universal” system is likely to work all the time in every case, but that’s ok because it’s all open source and the community finds a way.
You mentioned themes and some graphical packages, do you have an Nvidia GPU? I never had anything but trouble on Linux with them.
It has nothing to do with my hardware. Like I said fixing the theme was done with a simple command that basically mapped my user .icons folder to the flatpak one. My point is just that why isn’t this done automatically. Why isn’t there a system in place that will deal with this.
If it bothers you that much, write one. 85% of Linux was constructed by frustrated nerds deciding to write their own solution to a problem they found. There is no parent company to complain to, just fix it yourself and distribute the solution. Else, you’ll need to wait for someone else to do exactly that.
True. I would if I knew C. Maybe it will be a reason for me to learn it.
If feels like there is a system in place that will deal with this if it can be resolved by a simple command. Am I missing something?
Why is the command necessary and why did I have to Google it. It feels like it should be default behavior.
I can’t say with any specifics but flatpaks are sandboxed on purpose, when you override something you’re giving it more (or less) permissions than the developer thought they’d need. “Automatically giving permissions the developer didn’t think they’d need” seems like a crazy thing to try to automate, no?
Check out Flatseal if you haven’t already. It’s a GUI for flatpak permissions. Might make your life easier in the future.
Yeah I understand the reason why it is the way it is. I think it should be simplified. Just a pop-up box asking the user if it’s ok if flatpak gains Access to path x. That’s what I have in my mind. Maybe with time it will improve.
How do you propose that they trigger that popup? How would flatpak or the application know to ask if you wanted to add those extra permissions?
I don’t know. It’s only an idea.
It’s Linux, dude. If everything worked then everyone would use it. Can’t have that .
We should at least aim for it…
