Add steamtinkerlaunch source

[brendenhoffman]

I find installing 3rd party compatibility tools cumbersome on the steam deck, steamtinkerlaunch is no exception. Protonup-qt is a massive help. Could steamtinkerlaunch be added to the sources?

https://github.com/frostworx/steamtinkerlaunch

[DavidoTek]

Should be possible, I have to do some testing soon.

[BioIron]

Any news on this?
I have tried installing the Discovery package of steamtinkerlaunch, but steam doesn't recognize it as a compability tool.
Installation process with their script seems... easy, but i didn't tried it yet.
Would be nice to have it added to protonup and have all this tools in one place, with ease of install and uninstall at will.

[DavidoTek]

Any news on this?
Would be nice to have it added to protonup and have all this tools in one place, with ease of install and uninstall at will.

Sadly, no. But I had a look at it, would be nice to have though I'm not sure how easy it is to do.

I have tried installing the Discovery package of steamtinkerlaunch, but steam doesn't recognize it as a compability tool

I think it only works with the Flatpak version of Steam, which the Steam Deck does not use.

Installation process with their script seems... easy, but i didn't tried it yet.

That's probably the best solution for now. Support for ProtonUp-Qt will take a while.

[sonic2kk]

Hi, I contribute to SteamTinkerLaunch every so often and sometimes check in with the community around it. I thought I'd chime in:

SteamTinkerLaunch can be installed in a couple of different ways: Package manager, manually (both root and non-root, though non-root is very much untested), Flatpak Steam as noted, and on Steam Deck it is installed non-root but with some special magic to get it to work on Steam Deck. The script performs checks to see if it is running on Steam Deck and disables things like the notifier and tray icon and whatnot (I believe the Steam Deck is missing some packages to get this to work).

When installed from the package manager, SteamTinkerLaunch is usually installed to /usr/bin/steamtinkerlaunch and has its language files placed in other relevant root directories. Once installed, the command steamtinkerlaunch compat add should be ran to add SteamTinkerLaunch as a compatibility tool. This symlinks the script in /usr/bin/steamtinkerlaunch a compatibility tool into ~/.local/share/Steam/compatibilitytools.d/SteamTinkerLaunch/steamtinkerlaunch, with a few other VDF files. Once installed, SteamTinkerLaunch can be used in two ways: As a compatibility tool (for Proton games) or as a launch option with steamtinkerlaunch %command% (intended for native Linux games).

To install on Steam Deck, the user must run the shell script from the command line (e.g. chmod +x steamtinkerlaunch && ./steamtinkerlaunch). When using SteamTinkerLaunch on Steam Deck, it must be added to the path manually in order to be used as a launch option. This is also true when installing SteamTinkerLaunch manually. And in each instance the steamtinkerlaunch compat add command must be ran to add it as a compatibility tool. There is also an associated steamtinkerlaunch compat del command to remove it as a compatibility tool. To uninstall on Steam Deck (and also from a non-root manual install) a user would run that command to delete the compatibility tool, delete the config folder at ~/.config/steamtinkerlaunch, and then delete the SteamTinkerLaunch folder itself. There is currently no simple way of uninstalling SteamTinkerLaunch from a system-wide manual installation.

For more information please see the SteamTinkerLaunch Installation wiki. This also notes some hard and optional dependencies requires by SteamTinkerLaunch. The most notable one that some distributions will likely not meet is requiring a Yad version that is not ancient 😅

I think SteamTinkerLaunch would be an excellent addition to ProtonUp-Qt, I actually found this issue coming to suggest it myself! But if it's to be added I think it would be best if it's able to be installed for Steam Deck, for Flatpak Steam and for a regular Linux desktop, and I see a few hurdles with this.

Given the functionality already present in ProtonUp-Qt I could see checking if the user is using Flatpak Steam and installing the SteamTinkerLaunch Flatpak in that case being relatively straightforward 😄 For Steam Deck, that might be a bit less trivial, as it has to be installed in a specific way as mentioned above. I suppose some kind of hardcoded check could be done for SteamOS? There's also the issue that Steam Deck is only supported in SteamTinkerLaunch >= v10. Flatpak support may be partially available for v10, but the only official release with Flatpak support is v11.

