GNOME can't diferentiate GIMP stable and beta

[fabriciojardim]

STEPS TO REPRODUCE

1. Install GIMP stable from flatpak
2. Install GIMP beta from flatpak
3. Press overview key and search for GIMP

WHAT YOU EXPECT

• Search results should show the 2 versions of GIMP, preferably with some badging identifying the beta icon.
• It should be possible to have both versions of GIMP open side by side.

WHAT HAPPENS

• Search results only shows GIMP beta.
• You can find your stable GIMP if you use the applications dash but you can't have both open at the same time.

I'm not able to do it myself but I think this can be fixed in the flatpak manifest.

Thanks!

[Jehan]

Yes this is a limitation of the Linux desktop standards hence of flatpak. Basically the specs don't have concept of multiple version of a single application.
See flatpak/flatpak#1109

The solution so far is to switch the visible branch with one of the following command (depending on whether you want to show stable or beta):

flatpak make-current --user org.gimp.GIMP stable
flatpak make-current --user org.gimp.GIMP beta

You can also run any of the versions from command line even if not the current branch with:

flatpak run org.gimp.GIMP//stable
flatpak run org.gimp.GIMP//beta

There is a workaround to this issue, which is that we can give to the development version a different ID. Basically the idea is to pretend this is another software altogether. This is ugly and I don't like this, but this is currently the only solution. I will probably do this in a few days.

[Jehan]

@alexlarsson Hi! In the end, I'm just trying to follow the "rename the app-id for the beta release" recommendation. I think I did it all properly, with the rename-* options as well. Builds work fine.

But then the build fails at "Check for AppStream xml" step with this error:

stat: cannot stat 'builddir/*/share/app-info/xmls/org.gimp.GIMP.xml.gz': No such file or directory

Why does it look for a xml.gz file with the old ID. Does it pull this ID from the repository name (which I can not change obviously)?

When I look at the build log, in the last lines, I clearly see:

Processing application org.gimp.GIMP.dev
Saving icon /app/share/app-info/icons/flatpak/64x64/org.gimp.GIMP.dev.png
Saving icon /app/share/app-info/icons/flatpak/128x128/org.gimp.GIMP.dev.png
Saving AppStream /app/share/app-info/xmls/org.gimp.GIMP.dev.xml.gz
Done!

So the file is appropriately named org.gimp.GIMP.dev.xml.gz which is what we want as I renamed the app-id to org.gimp.GIMP.dev for the beta. Only the fact it looks for the stable app-id is problematic. Is it a bug in flathub scripts or am I missing anything?

I thought to have understood that other applications were already applying such trick. If they did, then there must be something I do wrong, no?

[fabriciojardim]

Yes this is a limitation of the Linux desktop standards hence of flatpak. Basically the specs don't have concept of multiple version of a single application.
See flatpak/flatpak#1109

The solution so far is to switch the visible branch with one of the following command (depending on whether you want to show stable or beta):

Thanks for this explanation and the workaround. I didn't know the Flatpak beta feature had this limitation.

[hfiguiere]

If you add "desktop-file-name-prefix": "(beta) ", in the manifest (top-level) it will prefix the desktop file name with "(Beta) " which allow seeing it's the beta branch.

[Jehan]

If you add "desktop-file-name-prefix": "(beta) ", in the manifest (top-level) it will prefix the desktop file name with "(Beta) " which allow seeing it's the beta branch.

We already do this, but it's not the problem here. I will also answer your comment on #92.

[hfiguiere]

Sorry I missed it when I checked....

[Jehan]

No prob. 🙂

[Twig6943]

This should be closed.

See: https://www.youtube.com/watch?v=ZM_CqPmI7cQ 15:04-15:15

[Jehan]

@Twig6943 Could you summarize what we are supposed to understand/discover with this video? I don't really want to click a Youtube link.

Also the Flathub report is still opened: flathub/flathub#1138

If that were solved or if they decided that it should not happen, the report would likely have been closed. So I'm curious as to why you think we should close the report on our end.

[brunvonlope]

I watched that specific part of the video. I think @Twig6943 got confused with the new Nightly AppId.

[Jehan]

Oh I see. Well @Twig6943, we have 3 flatpak-s: the "stable" one on Flathub, the "beta" one (also on Flathub) where we push development releases and the "nightly" one (on GNOME's nightly repo) which are random points in time in development code. Only the nightly flatpak has its own App-ID, since we can control the App-ID there.

We don't control App-ID on Flathub, so we need to wait for Flathub to add some special code for allowing this.

[hfiguiere]

We don't control App-ID on Flathub, so we need to wait for Flathub to add some special code for allowing this.

Don't hold your breath on that one.

[Jehan]

Don't hold your breath on that one.

What I was reading in the related report seemed pretty positive to me. Now I understand that it's very likely not high priority (which is fine) but Flathub contributors didn't seem particularly against the idea. The last comment even suggested a possible solution to automatize. 🤔

In any case, we are fine with waiting. Everyone does what they can when they can. And it's very fine with us. 🤗