A downside to providing flatpak specific features would be a lack of feature consistency between this and other package types and KDE Store items. Unless you are looking at a flatpak-only, or KDE Linux only tool here?
Your concerns are valid. There’s always a downside, but take a look at what we’ve got.
Ideally, in the very long term, we want to support only Flatpak and Snap (if they continue to exist, lol) ok?
We are going to provide a Flatpak-first distribution without a proper GUI application to manage and view details of those apps (the missing features described before)
So, the solution is to create a ‘Discover’ Flatpak-only app, what happened to Gnome Software and Bazaar? Probably not, but we should start somewhere.
Personally, I don’t care about the cohesive side of this. I know that native packages have poor details instead of the Flatpak ones, and ideally, as I said, the long-term goal is to get rid of the native packages (at least in GUI apps, as we know them).
Firstly, we need to make sure KDE itself, its developers and Linux/open source in general reach a good sustainability level. Emphasising donations to app developers would be a great improvement ( the donate button), in my humble opinion.
So, create or modify one for that sort of system, perhaps, instead of turning an app store into a package manager?
I actually like and prefer the simpler app store aspect of Discover, myself, but it would be very nice to have a KDE based flatpak manager with those extras.
The visual notification that the app is installed would need to include icons to indicate which versions are installed.
For example, in the case of Firefox, it has a native version, a Flatpak version, and a Snap version.
Just notifying that the app is installed isn’t enough. If all three versions were installed, it would need three icons: one representing the distro, one representing Flatpak, and one representing Snap.
Possibly, but it depends on how discover manages flatpaks – is it using packagekit? If so, then the data and stats shown probably needs to come from that, else it needs to be baked into the UI alongside the packagekit stuff, plus all the extra tools for functionality. Possibly a bit cumbersome.
But KDE is in many more places than KDE Linux
Should this topic have a “KDE Linux” tag?
On the flipside, integrating a permissions configuration would be useful and handy, instead of that one we had in System Settings, which feels like an odd place for it to be in some ways.
The PackageKit backend is used for handling traditional distribution packages and uses the system’s package manager.
Flatpaks and Flatpak repositories are handled by another backend, Snaps by a third one.
Without looking at the code I would guess that backends already have ways to communicate capabilities to the UI and provide different features depending on what the underlying system can go, e.g. ratings, reviews
I was not sure as there isn’t anything related to snap or flatpak in the backend list, but of course I have no idea if it is just somewhere else in there.
(version history, download stats and maps ecc ecc)
