| I don't really want to argue with you but I think you're still basing this on false information or on misconceptions, I'll try to clear things up. Of course you are free to use or not use whatever packaging solution you want for whatever reason. >All the apps I use (even the GTK4 ones) adopt my system theme perfectly fine as long as I'm not using Snaps/Flatpaks/containerized distribution. That's great for you, unfortunately this cannot be guaranteed for all combinations of themes and apps. There are "tricks" you can do to get your themes to work in a flatpak such as mounting the theme directory into the container but this would probably be considered an unsupported hack, I wouldn't recommend it. The only way this could ever be supported is if somebody tested your theme with every version of every flatpak app and then filed/fixed bugs everywhere, which is really not a reasonable thing to ask of theme developers so it probably won't ever be supported. >GTK has always had fallback stylesheets for this exact purpose This is not about the fallback style sheet, this problem is specifically about the style sheet used by the app and how it can conflict with the theme. I'm not sure if you're familiar with CSS, but the way it works is that anything from the theme can override things from the fallback style sheet and that could mess things up if the app expects something different to be there. >Flatpak has decided to circumvent them because of the Gnome foundation's wheel-spinning "don't theme our app" movement. There's quite literally nothing stopping the Flatpak devs from referring to your systems default stylesheet for all UI draws. Have you read the "stop theming my app" page all the way to the bottom? Please re-read it if you can, it shows examples of how theming is unreliable and can break apps. That's what would be stopping them. Also this wouldn't really be up to "flatpak devs" to handle either, this would be up to the maintainers of the GNOME SDK and app developers. >That's more work than I have to do on every other version of every package I use How? It's a bug, it's not different from any other bug that you would report. Once it's fixed you don't have to worry about it. >Wait, so now they have two packages to maintain? One being the true binary copy of their application, and the other being a sandboxed version that is apparently more likely to break? No, I've noticed often the flatpak maintainer and your distro maintainer are different people. There isn't any "true binary copy", unless you consider the binaries that are provided by the developer, which you should check which ones those are. They could be flatpak or they could be something else. And actually the sandboxed version should be less likely to break since the dependencies are pinned and there are less moving parts there. >it's really just "another competing standard" a-la XKCD Yes, that's sort of true, you could also use Snaps or AppImage or a similar thing. However these are not the same as distro packages so in that regard they're not "another competing standard". This is a package that you can install on any distro and have a reasonable guarantee that you'll get the exact same version that runs in the exact same environment. >Ah yes, the classic UNIX config directory '~/.var/app/', a directory that never existed until Flatpak came along and decided it was somehow the new standard. Great stuff! I don't understand what you mean here. If you're being sarcastic, please don't do that, it doesn't add anything of value to the conversation. These apps are sandboxed, so you probably want them in a separate directory so they don't clobber your home directory. There is no UNIX config directory for sandboxed apps so they had to come up with something new. What exactly is the problem here? |
THIS is the issue, the issue with almost every paragraph of your comments that I've read.
Your assumption that everyone cares about this is false, there's no "misconceptions" here. The only misconception is the one that GNOME is the center of the Linux universe... which is tacitly untrue. GNOME is an extension of a modular system, one that was also designed to be built upon to create better experiences. GNOME once also shared that sentiment of modularity, and it worked perfectly fine for it: GTK2 and GTK3 both respectively inspired several desktops to exist purely based around their design languages, and worked pretty much flawlessly. If the GNOME team is scaling down their ambition and deciding to be less modular, then fine: let's put the tiger on the table and yell at it. You can publicly say that you're distributing with Flatpak because you're too lazy to debug a native version, I won't take any umbridge. I'll just compile the app myself and use it as normal, no skin off my back.
The ultimate Achilles heel of Flatpak is that it will inexorably always be a second-class package manager. You'll never install it without having another, feature-complete package manager operating alongside it. The UNIX philosophy is to do one thing and do it well: Flatpak tries doing a hundred things, and can't do a single one better than another, dedicated tool. There is no argument here. Flatpak is not, cannot, and will never be considered a real package manager. It's a second-class supplement at best, and abhorrent bloatware when it stops working properly.