When it comes to #Linux and packages for the user, #Flatpak for when you need shared dependencies and #AppImage for when you need a portable app. Basically we've already solved both the "app store" and "downloadable executable" problems.
Snaps could compete, if it supported third party repos OOB and wasn't a vendor lock-in situation, but if and buts were candies and nuts...
Flatpaks, Snaps, & AppImages: "Do we really need these Universal App For...
https://youtube.com/watch?v=so_f6OtRWRo
It's clear to me that #flathub is the go-to vendor for Flatpak package distribution and as such, it sort of becomes a vendor lock-in situation... but #Flatpak supports third party repos OOB and #snap doesn't.
Flathub has also been held to the fire and it lead to a change in policy, thanks to the likes of @BrodieOnLinux shining a light on certain issues, like flathub enforcing #gnome like requirements and spiting #QT apps, which has since been changed to be more inclusive.
@hopland @BrodieOnLinux that was never the case, you have been lied to, if you believed that - in fact KDE devs were in it from the start - they just need longer to get stuff updated
@razze @hopland I never said Flathub was enforcing GNOME requirements, what I believe he's mistaking it with is the Flathub app guidelines leaned very heavily towards GNOME design inspirations and GNOME naming conventions which I believe it was stated in the docs that's it's partially based on the GNOME HIG or that may have been a follow up blog post.
@razze @hopland I don't think I've ever mentioned Flathub having an issue with QT apps, that's probably coming from Flathub very heavily promoting libadwaita apps which makes sense as they're more likely to follow guidelines inspired by GNOMEs guidelines which they were likely already trying to follow.
@BrodieOnLinux yeah, i was probably misrepresenting the issue.
I seem to remember that certain Qt app developers didn't publish to Flathub, simply because they didn't meet with the guidelines. Again, that could also be wrong.
Calling it a lie... is a bit extreme. But hey, my feed is apparently a place to through around words.
@hopland There are certainly developers who have chosen to not publish on Flathub due to the app guidelines, they're not strict requirements but they are requirements for being promoted rather than just being in the app listing.
@BrodieOnLinux @hopland to be clear, I did not assume, that you we're the "lying party"
@hopland For as long as you have to open properties and check a checkbox, and then it doesn't automatically get added to your apps list, then it's not solved, I would say. AppImage is good, but something needs to be done to make them usable by everyone, I think.
@forteller #AppImage support is still done on a per-distro basis, and it really isn't much more than setting permission and executing certain environment variables... I think.
But mayhaps this is a job for ... #FREEDESKTOP
Hello. I'm free desktop... gief money,
We craves it, WE NEEDS IT!!
But yeah, maybe xdg-open should handle that problem. Then distros wouldn't need to do anything to get first rate AppImage support by removing those annoyances.
One can only hope.
@hopland Agreed! :D
@forteller holy smeg the #freedeaktop #gitlab server is slow as snails crawling through molasses. Hoo-boy!
@forteller there's apparently a package called "go-appimage"... and it's called that because the old code base is in C++ and the new one is in go... with embedded C++.
I swear.
And ofc this would mean installing another system package, if it's even available on your distro.