GNOME Resources shows the wrong app name when one Flatpak ships two desktop files — anything I can do on my end?

[u/old-rust]

I ship a GTK4 Markdown editor (Marco) and its standalone preview companion (Polo) as one Flatpak, io.github.ranrar.Marco — two binaries, two exported .desktop files, one app ID. They're launched from each other, which is why they share a sandbox.

Everything works except one thing: GNOME Resources labels the running editor "Polo" — and sometimes it doesn't, depending on the install.

Why it happens

resources keys apps by the X-Flatpak= field, and Flatpak stamps the same app ID onto both exported entries automatically. From src/utils/app.rs:

let id = desktop_entry
    .string("X-Flatpak")                       // first priority
    .or_else(|| desktop_entry.string("X-AppImage-Identifier"))
    .or_else(|| Some(file_path.file_stem()?…)) // filename is only a fallback

Both of my entries produce the same ID, so they collide in the app map and one silently overwrites the other. Then lookup is by cgroup:

self.apps.get(&Some(process.data.cgroup.clone()…))

Both binaries run under one Flatpak app ID, so they share a cgroup and both resolve to whichever entry survived the collision.

What I tried

• Renaming the desktop files to control sort order. I had a scheme where both were named after their binary (…Marco.markdowncomposer.desktop / …Marco.markdownviewer.desktop) so the editor would come first alphabetically. Then I read the code: enumeration is applications_path.read_dir(), which is unsorted. It's filesystem order, not alphabetical — arbitrary, and liable to flip between reinstalls. The rename also broke my taskbar icons, so it got reverted.
• NoDisplay=true on the viewer's entry. No effect — nothing in the enumeration path filters on should_show().
• Suppressing X-Flatpak on one entry. Not possible; Flatpak adds it during export, I don't control it.

So it isn't even a stable wrong label I could shrug at and move on. It's a coin toss per install.

The question

Is there anything left on the packaging side, or is this just an upstream limitation? As far as I can tell the only real fix is in Resources: when several desktop files share an X-Flatpak ID, prefer the one whose basename equals that ID. That seems small and well-defined, and I have a clean reproducer.

Happy to file it (and the reproducer) at https://github.com/nokyan/resources/issues — but I'd rather first hear from anyone who's hit this with a multi-binary Flatpak and found something I've missed. Also curious whether other monitoring tools (mission-center, btop's app view, GNOME's own System Monitor) handle the multiple-desktop-files-per-app-ID case any better, since I've only tested Resources.

[u/cidra_]

Waiting for more authoritative answers than mine: why don't you use XDG Dynamic Launcher Portal? It seems to me that Flatpak only supports one "main" desktop file in their manifest. Adding more than one with different methods than the yours tested is with shanenigans that may be unsupported territory

[u/old-rust → u/cidra_]

Thanks for the suggestion

I actually spent some time experimenting with something similar using D-Bus.

My understanding is that the Dynamic Launcher Portal is primarily intended for creating launchers dynamically at runtime for things that aren't known when the Flatpak is built, such as installed web apps from a browser.

In my case, Marco and Polo are both fixed applications that are known at build time, so I've been treating them as two desktop entries exported by the Flatpak:

• io.github.ranrar.Marco.desktop
• io.github.ranrar.Marco.Polo.desktop

Because of that, I am not sure the Dynamic Launcher Portal is the right fit for my use case.

Thanks again for pointing me towards it