We treat installed desktop files *as* applications. Is the ebook reader a separate app or not? At the moment it seems it's in a kinda quasi-independent app, itself not sure if it's part of a bigger app or not.

Calibre is an application *suite*. The main application most people think of would be the ebook collection manager. Other included applications are readers and editors for a couple ebook formats. They all rely on core Calibre libraries, though. You could possibly *try* to yank everything apart to force each executable to reside in a separate package (like calibre-libs, calibre-ebook-reader...), *but* that's not how it is normally done. Even in Fedora, which I gather is relatively strict about separating all packages wherever possible, the entire Calibre application suite is installed as a single calibre package. This makes Calibre different from other application suites like LibreOffice; in Fedora, LibreOffice is split into multiple packages, separating the word processor from the spreadsheets application... However, Calibre seems to be internally more tightly integrated? Using a regular package manager, it's impossible to install or remove any Calibre component without doing the entire suite.

And Calibre isn't the only thing like this. Git Cola is a GUI front-end to git. It's also an application suite, though this time it only provides two binaries, each with their own .desktop file: Git Cola, which lets you stage and commit changes to the working file tree, and Git DAG, which lets you view and search the commit history. However, the git-cola and git-dag applications/executables are both provided by the single git-cola package (at least in Fedora).

There are also examples where you can wind up with multiple .desktop files even when there is unambiguously only one application: Let's say a user often uses Firefox in "private" mode. In Fedora, the Firefox .desktop file includes Actions that let you can right-click on the Firefox icon and choose "Open a new private window." However, the user uses private mode so much that they decide it's a little tedious and decides to create an extra .desktop file in ~/.local/share/applications/ where private mode is the default action. (The user changes the .desktop Name tag to "Firefox Private Window" and adds `-private` to the Exec tag.) In this scenario, GNOME Software treats the new Firefox Private Window as a completely separate application. But it's just a .desktop file using the *same* executable as regular Firefox, it's just using a different command line option. You can't install or remove Firefox Private Window separately from regular Firefox because they are literally the *same application*.

Firefox users who are testing and/or developing browser settings or addons might also create alternate .desktop files that use different Firefox profiles (with the `-P` command line switch).

Similarly, Phatch, the batch photo processor, out-of-the-box includes separate .desktop files for the batch image editor and its included image inspector. These two .desktop files use different command line options and different icons, but it's a single binary from a single package. So you couldn't install or remove the batch image processor without the inspector, or vice versa. Yet Phatch gets listed twice in GNOME Software.


...I'm sure there are many other examples. But do you see the problem now? GNOME Software listing entries based on .desktop files is problematic. It seems to me that available and installed software should be listed based on *packages*, since that is how the applications will actually be installed on the system.

(In reply to terrycloth from comment #2)
> Calibre is an application *suite*. 

It is? It looks like one application to me, with one extra helper program.

> ...I'm sure there are many other examples. But do you see the problem now?

I saw the problem before, but I don't see any good solutions to it.

> GNOME Software listing entries based on .desktop files is problematic. It
> seems to me that available and installed software should be listed based on
> *packages*, since that is how the applications will actually be installed on
> the system.

A package centric view just isn't going to happen, sorry. Packages are just an implementation of how the application is deployed, and they can also be deployed using flatpak or snappy, or numerous other ways. Displaying a list of packages is what gnome-packagekit did, and you're free to use that if you'd rather.

In a more constructive tone, we could perhaps require an installed AppData file for applications to appear in gnome-software as installed, although that's going to upset other people that install a proprietary or old application manually and then can't find it in the installed list.

Here's a thought: 

Could we extend the 'add ons' to have another type called 'alternate interfaces' or something and use that for these cases? when you install the base / real application all the alternate interfaces also show as installed and you could search based on them, etc. If you installed one of them it would install the base app. It would need to know what to execute for them however. 

I agree based on packages won't help. (At least it would not in the calibre case), it needs to be some way to see and search for all the 'faces' of an application and make sure they are all tied together so when you install one you have them all (just with different icons/binary name/command line args).

(In reply to Richard Hughes from comment #3)

>> Calibre is an application *suite*. 
> It is? It looks like one application to me, with one extra helper program.

The Calibre package actually includes 4 .desktop files. Also, is "application suite" versus "main application with helper applications" a useful distinction? I've seen plenty of things being called an app suite but this and one other Bugzilla thread are the first time I've ever seen anything called a "helper application." 


> A package centric view just isn't going to happen, sorry.

I'm confused. I don't know how you could possibly *avoid* working with packages in a package-centric distro. Correct me if I'm wrong. I know that GNOME Software doesn't use dnf or apt, but I believe both GNOME Software and PackageKit do still fetch software from the repositories of the distro on which they are installed. So what's being downloaded, updated, installed, or removed is inevitably still going to be a *package*. Right?

The design of gnome-software is built around applications and things people actually want to use and run. Packages are built around each upstream project. If someone wanted to use calibre they wouldn't care that they have to install say python-BeautifulSoup or even care what that is. So, all the libraries and supporting packages are not shown, only installed in the background as a means to have applications work. 

I agree the current situation isn't ideal, but exposing packages is definitely not the way to go. 

We need some way for applications that have multiple desktop files to be all tied together and shown as the one application they really are.

Okay, I think I understand the rationale behind listing applications by .desktop entry now. In fact, Kevin, since I actually opened this bug report based on our conversation about Calibre on the Red Hat Bugzilla, maybe we should be more explicit about what the real problem actually is -- or decide whether we're going to keep this thread open.

I was confused at first to see you agreeing with me that there is a problem here, but disagreeing about what the problem is. So the other day, I experimented with adding and removing .desktop-based application entries, and it occurred to me that GNOME Software treats the other members of an application suite sort of like dependencies.

Maybe the real problem here is that there's no way to see that the different Calibre sub-applications are related (and mutually dependent). So a user who installs Calibre, the well-known ebook manager, might be confused to later discover the lesser-known small bundled ebook editor. But if that user tries to remove the ebook editor, they will remove the rest of Calibre too. There's no warning. GNOME Software can handwave away the Python libraries, but perhaps it should still show you that it's about to add or remove the related GUI applications.

Also, users who create custom .desktop files for normally installed applications (like my Firefox example), or who download static binaries which create their own .desktop entry (like the official desktop client at telegram.org), will not actually be able to install or remove those applications/entries from GNOME Software.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-software/issues/130.