app-chooser: Relax app-id requirement for choices

[agx]

This is a follow up from a discussion in the matrix room coming from ashdp requiring an actual app-id where as other current portal backends don't:

Many system apps still use a desktop file name that isn't an app-id as they don't contain a dot. Popular examples are firefox, emacs and vim.

Thus relax the app-id requirement allowing for the base name of the desktop file.

/cc @bilelmoussaoui @arun-mani-j

[GeorgesStavracas]

I don't think this is desired, sorry. Instead of relaxing a well known, easy to conform requirement, these apps should provide a properly named desktop file.

[arun-mani-j]

@GeorgesStavracas we are not trying to lower the requirement, we are just clarifying the meaning, so that future backend implementation authors don't end up in the same confusion loop.

The changes made explicitly says that it is for legacy apps. Newly made apps and apps already following the standard are in no way affected too.

If you think we can reword it better so that it is clear, we can use those words instead :)

[arun-mani-j]

If you think that backend implementations should reject invalid app IDs, then XDP should be changed to validate the IDs before sending to the backend implementations, but that's going to be a break change.

Or the spec must be reworded to say that it is up to the backend implementation to decide if they want to accept the request of invalid app IDs or not. But that will unofficially move everyone to supporting as the major portal implementations - GNOME and KDE do support them.

Also, we are talking about the app IDs sent by XDP in AppChooser interface.
So the invalid app ID does not come from the backend or XDP or the original requesting app, but just because user has a random app in their system that has an invalid app ID and it registers itself to handle a file type.

Either way, the ultimate goal is the spec must clearly express something instead of leaving it in ambiguity :)

[agx]

@GeorgesStavracas The change documents the current practice the portal implementations follow. The alternative would be to have open-uri reject all non valid app-ids in the first place to have the result not being dependent on the backend implementation. Currently e.g. the gtk and gnome portals happily list vim/emacs for their given mime types although the desktop file is vim.desktop.

[bilelmoussaoui]

I am not so sure we really want this even if xdp internally sends you actual desktop file name and not an app-id here and in various other places as fallbacks (for host apps?).

So is this requirement specific to flatpak apps? how does snap behave in this case for portals other than the AppChooser? before committing to clarify this, we should investigate what is the most correct way forward and either fix those apps to use a RDNN desktop file name, fix xdp & the docs or fix ashpd.

[agx]

Can you elaborate what "various other places" you mean? I did look around for similar places but this backend is the only one I could find where the portal would send the ids of other apps to the backend so this particular solution would be for just this case.

[bilelmoussaoui]

Can you elaborate what "various other places" you mean? I did look around for similar places but this backend is the only one I could find where the portal would send the ids of other apps to the backend so this particular solution would be for just this case.

Not exposed to the frontends but they are used in places like https://github.com/flatpak/xdg-desktop-portal/blob/main/src/wallpaper.c#L191-L208

[bilelmoussaoui]

If we decide what is passed here is the actual destkop files basenames, the param names should be renamed.