Single source of truth for app publishing

[bertob]

I've been thinking about how to improve the developer experience for publishing new apps, and one of the things that came up is the disconnect between appstream and desktop files. While appstream has most of the data needed for app store listings, there are some properties that are duplicated in the desktop file (e.g. name, summary, binary), and some that exist only in the desktop file (e.g. app icon, categories).

From a new developer point of view this is quite confusing, and it means there isn't a single place where you can set up everything that determines the appearance of the app in app stores.

A potential solution could be to add the few missing things to appstream, and then generate the desktop file on build using that information (at least by default in our project templates in GNOME Builder). App icon and categories are the most prominent things missing in appstream at the moment, so maybe a good first step could be adding those?

Edit: What I'd like to work towards is a single UI with live preview for how an app will appear in app stores (mockup).

[JakobDev]

These are 2 different use cases: The .desktop file is used for the Applauncher of your Desktop, It has nothing to do with the Data shown in the AppCenters. The Appstream file is for the AppCenters. This are totally different use cases.

[bertob]

Sure, but as pointed out above we use app icon and categories in app stores, so clearly they are not that separate...

[JakobDev]

But on the other Hand, Applaunchers don't need thinks like a full Description or Screenshots. A App can also have multiple .desktop files but a single Appstream file.

[bertob]

I'm not saying that desktop files need to go away, just that we should add missing things to appstream and make it possible to generate desktop files as part of the build process for apps where it makes sense (i.e. where there's a single desktop file and most of its contents are already in the appstream file).

[ximion]

Checkout appstreamcli make-desktop-file - it will generate a desktop-entry file from a MetaInfo file, provided the latter has:

• Categories set
• A name/summary
• A <icon type="stock"/> set
• A binary set in a provides block (could nowadays maybe even be a new launchable type, but this code is old...)

This command can either generate a completely new desktop-entry file, or augment a stub-desktop-entry file that contains stuff that AppStream doesn't support, like context menu actions.
This will likely cover 99% of all cases, and is one of the commands that I want to add to a new Freedesktop Meson module that I have some preliminary code for, to make all of this easier for developers ;-)

[bertob]

Something that came up recently in the context of building an appstream previewer app: Setting the icon via icon name means we can't find the file from disk, it'll use whatever is installed system-wide (or nothing if it's not installed).

For previewing we need the actual local file from specific path in the app repo, so it'd be good to have that defined in the appdata file instead of just an icon name.

When going through the build step, the appdata file can replace the local path with the installed path.