DIscover with Flatpak back end installed.

[Bings]

Saw the following blog post last night https://pointieststick.wordpress.com...t-in-discover/

This Flatpak back end isn't installed in Kubuntu by default, so I installed it as per the article and it works fine. Having this installed by default would be a great help to less technically minded users.

Short post because can't really be more descriptive about the process than the blog

[acheron]

Yes, pondering what backends to ship by default. Will likely make a decision on that once Plasma 5.12 lands and gets some testing.

[GreyGeek]

That link is the clearest description of FlatPac I’ve read.
That said, FlatPacs appear to add complexity. It duplicates apt, it adds special repositories and a higher level of confusion.
And, IIRC, the standard repository used to offer versions: prev, cur and next release.

By comparison, AppImage is a model of simplicity that allows the user to run multiple version of an app without touching his system or libraries at all. No installation necessary, deletion is simply deleting the image.
Why the drive to complexity?

[Bings]

Maybe AppImages are not something that can integrate well into a Software Centre? I don't know whether it is possible to partially update an AppImage but as of now, if you want a new version of a AppImage you have to download the whole thing, which is kind of an annoyance if there has only been a minor update to it. At least with a repository system, you only update what's been updated. I get on with both AppImages and Flatpak. Flatpak in a software centre like Discover just wins over in the easiest of user experience because it's a one click install over changing the file permission to execute the file. Also, I found Appimage if it puts entries in the Application Menu, you have to remove them manually after deletion.

[GreyGeek]

Personally, I wouldn't want AppImages in the repository.
My wish is that the repository housed only the OS and DE and their related apps. Extraneous applications would be AppImages created by those who wrote the apps. I currently have a dozen AppImages in my home account. There is an AppImage which automatically updates new versions of AppImages but I wouldn't want to use it. My preference would be to install the new AppImage and check it out to see if it works without problems before I delete the old AppImage.

Since and AppImage is a self-contained application it doesn't depend on dynamic (or static) libraries pre-existing on the system, so an AppImage will generally run on any version of Linux.
https://appimage.org/

Linux apps that run anywhere

"As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application."

"As an application author, I want to provide packages for Linux desktop systems, without the need to get it \'into\' a distribution and without having to build for gazillions of different distributions."

That makes sense to me. App developers make just ONE version of their app - an AppImage version. How many times in the past have you installed (especially on an RPM system) an app only to find out that it doesn't work with the version of the dynamic libraries on your system. Kubuntu/Neon developers wouldn't have to futz with getting an application to work with the version of their DE that they are working on. App developers wouldn't have to compile for Debian, Ubuntu, Fedora and openSUSE, etc., leaving out many distros not based on those distros. They could package their app as an AppImage and not worry about the 300+ distros out there. Ubuntu/Kubuntu/Neon users wouldn't have to wait until they found a bug fix or new release in a LaunchPad's PPA, and then bloat out their sources list.

KISS'n it is so obvious I amazes me that folks are attempting to install a Rude Goldberg software installation device.

[dequire]

Well, for whatever the reason, so far Discover has backends for Snaps and Flatpaks. Appimages appears to not be on the radar. There's honestly pros and cons to all of the different options. Here is a pretty good discussion...several pages worth for those interested. Personally, I think Discover should ship with and enable any repo it can support and present a seamless experience for the user, which is what I understand from the original blog post is the case. The trivial nuances between all the different app source options that we go on about are relatively meaningless to the normal user who just wants to install that kool looking Telegram chat client she's staring at in the Discover software center, after all.

[GreyGeek]

Currently, the repository contains over 80K applications. I don't know how many of them have fancy graphic icons to go along, or how many bytes those icons are, but as Discover is currently designed, it is painfully slow. Are ALL the available icons stored locally during the first run and only new ones downloaded and save subsequently? Or, does Discover download all icons as the pages in Discover display? What ever way they are doing it it is, IMO, too slow, and currently too buggy.

Muon and Synaptic allows one to select multiple packages to add or remove and then does them all in one batch. Discover appears to create a thread for each package added or removed and in playing with it, as I clicked to install another package while previously selected packages were downloading and installing in the background the whole process slowed to a crawl. In speed, Muon or Synaptic blows the socks off of Discover.

[dequire]

Currently, the repository contains over 80K applications. I don't know how many of them have fancy graphic icons to go along, or how many bytes those icons are, but as Discover is currently designed, it is painfully slow. Are ALL the available icons stored locally during the first run and only new ones downloaded and save subsequently? Or, does Discover download all icons as the pages in Discover display? What ever way they are doing it it is, IMO, too slow, and currently too buggy.

Muon and Synaptic allows one to select multiple packages to add or remove and then does them all in one batch. Discover appears to create a thread for each package added or removed and in playing with it, as I clicked to install another package while previously selected packages were downloading and installing in the background the whole process slowed to a crawl. In speed, Muon or Synaptic blows the socks off of Discover.

Maybe, but I think the "intent" is not to use Discover and "packages" in the same sentence. Muon is for packages, Discover is for apps. And somewhere in there is a design and user-case difference, blurred as it might be to us old-timers.

[jpenguin]

There are a lot of apps for flatpack, and I do prefer it to snaps. I do like the simplicity of appimages; just download it from the developers site.