Desktop entry files

[Matoking]

The upstream Protontricks now comes with two desktop files that allow Protontricks to be launched from desktop, and EXE files to be launched using Protontricks. Those desktop files are not available for the Flatpak version yet, however.

I already experimented with trying to install the desktop file entries in #28, but I wasn't able to get them working. This might require changes in the Flatpak Steam manifest (maybe the merge-dirs option?), or Flatpak proper, since I wasn't able to find examples of Flatpak extensions in Flathub that also install desktop entry files.

@gasinvein might know more about this?

[gasinvein]

Exporting .desktop (or other integration files) from a flatpak extension isn't possible. I see two ways around this:

• Since protontricks is now a desktop app, maybe it makes sense to package it as a standalone app instead of an extension?
• Just bundle protontricks into Steam flatpak; I think it's useful enough to be shipped by default? (CC @nanonyme)

[nanonyme]

On latter: sure, why not. Especially if it doesn't have very large dependencies.

[gasinvein]

I've managed to turn protontricks into a standalone flatpak app. It needs some more work to fully transition, including minor changes upstream (see patches), but it seems to work properly overall (at least it launches, finds games, installs stuff). See the manifest with my changes here.

[gasinvein]

if it doesn't have very large dependencies

Well, I guess Perl (needed for winetricks gui) is the biggest one. Others are rather small.

[Matoking]

I've managed to turn protontricks into a standalone flatpak app. It needs some more work to fully transition, including minor changes upstream (see patches), but it seems to work properly overall (at least it launches, finds games, installs stuff). See the manifest with my changes here.

It works, although a small change to the second patch was required to make it prioritize the Flatpak directory (~/.var/app/com.valvesoftware.Steam/data/Steam) instead of the one in the host system (~./.steam). After that it detects the Flatpak installation correctly and is able to run EXEs from a graphical file manager as long as they're self-contained and don't depend on other files. Adding --filesystem=host fixes this, although that may be overkill.

[gasinvein]

It works, although a small change to the second patch was required to make it prioritize the Flatpak directory (~/.var/app/com.valvesoftware.Steam/data/Steam) instead of the one in the host system (~./.steam). After that it detects the Flatpak installation correctly

Probably I'm missing something, but how flatpak'ed protontricks can even get to ~/.steam, given this dir isn't allowed via --filesystem args (probably it should be, though, in addition to xdg-data/Steam)?

Adding --filesystem=host fixes this, although that may be overkill.

Yeah, allowing the whole host FS to arbitrary .exes that winetricks launches doesn't seem like a good idea.

[Matoking]

Probably I'm missing something, but how flatpak'ed protontricks can even get to ~/.steam, given this dir isn't allowed via --filesystem args (probably it should be, though, in addition to xdg-data/Steam)?

Sorry, I was referring to ~/.local/share/Steam, which is visible inside the Flatpak sandbox and is the Steam installation on the host, not managed by Flatpak. There's also the symlink ~/.steam/steam -> ~/.local/share/Steam.

Adding --filesystem=host fixes this, although that may be overkill.

Yeah, allowing the whole host FS to arbitrary .exes that winetricks launches doesn't seem like a good idea.

The new EXE file association in Protontricks is supposed to make launching EXEs easier - that could be a fan-made patch or mod manager that's distributed as an EXE (and sometimes a handful of files in the same directory). The file association in the desktop file allows that EXE to be launched for a specific Steam app using the usual "Open with" action that file managers support, making their use easier than running the commands manually.

I think one idea would be to allow access not only to the EXE, but the directory the EXE is contained in, but I'm not sure if that's supported by Flatpak's portal functionality. The granted permission could also be too broad if the the EXE is located directly in the home directory rather than a subdirectory.

If that can't be solved easily, it could be documented as a known limitation for now.

[gasinvein]

allow access not only to the EXE, but the directory the EXE is contained in, but I'm not sure if that's supported by Flatpak's portal functionality.

Sadly it isn't currently, see the feature request flatpak/xdg-desktop-portal#463

[Matoking]

I think packaging Protontricks as a standalone application might be the better option if there are no huge downsides; I'm guessing most people would prefer to install Protontricks separately than have an additional desktop shortcut for Protontricks installed on the side? That said, I'm okay with both options.

One issue I can imagine with the standalone approach is that the long list of arguments will have to be maintained separately instead of having them inherited from the Steam Flatpak. I noticed this when audio wouldn't be played when running an external EXE. Ideally, the permissions granted to the application would be similar to if the user had added the EXE as a non-Steam application in the Steam library and launched it there instead.

I don't know how Flathub handles renamed applications (or if they can be handled at all), so this probably means a new Flathub repo will have to be created and the old one marked as EOL if we go that route. Is this correct?

The EXE limitation will also have to be documented, possibly with the note that --filesystem=host can be used to circumvent this limitation with the caveat that it kills security and should be used with care.

[gasinvein]

I don't know how Flathub handles renamed applications (or if they can be handled at all), so this probably means a new Flathub repo will have to be created and the old one marked as EOL if we go that route. Is this correct?

Yes, apps are usually renamed like this. Flatpak supports end-of-life-rebase property for EoL'ed apps to suggest the new app id, but I don't know how it'll work with an extension-to-app rename.

The EXE limitation will also have to be documented, possibly with the note that --filesystem=host can be used to circumvent this limitation with the caveat that it kills security and should be used with care.

Potentially, protontricks could make use of flatpak sub-sandboxes, to keep full permissions for itself, but narrow them for EXEs it launches. But this obviously would require some specific codepath in protontricks.

[Matoking]

I've created a standalone_flatpak branch and applied additional changes there, including the list of arguments copied from Steam Flatpak:

https://github.com/flathub/com.valvesoftware.Steam.Utility.protontricks/tree/standalone_flatpak

The finish-args is copied ad verbatim from Steam Flatpak, so it's possible to do some pruning there if necessary. It seems to work fine now, though, aside from the EXE caveat mentioned before.

[Matoking]

One detail is that Protontricks is categorized as a console-application, while desktop-application also seems like a valid option. Though, in this case it's probably better to leave it as console-application since that's the main use case. The lack of app icon might be a problem if we were to classify Protontricks as a desktop-application instead.

Assuming there are no other issues, I'll probably create a new pull request for com.github.Matoking.protontricks soon.

[Matoking]

I've created a pull request for the new application:

https://github.com/flathub/flathub/pull/2481