That brings us to installing on a regular Linux desktop, which I could see being a little more troublesome. Probably, the solution here would be to do a non-root manual install of SteamTinkerLaunch. The trouble is, this is almost entirely untested, ProtonUp-Qt would probably have to do the heavy lifting of adding SteamTinkerLaunch to the path, and also requires the user to set their language to a corresponding SteamTinkerLaunch translation file with the command steamtinkerlaunch lang=lang/langfile.txt. The user can do this after-the-fact but it might be a bad user experience. A solution might be to have a dialogue prompt once installation finishes, asking the user to select their language file. This could be a dropdown populated based on the lang/*.txt files, and the default selection could be the user's current language, and perhaps default to English if unavailable (maybe with some text saying "SteamTinkerLaunch is not translated in your language yet")? SteamTinkerLaunch should probably not be installed itself to compatibilitytools.d either, as when steamtinkerlaunch compat add is ran, it creates the compatibilitytools.d/SteamTinkerLaunch folder. If there is any sort of caching folder for ProtonUp-Qt, the install could be stored there.

Finally, SteamTinkerLaunch package manager packages tend to be a bit all over the place, with some offering latest Git builds and some offering stable builds. SteamTinkerLaunch tends to have reasonable gaps between releases with not really any "bugfix" releases, so there can be very desirable features only available in Git releases for a few months. For that reason it might be nice to provide an option to use a "Git" release of SteamTinkerLaunch for users as well.

I know that's a lot but I wanted to give as much background as possible on how SteamTinkerLaunch installs work and provide ideas on how one might go about adding it 😄 I'm a bit handy with Python but not yet familiar with how ProtonUp-Qt works. if this isn't a priority I could take a look at adding it, but if anyone is already working on it or wanting to work on it please go ahead. I might not be able to figure out how to add it anyway 😅

EDIT: Started some initial work on a fork getting a SteamTinkerLaunch source added. Not sure how far I'll get but right now I'm able to get it to download SteamTinkerLaunch at least. That's one step out of the way 😅 Now I just gotta implement the steps I outlined above. Hopefully I can get there!

[DavidoTek]

Thank you for the detailed information.

I could see checking if the user is using Flatpak Steam and installing the SteamTinkerLaunch Flatpak in that case being relatively straightforward

A simple xdg-open appstream://com.valvesoftware.Steam.Utility.steamtinkerlaunch should do, right?
I'd probably add it to the Flatpak compatibility tool section to keep the ctmod file simple.

Once installed, the command steamtinkerlaunch compat add should be ran to add SteamTinkerLaunch as a compatibility tool.

Does it do anything else than copying some files over to compatibilitytools.d? If so, we have to ensure that the Flatpak has all the needed permissions.

For Steam Deck, that might be a bit less trivial, as it has to be installed in a specific way as mentioned above. I suppose some kind of hardcoded check could be done for SteamOS?

/etc/lsb-release probably contains SteamOS...

do a non-root manual install of SteamTinkerLaunch

That's what we want to do. I think ProtonUp-Qt should only install compatibility tools per user.

requires the user to set their language to a corresponding SteamTinkerLaunch translation file

We should be able to map the country code e.g. de-DE to german.txt automatically, otherwise fall back to english.

If there is any sort of caching folder for ProtonUp-Qt, the install could be stored there.

Can we store it in ~/.local/share/steamtinkerlaunch

For that reason it might be nice to provide an option to use a "Git" release of SteamTinkerLaunch for users as well.

Showing/downloading the Git repo as zip in addition to the release archive isn't a problem.

I know that's a lot but I wanted to give as much background as possible on how SteamTinkerLaunch installs work and provide ideas on how one might go about adding it

I had a look at the installation wiki a few days ago and it was quite overwhelming ;)

Started some initial work on a fork getting a SteamTinkerLaunch source added. Not sure how far I'll get but right now I'm able to get it to download SteamTinkerLaunch at least.

That's great! Any progress is welcome. If there's something specific to ProtonUp-Qt that doesn't work right, I can implement it afterwards.

[sonic2kk]

Thank you for the responses! That answers a lot of the questions I was trying to figure out last night 😅

Does it do anything else than copying some files over to compatibilitytools.d? If so, we have to ensure that the Flatpak has all the needed permissions.

That's a good point and I'd like to clarify a little. The steamtinkerlaunch compat add itself should just symlink the steamtinkerlaunch script and set up the toolmanifest.vdf and compatibilitytool.vdf. These contain information about how Steam should run SteamTinkerLaunch and what to set the tool name as and such. Here is how a SteamTinkerLaunch installation in compatibilitytools.d looks:

This symlink points to wherever SteamTinkerLaunch is downloaded to. However, running any SteamTinkerLaunch command for the first time, including steamtinkerlaunch compat add, should set up SteamTinkerLaunch's config structure in ~/.config/steamtinkerlaunch (this could change in future, though there is no one actively working on it as far as I know, see sonic2kk/steamtinkerlaunch#486).

For SteamTinkerLaunch Flatpak I believe this is all taken care of, I remember some discussion about running it automatically when the feature was in development. I don't have Flatpak Steam on any of my machines but our Steam Flatpak wiki page (written up by a major contributor of Flatpak support) seems to imply that it's all taken care of "automagically" :-) Looking at the Flatpak yml to my untrained eye it seems like it runs make install, though I don't recall our Makefile handling this automatically. I'll have to ask one of the Flatpak contributors about this to confirm! 😄

Can we store it in ~/.local/share/steamtinkerlaunch

Just to confirm, as I'm unfamiliar with some of these more technical directory structures, this is separate from ~/.config/steamtinkerlaunch, right? Or did you mean storing it in SteamTinkerLaunch's config directory? Either is fine imo, I'm just asking to make doubly sure :-)

Thank you very much!

[DavidoTek]

The steamtinkerlaunch compat add itself should just symlink the steamtinkerlaunch script and set up the toolmanifest.vdf and compatibilitytool.vdf.

Creating symlinks and creating new files is possible from inside the Flatpak if the Flatpak app has the needed permissions to the folders (actually creating symlink doesn't even require permissions as the target doesn't need to exist/be visible for the app).

~/.config/steamtinkerlaunch

For the ProtonUp-QT Flatpak: We need to give permission to this folder so that STL can create it.

For SteamTinkerLaunch Flatpak...

I don't think we have to do much here other than launching the users default app store (e.g. Discover, GNOME Software) and open the STL page.

Just to confirm...

~/.local/share/steamtinkerlaunch is a different folder than ~/.config/steamtinkerlaunch
I think this is where STL gets installed on the Steam Deck, correct me if I'm wrong. Either way, we should use the same folder as on Steam Deck to keep it simple.

[sonic2kk]

I think this is where STL gets installed on the Steam Deck, correct me if I'm wrong. Either way, we should use the same folder as on Steam Deck to keep it simple.

To my knowledge there isn't really a "standard" folder where SteamTinkerLaunch is installed on Steam Deck, basically wherever the user downloads it and runs the script from is the "install" folder on Deck 😄 I verified this on my Steam Deck with SteamTinkerLaunch installed. The symlink points to where I downloaded SteamTinkerLaunch on my Deck, and I couldn't find any STL folder outside of ~/.config/steamtinkerlaunch. I also looked through the script and didn't see any other folders specifically for Steam Deck.

We could put it in ~/.local/share/steamtinkerlaunch though, and give the ProtonUp-QT Flatpak the relevant permissions 😄

Thanks again for all your insight and help 👍

[sonic2kk]

My bad, when you install SteamTinkerLaunch on Deck, it actually creates a folder at /home/deck/stl/prefix. This doesn't seem like a symlink of any kind, the files look to be directly copied to that path from wherever the user downloaded and ran the SteamTinkerLaunch script from.

There are various other dependencies (I guess Yad AppImage for example) which are in /home/deck/stl/deps.

[sonic2kk]

Woohoo, I was successfully able to implement a basic SteamTinkerLaunch source! For now I have only tested a Linux Desktop scenario, which would be the non-root manual installation I mentioned earlier. I tested on my laptop which didn't have SteamTinkerLaunch installed before and I was able to download and install it with ProtonUp-Qt! It also successfully added the script to the path so SteamTinkerLaunch can be used as a launch option!

I still need to test Steam Deck, and partially related, I haven't even touched anything related to Flatpak permissions or STL Flatpak installation yet. I also have not fully tested the code that sets the language for SteamTinkerLaunch.

Currently STL is downloaded and extracted to ~/.local/share/steamtinkerlaunch (which is created if it doesn't exist). Then:

• If we're not on Steam Deck: Set SteamTinkerLaunch's language based on the system's locale, with a fall back to en_US (english.txt).
• If we are on Steam Deck, run the SteamTinkerLaunch script which sets up STL's config structure and, crucially, sets up the STL install at /home/deck/stl/prefix. Then change to that directory so the compatibility tool is set up from the right path

Regardless of platform, we then add STL as a compatibility tool with ./steamtinkerlaunch, and then add STL to the path variable so that it can be used as a launch option for native games.

From initial testing on the desktop this seems to work. However there is still some more work to do:

1. Make sure ProtonUp-Qt Flatpak has the necessarily permissions for the necessary directories (/home/deck/stl/prefix, I think Flatpaks should have access to this anyway? Also make sure it has permissions for ~/.local/share/steamtinkerlaunch).
2. Test on Steam Deck. Not sure if I can run from source on Steam Deck, either way I could probably just build an AppImage and send that over to the Deck.
3. Add support for downloading latest SteamTinkerLaunch git
4. The list of compatibility tools seems to always list STL as being unused. Could you give me some help on how I could go about fixing this? 😄
5. Implement SteamTinkerLaunch Flatpak support. For now, this is entirely unimplemented

I'm happy with the progress that I've made so far. Once I've tested to make sure it works on Steam Deck and gotten some form of Flatpak support added, I'll get up a PR for review! The development effort is going on here for anyone interested.

[DavidoTek]

Awesome!

Currently STL is downloaded and extracted to ~/.local/share/steamtinkerlaunch

Maybe we can use ~/stl instead so ProtonUp-Qt can detect if it was installed manually before.

1. Make sure ProtonUp-Qt Flatpak has the necessarily permissions for the necessary directories

When we know all directories, I will add the permissions in the next release.

1. ~/stl
2. ~/.config/steamtinkerlaunch
3. maybe ~/.local/share/steamtinkerlaunch depending on what we use in the end

4. The list of compatibility tools seems to always list STL as being unused. Could you give me some help on how I could go about fixing this?

ProtonUp-Qt checks if STL is selected as a compatibility tool in the Steam game settings. It won't detect if it's just used as a command line option.
ProtonUp-Qt counts the games using the tool and says it unused if the number is zero, see

ProtonUp-Qt/pupgui2/pupgui2.py

Line 171 in 8c66d08

ct.no_games = len(games)

We can check if the command line contains stl, might be a bit hacky but should do the trick.

5. Implement SteamTinkerLaunch Flatpak support. For now, this is entirely unimplemented

Adding following should do work:

#constants.py
STEAM_BOXTRON_FLATPAK_APPSTREAM = 'appstream://com.valvesoftware.Steam.Utility.steamtinkerlaunch'
#pupgui2.py line 323
btn_dl_stl = QPushButton('Steam Tinker Launch')
layout1.addWidget(btn_dl_stl)
btn_dl_stl.clicked.connect(lambda: os.system('xdg-open ' + STEAM_STL_FLATPAK_APPSTREAM))

I'm happy with the progress that I've made so far.

Thank you, that will be a great addition to ProtonUp-Qt and probably help a lot of people getting started with Linux gaming/Steam Deck!

[sonic2kk]

Thanks for all the help. I added the lines in the appropriate files to hopefully enable Flatpak support.

Sadly it seems I was a little preemptive with proclaiming launch option support. For some reason I thought os.environ['PATH'] would change the path variable. Very silly of me! I guess if we want to go the road of setting the PATH variable we would have to write out to the shell profile. That comes with the complication of 1) do we actually want to do that, and 2) if so we need a shell-agnostic way of identifying the shell profile (e.g., .bash_profile/.bashrc with Bash, .zshrc for Zsh, etc). Maybe on Steam Deck it could be safe to assume a shell? Though I think I've seen people using OhMyZshon Steam Deck... Not sure if there's a good way forward for this. From a usability perspective it makes sense to handle this, but from a "security" point of view it could be dangerous, and from a development point of view if might be cumbersome.

We could have a hardcoded list of shell profile files that correspond to each shell type. For example: shells = { 'bash': [ '.bashrc', '.bash_profile' ], 'zsh': '.zshrc', ... }. We can check the user's shell with the $SHELL variable (and default to Bash in case the shell does not export it for some reason). Then we can search for the corresponding shell profile and run something like subprocess.run(['sed', '-i', f's|export PATH="$PATH"|export PATH="$PATH:{stl_path}"|']), where stl_path is the path to the installed SteamTinkerLaunch script (~/stl/prefix/steamtinkerlaunch on Deck, ~/stl/frostworx-steamtinkerlaunch-blahblah/steamtinkerlaunch on Desktop). Even just writing this out makes the idea seem a bit hacky to me. Any thoughts on this? Is this something you feel ProtonUp-Qt should be meddling with?

I haven't yet tested on Steam Deck but I have some preliminary checks for it in place, I'll do some testing on Deck and report back once I have some good news 😄 GitHub is a little temperamental with trying to download SteamTinkerLaunch, it doesn't have a browser_download_url like other compatibility tool downloads seem to. I think this is fine and GitHub just doesn't like how many requests I've been making during debugging.

[DavidoTek]

Even just writing this out makes the idea seem a bit hacky to me. Any thoughts on this?

We can define a line to be added to the .profile/.zprofile file, e.g. if [ -d "$HOME/stl/prefix/steamtinkerlaunch" ]; then PATH="$HOME/stl/prefix/steamtinkerlaunch:$PATH"; fi
When installing STL, the line would just be appended to the profile file and when STL is removed, ProtonUp-Qt would search for it in the profile file and remove it (if the user changed the line, it will not be removed).

Is this something you feel ProtonUp-Qt should be meddling with?

I believe we have no other option. Opening a message asking the user to add STL to your PATH yourself is not a good option at least.

~/stl/prefix/steamtinkerlaunch on Deck, ~/stl/frostworx-steamtinkerlaunch-blahblah/steamtinkerlaunch on Desktop

Can't we use ~/stl/prefix/steamtinkerlaunch for everthing? Or is prefix a placeholder for something?

Alternatively, instead of adding the folder to PATH, we can create a symlink to stl in ~/.local/bin

I think this is fine and GitHub just doesn't like how many requests I've been making during debugging.

Yeah, there is a limit to how many requests you can make without specifying a Auth Token. You can get a personal access token from GitHub settings and write it to the environment variable PUPGUI_GHA_TOKEN so ProtonUp-Qt can use it.

The development effort is going on here for anyone interested.

Awesome!

[sonic2kk]

You can get a personal access token from GitHub settings and write it to the environment variable PUPGUI_GHA_TOKEN so ProtonUp-Qt can use it.

Thank you!

Can't we use ~/stl/prefix/steamtinkerlaunch for everthing?

We could, but ~/stl/prefix is where the actual STL files live. Sorry, I got the path a bit mixed up and had to double check, it doesn't actually end with steamtinkerlaunch. Here is a screenshot of how an STL install looks on Deck:

There's no reason we couldn't download and extract to that folder that has all the STL files, but here's my thought process:

• On Linux Desktop, we don't need to have the ~/stl/prefix structure. Just simply extract to ~/stl/<whatever name github gives the download>. On Desktop, this is the folder where the actual STL install will live, and where the script in compatibilitytools.d will link to.
• On Steam Deck, we still download to ~/stl/<whatever name github gives the download>, but when we run the script from that folder, STL has some Steam Deck setup stuff which creates the folders I listed above. On Deck, the actual SteamTinkerLaunch install lives in ~/stl/prefix, and the symlink in compatibilitytools.d points to the /home/deck/stl/prefix/steamtinkerlaunch script. Therefore we can remove the download on Steam Deck and simply leave ~/stl/prefix as the install folder there.

Prefix doesn't stand for anything, it's just the name that was given to the folder with the SteamTinkerLaunch install.

We can define a line to be added to the .profile/.zprofile file

I didn't know about those files, though on desktop these files are not sourced (by Zsh at least) until the user logs in again. For Steam Deck, the .profile file is not sourced at all? At least I can't add anything to the PATH from a .profile file, or get the Deck to do anything with that file. echo "Profile loaded" did nothing on Deck but worked when I ran zsh --login on my desktop (added to .zprofile on my Desktop). The was no .profile on Deck until I created it.

Alternatively, instead of adding the folder to PATH, we can create a symlink to stl in ~/.local/bin

I actually really like this idea, but Steam Deck doesn't have ~/.local/bin nor does it have that in its PATH, and it doesn't seem very straightforward to add to PATH on Steam Deck without directly modifying the .bashrc/.bash_profile files. But if the user isn't using Bash on Deck those files could exist but be unused.

On my laptop running Arch, ~/.local/bin isn't in my path. In fact, my path on my laptop is basically identical to the Steam Deck. My PC running Arch does have ~/.local/bin in its path, but I've had Arch installed on that machine for coming on 6 years now, so it's possible I could've added it at some point or that at one point Arch did have it. So I don't think symlinking to that location is very reliable unfortunately.

A somewhat hacky solution would be to do some checks, though I don't even know if these would work:

• If the current shell is Bash, assume .bashrc and add if [ -d "<relevant STL install path>" ]; then export PATH="$PATH:<relevant STL install path>"; fi to it (this means the user doesn't have to log in again)
• If the current shell is Zsh, add if [ -d "<relevant STL install path>" ]; then PATH=$PATH:<relevant STL install path>"; fi to the .zshrc file (again, means the user won't have to log in again)
• If using fish, add path to the file at $HOME/.config/fish/config.fish, though I'm not sure of the correct syntax
• If using Korn Shell, add path to .kshrc (I believe this to be the path, though I'm not sure and I'll also have to check the exact syntax)
• Else, assume .profile will be used and loaded by whatever shell is running, and add if [ -d "$HOME/stl/prefix/steamtinkerlaunch" ]; then PATH="$HOME/stl/prefix/:$PATH"; fi to the .profile (most shells should respect .profile from what I've read)

Replacing <relevant STL install path> with either the Steam Deck install path ($HOME/stl/prefix) or the installation path on Desktop Linux (as of writing,$HOME/stl/<whatever github calls the download>, but of course this might change 🙂). That way we should be able to add to the path on Steam Deck too, without having to assume the Deck is using Bash. Though Bash is a dependency of SteamTinkerLaunch, there is no guarantee users on Deck or Desktop will be using it.

I found this StackOverflow question which didn't really have a resolution, about a shell agnostic way of getting initialization files. Also this StackOverflow answer about .bashrc equivalents in other shells.

So covering Bash with .bashrc, covering Zsh with .zshrc, covering fish with $HOME/.config/fish/config.fish, covering ksh with .kshrc, and defaulting to .profile for all other shells. I'm slightly uneasy about defaulting to .profile because it'll mean the user has to log back in again, but I suppose any shell-specific issues could be fixed as users of those shells report issues.

And of course before this, we'd check if that line is already in the files we're adding to, on Steam Deck and Linux Desktop (checking on PATH may not be enough in case there are different folders or whatever, checking for the path that we just installed to is more effective in my mind).

I believe we have no other option. Opening a message asking the user to add STL to your PATH yourself is not a good option at least.

I wholeheartedly agree, doing this kind of heavy-lifting for the user would be ideal.

[sonic2kk]

So I just finished testing on Steam Deck and it works! SteamTinkerLaunch is able to perform a regular install and I'm able to launch games with it. Of course, there is still no launch option support since I haven't worked out a path forward (no pun intended) to add STL to the system path :-) I haven't been able to test Flatpak support yet but the code is there for it and it should hopefully work.

To recap, here is currently what works:

• STL can be downloaded and installed on Linux Desktop
• STL can be downloaded and installed on Steam Deck!!
• STL should be supported for Flatpak Steam

Currently here is what does not work

• STL can't be used as a launch option on desktop. Adding to a .profile/.zprofile may work, though I'm not totally sure yet (not sure if it can be shell and distro agnostic)
• STL can't be used as a launch option on Steam Deck, and I have no solution for that just yet.
• There is an intermittent issue on my side where sometimes STL can't be downloaded. Even when using a token, sometimes it doesn't send the Content-Length in the header. I made a lot of requests when trying to figure out how to correctly send a request, as STL releases just link to the source code and don't have a browser_download_url, so I think this issue is just on my side as I've made a lot of requests 😓 Hopefully this should not be a problem for users!
  • Sometimes if you repeatedly attempt to download, it will be able to download, though that happens maybe 1 out of 20 attempts. I'm not sure if the issue is from me making too many requests or if sometimes GitHub just does not send Content-Length, which would be strange. Given that this used to work fine until I made too many requests, I think this is just on me, but hopefully we'll find out soon enough!
• No Git download but that shouldn't be too hard to implement (I hope).

So right now, the only problems left (assuming the download issue is a rate-limiting issue) is adding SteamTinkerLaunch to the path for the user, and once that's solved then there should be an option to install a Git release of STL. Once it can install a stable build it should just be a case of changing how STL is downloaded, the install process should be identical.

After this I should be able to get a PR up for review 🥳

[DavidoTek]

A somewhat hacky solution would be to do some checks, though I don't even know if these would work: [...]

We can add the line in all shell rc files that exist. That way the user can use different shells.
Also, checking the current shell from inside Flatpak isn't that easy.

I'm slightly uneasy about defaulting to .profile because it'll mean the user has to log back in again,

Yes, probably the ...rc files are a better option

So I just finished testing on Steam Deck and it works! [...] I haven't been able to test Flatpak support yet but the code is there for it and it should hopefully work.

Great! I had a look at your code, should work fine inside Flatpak.

1e8c640 can be omitted. The Authorization header is already set for the requests.Session rs here.

No Git download but that shouldn't be too hard to implement (I hope).

One solution might be to get a list of commits from https://api.github.com/repos/frostworx/steamtinkerlaunch/commits?per_page=10 and rename/add the ones which have a tag/release https://api.github.com/repos/frostworx/steamtinkerlaunch/tags.

[sonic2kk]

We can add the line in all shell rc files that exist. That way the user can use different shells.

Ah! Not sure why I didn't think of this specifically, I think this solution is good. I'll work on adding STL to the path this way, hopefully it'll be straightforward enough 🙂

Also, checking the current shell from inside Flatpak isn't that easy.

I figured, but that should be fine as STL Flatpak doesn't advertise support for using STL as a launch option. That should be managed by STL Flatpak I think 😄 Though it would be nice, I don't think it's up to ProtonUp-Qt to manage this if the feature itself isn't officially supported.

The Authorization header is already set for the requests.Session rs here.

Ah! No worries, that was mostly just for testing. Thanks for the confirmation, I'll be sure to remove it before getting a PR up.

One solution might be to get a list of commits from https://api.github.com/repos/frostworx/steamtinkerlaunch/commits?per_page=10 and rename/add the ones which have a tag/release https://api.github.com/repos/frostworx/steamtinkerlaunch/tags.

Sorry if I was unclear but I meant a Git download as in downloading the latest Git release, as in a release of STL from the latest Git commit which doesn't have a release yet (for example, steamtinkerlaunch-git from the AUR).

I see ProtonUp-Qt has this option in its "About" menu:

Maybe STL git should only be shown if this is enabled? In that case I guess downloading from the latest Git would be a case of git clone url. Though I'm not sure how ProtonUp-Qt handles updating git releases of compatibility tools.

Using the most bleeding-edge build of STL can be really beneficial as often there can be relatively significant gaps between releases, and sometimes users are asked to help test features in the latest master. So I would be keen to find a way to implement this 😄

[sonic2kk]

So I've got STL adding to the path working. I tested with Bash, Zsh and Fish. It should also add to .kshrc as well. I believe this should cover the main shells.

I'll need to add support for Git as well Can now download STL from Git! I set the download source as https://github.com/frostworx/steamtinkerlaunch/archive/master.tar.gz and that works.

Something occurred to me: Is there a way to specify a custom deletion method for compatibility tools? With something like Proton-GE you only have to remove the compatibility tool from compatibilitytools.d, but for STL there would be a few more steps:

• Remove the compatibility tool (is currently being done with the Remove Selected button)
• Removing the $HOME/stl folder to remove the actual install
• Removing STL from the path
• Removing $HOME/.config/steamtinkerlaunch where STL's configuration files live
  • When installing mods and such this is also where MO2/Vortex and other things like CheatEngine live. But I think we can assume if a user is removing STL they understand that they will be losing their modded games. At least if they were to uninstall STL themselves this is what they would do to do a full proper uninstallation
  • In other words a user removing STL should be doing so with the intent in mind to remove their mods

Also, unlike other compatibility tools, there is no real support for having multiple versions of STL installed at once. I'm not sure if maybe Boxtron/Roberta is also like this, but it is expected that a user will only have one version of STL installed at any given time. One benefit of having integration with ProtonUp-Qt means a user can upgrade/downgrade more easily 🙂

If we really wanted to manage multiple versions, we could run ./steamtinkerlaunch compat add on the version we want to currently use, but there is no guarantee that upgrading/downgrading versions is going to work as all versions will share a $HOME/.config/steamtinkerlaunch.

There is also the case of upgrading SteamTinkerLaunch. When upgrading we should basically do all the uninstallation steps except for removing the $HOME/.config/steamtinkerlaunch folder, then run through a regular installation again.

Is there an advisable way of setting "custom" uninstall/upgrade methods for compatibility tools?

---

I noticed that ProtonUp-Qt was always marking STL as "unused". I did some digging into this and games using SteamTinkerLaunch as a compatibility tool seem to be marked as using Proton-stl

I'm not too sure where this name comes from I'm afraid. If I select "SteamTinkerLaunch" from that dropdown, the game no longer uses any compatibility tool. It seems the cause of STL showing up as unused is a name mismatch.

So next up is fixing this, then looking into adding some sort of upgrade/downgrade/remove path 😄

[DavidoTek]

Also, checking the current shell from inside Flatpak isn't that easy.

I figured, but that should be fine as STL Flatpak doesn't advertise support for using STL as a launch option.

Actually, what I meant was that the Flatpak version of ProtonUp-Qt cannot read the global $SHELL variable, as it is set to /bin/sh inside the Flatpak. But I guess it doesn't matter too much in the current implementation.

I see ProtonUp-Qt has this option "Advanced Mode" in its "About" menu:
Maybe STL git should only be shown if this is enabled?

I agree.

Also, unlike other compatibility tools, there is no real support for having multiple versions of STL installed at once. [...] One benefit of having integration with ProtonUp-Qt means a user can upgrade/downgrade more easily.

I don't think this is a problem.
Does STL update automatically when the script is launched?

Is there an advisable way of setting "custom" uninstall/upgrade methods for compatibility tools?

Ideally, each ctmod would deal with detecting, installing and removing the compatibility tool. I haven't implemented it (yet?) so we may need to implement in some hacky way for now (maybe detect the name and then execute a special function only for STL, could be defined in steamutil.py).

It seems the cause of STL showing up as unused is a name mismatch

Probably because the internal name is different from the folder name which ProtonUp-Qt uses. In the game list it will also show the internal names if they differ.

[sonic2kk]

Actually, what I meant was that the Flatpak version of ProtonUp-Qt cannot read the global $SHELL variable, as it is set to /bin/sh inside the Flatpak. But I guess it doesn't matter too much in the current implementation.

Hmm, this might have a few implications for other parts of the code actually but I'm not totally sure.

1. It might impact the checks done for the STL hard dependencies. Though these are also done for Boxtron.
2. Similar to above, it might impact the check for checking if the fish shell is installed. Fish has a way to permanently set its environment variables from a command, and so the ctmod will only run the commands to add it to the fish shell path if shutil.which('fish') passes.

Once I get the ctmod working when running from source I'll do some AppImage and Flatpak testing 😄

I don't think this is a problem.
Does STL update automatically when the script is launched?

For a non-root manual install, f you download a new release of SteamTinkerLaunch and the folder name changes, you have to run ./steamtinkerlaunch compat add to update the symlink in compatibilitytools.d.

When installing via package manager/flathub/system-wide with sudo make install this isn't ever really a problem though. So this step is really only necessary for non-root manual installs or even root installs if you're changing the install folder.

Ideally, each ctmod would deal with detecting, installing and removing the compatibility tool. I haven't implemented it (yet?) so we may need to implement in some hacky way for now (maybe detect the name and then execute a special function only for STL, could be defined in steamutil.py).

Sounds good 😄

Probably because the internal name is different from the folder name which ProtonUp-Qt uses. In the game list it will also show the internal names if they differ.

The name set in one of the .vdf files for STL is "Steam Tinker Launch". I'll keep looking to see if I can find where this name is coming from and resolve the mismatch.

[DavidoTek]

It might impact the checks done for the STL hard dependencies. Though these are also done for Boxtron.

That's true. ProtonUp-Qt skips the checking altogether, when running inside Flatpak. Not sure how we can fix this.

ctmod will only run the commands to add it to the fish shell path if shutil.which('fish') passes

I think shutil.which('fish') will return false as it cannot detect those inside the Flatpak.

[sonic2kk]

So if a user tries to install Boxtron for example when running ProtonUp-Qt Flatpak and they're missing dependencies for Boxtron, is it up to the user to know that they are missing those dependencies? Basically if they install something like Boxtron and it won't run, the expectation is that the user should know that they don't have Boxtron's dependencies? If so, though not great, we can place the expectation on the user for SteamTinkerLaunch too.

This isn't a worry for Steam Deck as the STL core dependencies are downloaded and set up through some Steam Deck-specific magic (and there are limitations here, such as having to use the Yad AppImage which doesn't support WebKit, so no built-in STL wiki browsing). The main issue here is for desktop users that want to install SteamTinkerLaunch but may be missing dependencies. We could add a list of dependencies to the information section of the Description of the ctmod though.

Most distros will have most SteamTinkerLaunch's dependencies as they are fairly standard, the biggest exception being yad, or rather some distros such as Ubuntu package a very old version Yad. But some tools like xdotool may be missing on some desktop environments e.g. distros which only package Wayland sessions.

Does this compatibility skip apply to every compatibility tool? Sorry, I'm not totally familiar with the code so I'm not sure if it just skips the is_system_compatible check for each ctmod.

I think shutil.which('fish') will return false as it cannot detect those inside the Flatpak.

There is a potential solution, though imo it's less than ideal: If we're running in a Flatpak, instead of checking shutil.which('fish'), we could check to see if there are fish configuration files stored in the user's home directory (basically if ~/.config/fish exists and it isn't empty). That way we could "guess" if fish is installed. However I'm not sure if from Flatpak we can call Fish with subprocess, something like subprocess.run(['fish <<< \'echo 'Hello\''], shell=True) might not work from Flatpak, I am not totally sure.

Even if the above does work, this solution is less than ideal because there is the potential for fish configuration files to be left over if Fish is no longer installed. To get around this we could wrap the Fish path checks in a try/except, so if subprocess fails to call fish we can just assume the user doesn't actually have Fish installed.

[DavidoTek]

Basically if they install something like Boxtron and it won't run, the expectation is that the user should know that they don't have Boxtron's dependencies?

It's not an expectation, but rather a limitation by the Flatpak version. I'm not sure how one would do that.

I'm not sure if it just skips the is_system_compatible check for each ctmod.

If ProtonUp-Qt is running as Flatpak, it will just ignore the return value of is_system_compatible

the biggest exception being yad

Can we include/download yad next to STL?

If we're running in a Flatpak, instead of checking shutil.which('fish'), we could check to see if there are fish configuration files stored in the user's home directory.

That's the way to go. Detecting if dependencies are installed outside the Flatpak is hard/requires more permissions than ideal and executing commands from inside Flatpak that run outside the Flatpak sandbox is not possible afaik.

Even if the above does work, this solution is less than ideal because there is the potential for fish configuration files to be left over if Fish is no longer installed.

Can we just add it to the path configuration file and don't care whether they are actually used?

[sonic2kk]

Can we include/download yad next to STL?

We could download yad and point STL to it, it allows for pointing to custom yad binaries. However I'm not sure if it's possible to build a portable non-root Yad and point SteamTinkerLaunch to it. There are also Yad AppImages but I believe these have limitations over a system Yad install. The STL Steam Deck wiki notes that the Yad AppImage used there doesn't have WebKit support, and the Custom Yad wiki page notes that there are custom AppImages available with WebKit support, but they are big and STL doesn't officially support or maintain them.

I think maybe having a Yad AppImage with full WebKit support is probably the ideal but as mentioned this AppImage is apparently quite large and it seems like the repo for the custom Yad AppImage just hosts the scripts to compile it yourself, meaning we'd have to compile it with downloading STL.

I'm not sure how to proceed on this front.

Can we just add it to the path configuration file and don't care whether they are actually used?

As far as I know with the Fish shell (though I'm not too familiar with it), that's not very easy. It seems like it may be possible to add it to the fish.config file but the "expected" way seems to be to set universal variables from inside Fish.

[sonic2kk]

So I looked into resolving the mismatch between STL's internal name (Proton-stl) and what ProtonUp-Qt looks for (SteamTinkerLaunch). It looks like there's no way with ProtonUp-Qt to set the internal name of a ctmod? It looks like this is only checked for "official" compatibility tools e.g. Proton.

From what I looked into with GE-Proton and Proton-tkg, it seems like generally the internal name for compatibility tools is rarely different. But for some reason, STL uses a different internal name. Though this could be changed on STL side this wouldn't have any effect on older releases. I hope this isn't too forward but is there a way ProtonUp-Qt could add support for setting different internal names for ctmods? Or perhaps there's a different way to go about this.

[DavidoTek]

I hope this isn't too forward but is there a way ProtonUp-Qt could add support for setting different internal names for ctmods? Or perhaps there's a different way to go about this.

Currently, the display name is just set to the folder name:

ProtonUp-Qt/pupgui2/util.py

Line 368 in 430c116

ct = BasicCompatTool(folder, install_dir, folder, ct_type=CTType.CUSTOM)

Ideally, we wouldn't use a global function which just returns a list of folder names, but instead each ctmod would return a curated list of its own compatibility tools. I haven't gotten to implement it yet though.
A solution would be to read the display name from the vdf file if it's available and have the foldername as displayname as a fallback if there is no vdf file (e.g. Wine-GE for Lutris).

[sonic2kk]

Thanks, I'll look into implementing something to fix this counting problem.

I did some more research and it seems there may indeed be a way to set the path for fish from a text file rather than from Fish. I don't think this is an "intended" way but it might work. I'll do some playing around with it later and see if I can figure something out. It seems like we can simply write out to a file $HOME/.config/fish/fish_variables and add a path to SETUVAR fish_user_paths:/our/path\x1e/another/path, where \x1e is used as the separator between variables in the fish_variables path. I think I'll replace the code that runs the fish via subprocess.run with a write out to this variable file, whether the user is running in Flatpak or not.

Still not totally sure how to fix the Yad/general dependency checking problems but I'll come back to that :-)

[sonic2kk]

I was able to implement adding to the Fish paths by writing to the fish_variables file instead of having to run Fish commands with subprocess! I think it makes the code a lot cleaner too. It won't attempt to add (or remove) fish from the fish paths if fish isn't installed or if the fish_variables file doesn't exist (this is pretty much essential for Fish to work from what i can tell, so there wouldn't be a valid Fish install without this file!).

I refactored the SteamTinkerLaunch-git ctmod to show branches instead of just git. Right now, STL only has one branch, but in case this ever changes in future (if there are any super experimental development features on another branch for example) ProtonUp-Qt should be able to deal with it. I wanted to give extra care to ensuring STL-Git can be easily, in part because that'll be the version I want to use when I use ProtonUp-Qt to manage STL on my Deck 😄

Next up is implementing a fix for counting which games are using STL as a compatibility tool!

I had a couple of other ideas I wanted to raise:

• Only STL v10.0 and up support Steam Deck. Is it worth showing a warning to a user if they attempt to install an unsupported version of STL on Steam Deck?
• The progress bar at 99% says "Extracting SteamTinkerLaunch". This is probably fine to most users but I was wondering if there's any way to change it to say "Installing SteamTinkerLaunch"? From looking at the code it seems hardcoded to a certain progress bar percentage, so maybe I could set the progress to 99.5 from the ctmod and then have the status bar display "Installing SteamTinkerLaunch"?

Not sure how to proceed with the dependency checking stuff from ProtonUp-Qt Flatpak. There's probably not much we can do really, SteamTinkerLaunch's dependencies are documented, though I am somewhat hesitant to just leave it up to the user to know what dependencies they need. On one hand a user should know what they're installing so should ideally know what STL is before installing it blindly through ProtonUp-Qt, and they should at least visit the STL docs to understand how to use it. In that regard, they should know that STL will need some additional dependencies. And the Steam Deck case is already covered by STL where it manages dependencies.

On the other hand, it would be undesirable to have issues opened on this repo from users saying "STL doesn't work", or users trying to install STL through ProtonUp-Qt and it doesn't work, so they just abandon it and can't use STL.

Though I still think it's a bit of a less-than-ideal approach, we could add a list of all the hard dependencies into the description. That way users can install it themselves - If they were missing the dependencies when running normally, they'd have to install them on their own. This way, we're telling users in the description of the ctmod what dependencies they need. Perhaps something along the lines of:

SteamTinkerLaunch is [...]

If you're not on Steam Deck, ensure you have the following dependencies installed. (On Steam Deck, these are installed for you by SteamTinkerLaunch):

• Dependencies list goes here

Thanks for all the patience over the last week. Your input has been vital, and hopefully this should be ready soon 🙂

[sonic2kk]

PR is up!!!! I think further discussion should take place there 😄

[frostworx]

(steamtinkerlaunch author here)

Wow, thank you both @DavidoTek and @sonic2kk for the implementation and excellent collaboration! You rock! ❤👍

[brendenhoffman]

Great work guys!

[BioIron]

I did not understood much of what was going on, but it was a joy to follow through it this last week .
Nice work!

[sonic2kk]

Woohoo! This was just merged into main with 7ce49a5! Hope this turns out to be a useful addition, it was a lot of fun getting to contribute. Huge thanks to everyone here, the positive feedback here after the PR was opened was super encouraging 😃 You're all awesome!

I hope anyone that uses the source finds it as useful as I did during tests on my Steam Deck. Happy tinkering!

[DavidoTek]

Yes, I too think it is a very useful addition for ProtonUp-Qt and was lots of fun. Thanks for all you support! 🥳

It's currently available in the AppImage release over here, a Flatpak update will follow soon.

---

@everyone Feel free to do some testing and report any bugs/issues below.

[DavidoTek]

Won't Steam recognize the command if it's on the system's path?

Steam should recognize the path after a re-login or reboot.

I've released a new version, the SteamTinkerLaunch installer should work now: https://github.com/DavidoTek/ProtonUp-Qt/releases
I have also updated the Flatpak.

[outerwinnie]

The installation is stuck at 99% on the Steam Deck (flatpak):
https://i.ibb.co/C5PYtgh/IMG-20220924-042711.jpg

[BioIron]

The installation is stuck at 99% on the Steam Deck (flatpak): https://i.ibb.co/C5PYtgh/IMG-20220924-042711.jpg

Same problem here. Left the Deck installing STL for an hour but it wouldn't pass from "Extracting... 99%".

[tannertechnology]

When running ProtonUp-Qt 2.7.4 appimage I get this error in the console attempting to install steamtinkerlaunch:

could not convert string to float: '0.40.0'

It never appears to attempt to begin downloading. I'm running steam native on Kubuntu. Same occurs if I pick the git or regular versions.

Edit: definitely has to do with yad. My yad version is 0.40.0.

Edit: Resolved by removing the system yad and building per the docks: https://github.com/v1cont/yad#building-git-version

[DavidoTek]

You probably installed ProtonUp-Qt from the Discover app store, right? Can you @outerwinnie @BioIron open the Konsole app on the Deck and type following line:

flatpak run net.davidotek.pupgui2

Can you then send me the output text it shows when trying to install SteamTinkerLaunch?

[DavidoTek]

could not convert string to float: '0.40.0'

The code cannot handle version numbers with two decimal points. Fixed.

Edit: Resolved by removing the system yad and building per the docks

Yes, version 0.40.0 is too old, version 7.2 is the minimum requirement.

[outerwinnie]

flatpak run net.davidotek.pupgui2

Yes, i install it from the Discover app store. Here you have the output text:

Downloading SteamTinkerLaunch...
Extracting SteamTinkerLaunch...
Removing SteamTinkerLaunch installation...
Removing SteamTinkerLaunch from path...
Successfully uninstalled SteamTinkerLaunch!
Setting up SteamTinkerLaunch...
Sat Sep 24 05:01:15 PM CEST 2022 INFO - CompatTool - Creating symlink '/home/deck/.local/share/Steam/compatibilitytools.d/SteamTinkerLaunch/steamtinkerlaunch' pointing to '/home/deck/stl/prefix/steamtinkerlaunch'
Sat Sep 24 05:01:16 PM CEST 2022 INFO - main - No arguments provided. See 'steamtinkerlaunch --help' for possible command line parameters
Adding SteamTinkerLaunch to shell paths...
[Errno 2] No such file or directory: '/home/deck/.config/fish/fish_variables'

[sonic2kk]

Uh oh, looks like the check for writing to fish is wrong. It's only meant to be written to if that file exists but maybe the check needs adjusted (though it worked on my deck before without fish during development...)

[BioIron]

You probably installed ProtonUp-Qt from the Discover app store, right? Can you @outerwinnie @BioIron open the Konsole app on the Deck and type following line:
all
flatpak run net.davidotek.pupgui2

Can you then send me the output text it shows when trying to install SteamTinkerLaunch?

I had installed STL from Discover app indeed, but i uninstalled it soon after. I did not try to install the STL from protonup while the Discover app one was installed too (if that helps with anything).
Anyways, i pasted the command on konsole, and after a long column of percentages, this appeared:

100%  153M=23sSat Sep 24 07:06:38 PM CEST 2022 INFO - CompatTool - Creating symlink '/home/deck/.local/share/Steam/compatibilitytools.d/SteamTinkerLaunch/steamtinkerlaunch' pointing to '/home/deck/stl/prefix/steamtinkerlaunch'
Sat Sep 24 07:06:43 PM CEST 2022 INFO - main - No arguments provided. See 'steamtinkerlaunch --help' for possible command line parameters
Adding SteamTinkerLaunch to shell paths...
[Errno 2] No such file or directory: '/home/deck/.config/fish/fish_variables'

[sonic2kk]

I had installed STL from Discover app indeed, but i uninstalled it soon after

Just in case you aren't aware as a few people that have left reviews aren't, STL from Discover is for Flatpak Steam. It says so on the page too. ProtonUp-Qt will install SteamTinkerLaunch for regular Steam (which is what the Steam Deck uses)

Also the long percentages output is likely for SteamTinkerLaunch downloading all its dependencies, which only happens on Steam Deck.

[DavidoTek]

Uh oh, looks like the check for writing to fish is wrong

Probably caused by this line:

ProtonUp-Qt/pupgui2/resources/ctmods/ctmod_steamtinkerlaunch.py

Line 293 in d0b08b5

if os.path.exists(constants.STEAM_STL_FISH_VARIABLES) or host_which('fish'):

or should be replaced by and. Actually, the second part can be omitted. I will test and patch it.

UPDATE: Patched, 6919131

[DavidoTek]

I guess this can be closed now.

Added support for installing Steam Tinker Launch with v2.7.5, few bug fixes and improvements will be available in v2.7.6.

[sonic2kk]

I agree, thanks for allowing support and the awesome collaboration 🎉 Hoping to be able to give back a bit to other parts of ProtonUp-Qt as well going forward, I'll keep my eye out for anything I can contribute to 😉

[BioIron]

I can confirm, with more than an emote now, than i had successfully installed STL without any issue in my Deck.
Until this recent update, STL installation still got stuck on 99%, but after closing ProtonUp, it would appear on the compatibility list as if there wasn't any problem.
I reinstalled it now with the new update, and it went right to 100% with no weird install issues.
Thanks for your work :)