Unable to add games on Kubuntu Linux 20.04 LTS

[ssokolow]

Currently (2.2.0), the ScummVM Flatpak invokes the file chooser portal when asked to add a game.

However, Kubuntu Linux 20.04 LTS comes with a version of xdg-desktop-portal-kde that doesn't support directory pickers (it just shows a file picker that doesn't let you pick anything) and the Flatpak PPA only offers updates for xdg-desktop-portal-gtk.

As such, unless you've already created a scummvm.ini using an out-of-Flatpak version of ScummVM (which may be significantly older and support fewer games), it is impossible to add games to ScummVM on Kubuntu Linux 20.04 LTS or anything else with a comparable version of xdg-desktop-portal-kde.

Given that I can easily just add :ro access to my folder of game assets using Flatseal, you'd think it'd be easy to just revoke the permission to access the portal and have it fall back to its built-in picker, but no luck. Flatpak currently doesn't allow revocation of that (flatpak/flatpak#3977), so it'd be up to you guys to do something like listening for a NO_PORTAL environment variable and forcing ScummVM into a configuration where it doesn't use the portal.

[lotharsm]

Hey there!

I'm currently not active in FlatPak development, but I'm a member of the ScummVM team.

I am not entirely sure if this is something to be fixed in the FlatPak itself or more or less a bug specific to Kubuntu 20.04. However, if one wants to fix this by disabling the GTK dialogs/file picker, the configure option --disable-system-dialogs needs to be used at build time.

Unfortunately, there's no command line option to disable the GTK dialogs at runtime, so simply checking for affected version and modify the startup wrapper script is not possible.

[ssokolow]

Whether it needs to be a runtime thing achievable through something like Flatseal or can be done at compile time would depend on the maintainers' attitude toward forcing users to either move their data or edit their permissions.

For some flatpaks (I believe Corsix-TH is one example), it's considered unacceptable to require users to either use Flatseal or move their game data into a Flatpak-specific location. (Though, given this has --filesystem=xdg-documents, I'm assuming it's not using the Corsix-TH approach of a permanent Documents portal grant since that wouldn't require such a grant.)

I was imagining something along the lines of having the wrapper query the portal version if that's possible and/or check for an environment variable override set via Flatseal and then, if it's decided not to ask the portal for a directory picker, having the wrapper do whatever is needed to keep the GTK code from seeing that it's running in a sandbox before launching ScummVM.

(i.e. the reverse of using export GTK_USE_PORTAL=1 outside Flatpak.)

Does the Flatpak environment just export GTK_USE_PORTAL=1 as part of the setup that could be unset after Flatpak sets it? Is it necessary to take the sledgehammer approach and unset DBUS_SESSION_BUS_ADDRESS at a point beyond where the Flatpak environment overrules what Flatseal asks for? etc.

[AsciiWolf]

Thanks for your report! The GTK file chooser is incorrect and won't work - ScummVM needs to have permanent access to game files, not just one time access using XDG portal. It should have access to xdg-documents by default. This was already discussed and decided to be the best directory for that purpose. Giving the ScummVM Flatpak full home access is not a good solution, at least in my opinion.

[ssokolow]

To be fair to ScummVM, it's not inherently unviable. Apparently OpenRCT2 is proof that you can request a permanent grant of permissions via the file chooser portal.

(Something that horrified me when I learned of it and I'm still trying to figure out where that information is persisted so I can write a tool to scrub it for any applications not on a whitelist of my choosing.)

[AsciiWolf]

Hmm, even whole directories? Interesting. Anyway, I will disable the GTK file chooser/XDG portal usage for now until a better fix is implemented.

[ssokolow]

That said, I still think it's a questionable option for something like ScummVM where, if I botch up the permissions grants, I suddenly have 167 game entries (I'm a collector) where I need to individually invoke the file chooser dialog and re-grant access to the files.

(Compared to something like an emulator with a built-in ROM browser where the UX is built around "grant one or a handful of root paths and the program will list what's in them".)