[FEATURE] Adding Steam Tinker Launch to possible downloads

[IC3P3]

Is your feature request related to a problem? Please describe.
I would like to add Steam Tinker Launch to start it through Steam without installing it manually.

Describe the solution you'd like
Adding builds of Steam Tinker Launch to ProtonPlus

Describe alternatives you've considered
No

Additional context
Steam Tinker Launch can be used for many things like configuring MangoHUD, adding Shaders and more. Here is a link to the project.
https://github.com/sonic2kk/steamtinkerlaunch

[Vysp3r]

It was on my to-do list already, but I will use this issue for any updates on that.

[Arcitec]

It really is sad that this gorgeous ProtonPlus application can't manage SteamTinkerLaunch, since that's the primary reason I'm enjoying Linux gaming: Being able to set a default Steam configuration in STL, with things like FSR enabled, PULSE_LATENCY_MSEC=30 to fix crackling audio in all games, enabling various environment variables globally, globally configuring my DPI so that game dialog boxes render at the correct screen scale, etc. And as soon as I run a new game, it just works immediately thanks to SteamTinkerLaunch's config being applied to it automatically.

For reference, ProtonUp-Qt supports SteamTinkerLaunch install from tagged releases and git development. That's what I'm using for managing STL.

The primary implementation is here:

https://github.com/DavidoTek/ProtonUp-Qt/blob/main/pupgui2/resources/ctmods/ctmod_steamtinkerlaunch.py

There are also some other files here:

https://github.com/search?q=repo%3ADavidoTek%2FProtonUp-Qt%20steamtinkerlaunch&type=code

The remove_steamtinkerlaunch() method here seems interesting too:

https://github.com/DavidoTek/ProtonUp-Qt/blob/main/pupgui2/steamutil.py

[Vysp3r]

@Arcitec I will look into it to know how much work it would be and if it's not too much I will consider working on that.
I will check tomorrow morning.

[Arcitec]

@Vysp3r Hi. :) Honestly, take as much or little time as you want, and if it's too much work, don't bother. :) There's no pressure. I know how it feels to make projects as a hobby. But I would definitely love to switch to your very beautiful application if it becomes possible.

[Vysp3r]

I just finished the dependencies verification.

[Vysp3r]

I just finished adding a verification to know if there's an install of STL which was not installed by ProtonPlus.

[Arcitec]

@Vysp3r Dude, woah! You are shocking me. This is super impressive. I thought you might at most do an installer that fetches the code, but you're even implementing the dependency checks and previous version detection. I am completely in shock. You are amazingly talented. I think ProtonPlus is already one of the most beautiful and well-designed applications on Linux. And this is the cherry on top that lets it replace ProtonUp-Qt. :O

[Vysp3r]

I just finished adding a way to add STL to your PATH if it's a new install or an install that was not made by ProtonPlus or ProtonUp-Qt.

[Vysp3r]

I was able to install STL with ProtonPlus just now!
All that's left to do is the code to remove STL and test everything.
(So around 25% left)

[Arcitec]

Oh my god this is incredible. Thank you thank you thank you. ProtonPlus is so beautiful and easy to understand that I will proudly recommend it to friends and family. :)

I'll tag @sonic2kk to let him know that https://github.com/sonic2kk/steamtinkerlaunch?tab=readme-ov-file#how-do-i-install-it can soon have a new member. :)

[Vysp3r]

The first implementation will be rough since I had to really mess around my code to make it, because of the way the application was originally made.
After I push the update with STL I will take some time to rework the backend, because otherwise this will make it really hard for me to maintain if I keep adding edge cases like that.

[Arcitec]

@Vysp3r Totally understandable! :) Thanks again for the great work! If you want me to compile the Flatpak locally to test out the changes and provide reports if there's any issues, just be sure that your latest work exists on a branch here and I'll get on it and test!

[sonic2kk]

Thanks for the work on this! Please tag me again once this is merged and available (even in a nightly is fine) and I can update the relevant docs. If you'd like, feel free to open an issue on the SteamTinkerLaunch repo requesting it once available so it stays in my mind :-)

From what I can tell here this supports SteamTinkerLaunch releases and SteamTinkerLaunch from git, the latter of which is the recommended way to use the project, as stable releases are always behind (the current is from March 2023). Since it is a script there is no need to use stables.

As another note, myself and the maintainer of ProtonUp-Qt contributed the SteamTinkerLaunch support, and I keep an eye on the integration and bug reports there. I also contribute to ProtonUp-Qt. I won't be able to do this here so apologies in advance, but please feel free to open issues on the SteamTinkerLaunch repository if a change on that side ever breaks something here. I just may not be able to help out with the specifics of this project the same way I might be able to do with ProtonUp-Qt.

I am surprised, very pleasantly surprised, to see positive reception to this here, given the negativity and borderline hatred online that surrounds SteamTinkerLaunch. It is motivating :-) I appreciate the work put in here.

[Arcitec]

@sonic2kk

Hey, great to hear from you Eamonn. You will always be a hero in my eyes for stepping up when STL needed help. :)

From what I can tell here this supports SteamTinkerLaunch releases and SteamTinkerLaunch from git, the latter of which is the recommended way to use the project, as stable releases are always behind (the current is from March 2023). Since it is a script there is no need to use stables.

The code I've seen so far is based on the GitHub /releases list, just like all other tools that ProtonPlus manages. It fetches the latest list of releases, shows a list of all tagged releases, and to download a version it fetches the tarball URL in that GitHub release, such as:

https://github.com/sonic2kk/steamtinkerlaunch/archive/refs/tags/v12.12.tar.gz

That's a reasonable solution without having to write a Git "master/commit" based download system, since practically all projects use release tags, even script-based ones.

I wonder... would it be okay to start tagging releases in SteamTinkerLaunch with the simplest possible method? As follows:

• After any particularly important feature or fix, create a Git tag with date-based version number. This is typically done for live-development projects like STL, where the main branch is reasonably stable and doesn't contain broken WIP-commits. So for example, today's tag would be v2024.09.02 (YYYY-MM-DD).
• No need for any release notes or anything else. Just uploading the tag is enough for ProtonPlus to see that source code version. Plenty of projects do tagging without release notes, so that GitHub creates a record and a downloadable URL.
• Tagging could probably even be totally automated via GitHub actions, like "tag on the 1st day of each month". And then there's no need to do anything unless a particularly important change happens mid-month.
• One possible idea would be to have a GitHub action hook "on commit" to the main branch, which auto-checks the latest active tag, splits it v2024.09.01 -> v2024.09, and compares it against the current month (such as v2024.10). If no match, auto-create a tag for the current day (such as v2024.10.09). This way, it would automatically create one single tag for the first code change each month, and it would not tag anything if there's no changes.
• That would be a hands-off system where no manual tagging is needed unless there's a particularly important change/fix. :)
• Edit: I found a GitHub actions script which automatically creates a tag based on the contents of a file you specify. So you could put a file in the repo named version, and inside put a value such as v2024.10.03. Then the action will automatically tag the project when a push happens with a new value inside the version file: https://github.com/marketplace/actions/generalized-automatic-tags

As another note, myself and the maintainer of ProtonUp-Qt contributed the SteamTinkerLaunch support, and I keep an eye on the integration and bug reports there. I also contribute to ProtonUp-Qt. I won't be able to do this here so apologies in advance, but please feel free to open issues on the SteamTinkerLaunch repository if a change on that side ever breaks something here. I just may not be able to help out with the specifics of this project the same way I might be able to do with ProtonUp-Qt.

Hmm. Since the compatibilitytools.d directory is standardized, I am guessing that the only real thing that might change over time is the list of SteamTinkerLaunch's core dependencies.

I have a suggestion there. Would it be possible to have a static text-file named something like dependencies.essential.txt and list them there, so that ProtonPlus can read that file to detect the required dependencies?

At the moment, even ProtonUp-Qt has hardcoded the dependency list. It would be more structured if that list exists in STL's repo itself. These are the current dependencies that ProtonUp-Qt hardcodes:

https://github.com/DavidoTek/ProtonUp-Qt/blob/bb1a50966191cb2f855c27ea6322394dd0d60d36/pupgui2/resources/ctmods/ctmod_steamtinkerlaunch.py#L176-L199

It could be listed in a format similar to Python requirements.txt. So something like this:

awk || gawk
git
pgrep
unzip
wget
xdotool
xprop
xrandr
xxd
xwininfo
yad >= 7.2

Which means: awk or gawk must exist (either is fine), the other tools must exist, and yad must exist and have a --version >= 7.2.

I am surprised, very pleasantly surprised, to see positive reception to this here, given the negativity and borderline hatred online that surrounds SteamTinkerLaunch. It is motivating :-) I appreciate the work put in here.

I have seen that hatred so often in the open source community and suffered a lot of it myself. People think that you owe them something and they are so happy to dump feature requests on you, but very few contributors. And when something isn't exactly as they want it to be, they'll often start becoming really rude. Especially the "ping ping ping ping hey ping ping come on do it ping ping ping" people.

My recommendation, if you have such people in your community and issue tracker, is that you actually ban them from the project. Their attitude is not helpful at all and you deserve better.

Thank you so much for your work on SteamTinkerLaunch. It's seriously an incredible tool and your continued development has made it even better.

[sonic2kk]

I wonder... would it be okay to start tagging releases in SteamTinkerLaunch with the simplest possible method? As follows:

I think this is possible, although SteamTinkerLaunch is probably best used by just updating from master. Similar to what is possible with Winetricks' --self-update. I want to introduce something like this into SteamTinkerLaunch, although I am not sure of a good way to implement it when installed as root, and would not want to disturb managed installs like those from package managers or projects like ProtonPlus.

There will be at least one more SteamTinkerLaunch "release", likely called v14.0, after that I can consider possible go-forwards for how to create tags. ProtonUp-Qt uses a master-based download option for SteamTinkerLaunch, which just uses the URL https://github.com/sonic2kk/steamtinkerlaunch/archive/master.tar.gz (it goes through some other steps to build that, the logic is caught under self.allow_git). The rest of the install flow is the same, the target URL is all that changes.

I am not sure if such a solution is feasible here, these are two entirely separate projects, I perfectly well understand that just because they may appear to solve similar problems that does not mean they work exactly the same and each have different architectural constraints.

If this cannot be done, and tagging is quite strongly preferred, then after v14.0 I think an open discussion on the SteamTinkerLaunch repo would be good. We can open the floor and come up with something that benefits as many integrations as possible.

I have a suggestion there. Would it be possible to have a static text-file named something like dependencies.essential.txt and list them there, so that ProtonPlus can read that file to detect the required dependencies?

At the moment, even ProtonUp-Qt has hardcoded the dependency list. It would be more structured if that list exists in STL's repo itself. These are the current dependencies that ProtonUp-Qt hardcodes:

SteamTinkerLaunch itself also uses a hardcoded dependency list :-) If the project were to introduce such a list, it would currently only be available in the latest master, and would not apply to previous tagged releases, so both ProtonPlus and ProtonUp-Qt, and any other application that can download SteamTinkerLaunch, would likely still need to maintain a hardcoded list. I don't see using previous releases as a common thing that users would do, but it's worth mentioning.

My other concern would be that, if this was introduced, I would like this to be something that could be utilitsed broadly. Is there a "standard" for this that, say, package maintainers could hook into as well? Of course packages manage their own dependency files, what I mean is, if this were introduced, I would like this to be as useful as possible, and getting it right means the structure and location of the file won't have to change. If this was ever changed to a new format, it would be a mess for anything like ProtonPlus to handle all the different revisions of, and I want to avoid such a thing! The requirements.txt is one example, but there are others. People will all have their own opinions but if there is a good template to follow I'd like to do that to make it as straightforward as possible for other parties.

Perhaps this is something best opened on the SteamTinkerLaunch repo to involve the community in the discussion. I'm grateful for anyone that puts in the time and work to integrate with SteamTinkerLaunch, and I try to be as mindful and as helpful as possible to anything downstream to make their lives easier (when I was working on the SteamTinkerLaunch integration for ProtonUp-Qt initially, it was a bit more restricted, as I wasn't the project maintainer back then).

I have zero problems introducing such a list, I want to make that clear, this isn't a rejection! This is basically 1) A hardcoded list may still need to be maintained, and 2) If this is introduced, I want to make sure it's done right, to fit any standards, and to be as useful and easy as possible for anything integrating with SteamTinkerLaunch that may care about its dependencies.

---

I don't want to derail this issue too much, apologies if I already have, but I welcome all thoughts on anything I can do to make things easier here. And once again, thanks for the kind words :-)

[Vysp3r]

I only need to code the part to remove what I added to shell files when you want to remove STL.

[Vysp3r]

I haven't tested every possible cases, but I am able to install, uninstall, upgrade and downgrade on my end without having any issues.

@Arcitec I'll let you test on your end before merging like you proposed just to make sure I didn't miss anything.

[Vysp3r]

I just thought about it, but I forgot to fix the progress bar.
I'll do when I am home, but overall it should still work so you can still test.

[Arcitec]

@Vysp3r @sonic2kk

Hey. I read your full responses and agree that we should talk about auto-tagging and requirements.txt in the STL repo after this.

• Regarding release tags, I've done more research and saw that auto-tag + auto-release are indeed totally doable via GitHub actions, where it's pretty easy to script those actions.
• As for requirements.txt, I am not aware of any format that would allow us to say "they need awk OR gawk", but other than that, Python's requirements.txt format would work well, which is why I based it on that but with the || "OR" operator. But there might be another format that can specify this a better way. That's something we can discuss and research in more detail at STL's repo later if it becomes necessary. However, you're totally right that I forgot about the situation with older versions of STL which won't contain the dependency list, so it's definitely a tricky question to solve. It might be semi-solvable by doing something like "fetch the latest, raw dependency list from the development repo if nothing existed in the downloaded version archive". But maybe it's all overkill, in case the core dependencies of STL almost never changes?

For now, I've been doing research into GitHub's APIs and query parameters to come up with two ways to fetch the latest Git version of STL WITHOUT embedding a full Git client into ProtonPlus. If this solution works for @Vysp3r then there would be no need for consistent version/release tagging.

Here is the code. Put this in a Python script and run it to see the result of both methods.

My idea is that ProtonPlus could do the following:

• Do one of these queries (probably method 2 since it provides a better user experience).
• Compare the full_hash variable to a stored, internal "currently installed hash" (which would only exist if STL has currently been installed in this Git Hash mode by ProtonPlus).
• If different, show a new dropdown menu item in ProtonPlus: "Steam Tinker Launch: Git 2024-09-03 (49743db); ✔️ Git 2024-08-10 (8756dc8)", where the ✔️ represents the currently installed version from Git, and the entry above it only shows the latest detected Git hash via the methods I proposed. So there would only ever be two Git-version entries: The latest. And the currently installed (if any).
• If the user clicks such a "Git" entry, use the download_url variable to fetch and unpack the new archive.

from datetime import datetime
from urllib.request import Request, urlopen
import json


# Method 1: Just the latest hash, no metadata.

STL_UPDATE_CHECK_URL = (
    "https://api.github.com/repos/sonic2kk/steamtinkerlaunch/commits/master"
)

# NOTE: The "Accept" header is important. It tells GitHub to give us the commit
# hash and nothing else. Otherwise they'll send a JSON object containing the
# entire patch diff, which they say "can be slow and may even time out":
# https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#get-a-commit
req = Request(STL_UPDATE_CHECK_URL)
req.add_header("Accept", "application/vnd.github.sha")
req.add_header("X-GitHub-Api-Version", "2022-11-28")

with urlopen(req) as f:
    full_hash = f.read().decode("utf-8")
    short_hash = full_hash[:7]

    # NOTE: ".zip" is GitHub's preferred URL. The ".tar.gz" suffix works too,
    # but includes some extra dummy file, so it's less ideal.
    title = f"Git {short_hash}"
    download_url = (
        f"https://github.com/sonic2kk/steamtinkerlaunch/archive/{full_hash}.zip"
    )

    print("Method 1: Grab Latest Hash")
    print(f"Internal ID: {full_hash}")
    print(f"Version Title: {title}")
    print(f"Download URL: {download_url}")


# Method 2: Latest hash with all metadata.

STL_UPDATE_CHECK_URL = (
    "https://api.github.com/repos/sonic2kk/steamtinkerlaunch/commits?per_page=1"
)

# By not specifying a "?sha=" parameter, it automatically checks the default branch.
# And since we set "per_page" to 1, we don't waste time fetching older commits.
# This API doesn't include diffs in the result, so there's no risk of timeouts.
# https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits
req = Request(STL_UPDATE_CHECK_URL)
req.add_header("Accept", "application/vnd.github+json")
req.add_header("X-GitHub-Api-Version", "2022-11-28")

with urlopen(req) as f:
    data = json.loads(f.read().decode("utf-8"))
    assert len(data) >= 1, "No results."

    # Get the latest commit.
    commit = data[0]

    full_hash = commit["sha"]
    short_hash = full_hash[:7]

    # NOTE: The date is in ISO 8601 format: `YYYY-MM-DDTHH:MM:SSZ`.
    # NOTE: The "Z" at the end stands for "Zulu" aka UTC time (UTC+00:00).
    commit_date = datetime.strptime(
        commit["commit"]["committer"]["date"], "%Y-%m-%dT%H:%M:%SZ"
    ).strftime("%Y-%m-%d")

    # NOTE: ".zip" is GitHub's preferred URL. The ".tar.gz" suffix works too,
    # but includes some extra dummy file, so it's less ideal.
    title = f"Git {commit_date} ({short_hash})"
    download_url = (
        f"https://github.com/sonic2kk/steamtinkerlaunch/archive/{full_hash}.zip"
    )

    print("\nMethod 2: Grab Full Metadata")
    print(f"Internal ID: {full_hash}")
    print(f"Version Title: {title}")
    print(f"Download URL: {download_url}")

What do you think of this idea?

PS: I'll start testing the in-development version in ~1 hour. I've got an appointment right now. Testing after that may take up to some hours since I'll be trying it with both Flatpak Steam and Native Steam and doing various tests. :)

Edit: A simpler way to extract the date is in this other comment. I recommend using that method instead of parsing the date!

[Vysp3r]

FYI I didn't test STL itself to see if it was working after being installed with ProtonPlus
I just checked to see if it was catched by Steam and if the downgrade upgrade was reflected in the symlink

[Arcitec]

FYI I didn't test STL itself to see if it was working after being installed with ProtonPlus

Alright, I will be testing the Flatpak and Native Steam now, and making sure that STL works in both! :)

I just began testing now, because a lot of time was wasted trying to build the Flatpak until I finally realized that the manifest inside the repo is outdated. I grabbed the latest from Flathub to successfully build it:

https://github.com/flathub/com.vysp3r.ProtonPlus/blob/master/com.vysp3r.ProtonPlus.json

And just changed its git source to point at the wip branch.

Apart from that issue, the "3. Install the needed runtimes for flatpak" step in the readme uses outdated runtime install names that can't find the runtimes these days.

Now the local build is working and I'll be testing everything! I'm testing Flatpak first. Then I'll migrate all my Steam compatdata and games to native Steam and test that too.

Should have the results within 2 hours.

PS: Any thoughts so far about the Git downloader idea from #166 (comment)?

[Arcitec]

Early result worth mentioning to hear your thoughts:

Test: Flatpak Steam. SteamTinkerLaunch already installed as Utility managed by Flatpak from https://github.com/flathub/com.valvesoftware.Steam.Utility.steamtinkerlaunch

ProtonPlus cannot see that it's installed, but the files can be seen inside the sandbox:

$ flatpak run --command=bash com.valvesoftware.Steam

[📦 com.valvesoftware.Steam ~]$ ls /var/data/Steam/compatibilitytools.d
SteamTinkerLaunch
[📦 com.valvesoftware.Steam ~]$ ls ~/.local/share/Steam/compatibilitytools.d
SteamTinkerLaunch

My suspicion is that the "Flatpak Container Disk Layer" that contains STL is not visible to ProtonPlus in the location where it analyzes Flatpak Steam's data.

But strangely enough, STL is actually visible outside the sandbox too (this command was ran on the host):

 ~ $ ls ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/compatibilitytools.d
SteamTinkerLaunch

And also tested the `data` dir which is what ProtonPlus has in its filesystem permissions. It's a symlink to the above.

 ~ $ ls ~/.var/app/com.valvesoftware.Steam/data/Steam/compatibilitytools.d
SteamTinkerLaunch

This edge case is not really important though. If installed as a Flatpak component, STL updates itself via regular Flatpak updates.

I will now clean up the Flatpak variant of STL and start using ProtonPlus to install it.

Edit: Wait, I think that was a false alarm? If I click "Installed Only", it seems to detect it. I just didn't see any "uninstall" icons UNTIL I had clicked "Installed Only" first. My mistake, I guess?

[sonic2kk]

@Arcitec I'm not sure I understand why something that complex is necessary, apologies if I'm getting the wrong end of the stick here.

While I agree implementing some kind of Git client is overkill, it seems like this is getting as granular as downloading specific commits. That shouldn't be necessary, it should be possible to just point to the latest SteamTinkerLaunch master branch. This can be done with https://github.com/sonic2kk/steamtinkerlaunch/archive/master.zip. (or .tar.gz, if preferred, GitHub offers both). Since SteamTinkerLaunch does not package a release archive, just the source code archive offered by default when you make a release on GitHub.

However you might want to fetch the GitHub branches for the project and allow those as "versions," default to the master branch. This is what I did for the ProtonUp-Qt integration. You can get the branches with the https://api.github.com/repos/sonic2kk/steamtinkerlaunch/branches endpoint. The download URL then becomes the same as the one for master, but using the branch name instead. For example, to download from a branch called super-cool-feature, the URL becomes https://github.com/sonic2kk/steamtinkerlaunch/archive/super-cool-branch.zip.

In ProtonUp-Qt, we can treat branch names essentially like tags. In fact when building the download data, we take a tag argument, and for SteamTinkerLaunch-git we just give it a branch name. Something along these lines could make integration easier.

So I don't think going as far as implementing specific hashes is necessary, only the latest commit to master is supported for SteamTinkerLaunch at any given time. For troubleshooting it could be useful to bisect to specific commits, but that is potentially out of scope for tools like this.

This could be a misunderstanding on my part, stemming from unfamiliarity with the context here of ProtonPlus, so sorry if that makes no sense in the context of this project 😅

[Arcitec]

@sonic2kk

This could be a misunderstanding on my part, stemming from unfamiliarity with the context here of ProtonPlus, so sorry if that makes no sense in the context of this project 😅

Hehe yeah you've misunderstood, but it's no worries. 😄

The way ProtonPlus works is that it provides a list of detected versions and allows the user to click a version to download it. If we just grab "master.zip" we would never know when there is an update.

The code I provided above will query GitHub's APIs, find the newest commit, and treat that as a version, complete with a nice title and date and the download URL for that exact "version" (commit). It's like downloading master.zip but allows us to have "there is an update"-detection.

If that algorithm can be added to ProtonPlus, the update problems / release tagging situation would be solved. There wouldn't be any need to have tagged releases in STL's repo.

[Arcitec]

Next test result, also highly worth mentioning:

Test: Flatpak Steam. SteamTinkerLaunch NOT installed as a com.valvesoftware.Steam.Utility.steamtinkerlaunch Flatpak component.

• ProtonPlus offers to install it.
• It correctly checked if the Flatpak environment (rather than the host) contains the necessary tools.
• And then it realizes that dependencies don't exist inside the Steam Flatpak:

This made me wonder how the Flatpak component solved the issue, so I looked at the manifest:

https://github.com/flathub/com.valvesoftware.Steam.Utility.steamtinkerlaunch/blob/master/com.valvesoftware.Steam.Utility.steamtinkerlaunch.yml

And there it was... A long list of binary component modules, such as yad.

Conclusion: The dependency situation inside the Flatpak version of Steam means that the only way to install SteamTinkerLaunch for it is via flatpak install com.valvesoftware.Steam.Utility.steamtinkerlaunch. Therefore, ProtonPlus should not attempt to install it for Flatpak Steam.

• So let's add something that blocks ProtonPlus from managing the Steam Flatpak version of STL.
• It could still display the STL install/uninstall buttons for Flatpak Steam, but as soon as the user clicks install/uninstall for STL, it should do nothing, and instead pop up a dialog that tells the user what to do.
• The popup could say something like this:

"The Flatpak version of Steam requires extra Steam Tinker Launch dependencies which cannot be managed by ProtonPlus.

To install Steam Tinker Launch for the Steam Flatpak, please run the following command:

flatpak install --user com.valvesoftware.Steam.Utility.steamtinkerlaunch"

This is a totally acceptable situation, since Flatpak Steam already has the package above which installs and keeps SteamTinkerLaunch updated automatically. It's the only solution for Flatpak Steam since I can't think of any way for ProtonPlus to add the dependency binaries to Steam's Flatpak.

Alright... Now, it's time for me to move all my games/library/compatdata to native Steam instead (I am leaving Flatpak for many reasons, such as no VR support, various launcher bugs with the Flatpak itself where it often double-launches two Steam copies, etc). Then I'll install and test STL via ProtonPlus for Steam Native!

[Vysp3r]

The dependency check is done on the system itself and not Flatpak to my knowledge.
I had to install and remove them from my system to test if that was working.
I run the application with Flatpak when I develop.

[Vysp3r]

I will need to check for Steam snap if it's working, because I don't know if it works the same way as Flatpak.

[Arcitec]

The dependency check is done on the system itself and not Flatpak to my knowledge.
I had to install and remove them from my system to test if that was working.

That's strange, since I definitely have every dependency on the host:

 ~ $ which awk
/usr/bin/awk
 ~ $ which gawk
/usr/bin/gawk
 ~ $ which git 
/usr/bin/git
 ~ $ which pgrep
/usr/bin/pgrep
 ~ $ which unzip
/usr/bin/unzip
 ~ $ which wget 
/usr/bin/wget
 ~ $ which xdotool
/usr/bin/xdotool
 ~ $ which xprop  
/usr/bin/xprop
 ~ $ which xrandr
/usr/bin/xrandr
 ~ $ which xxd   
/usr/bin/xxd
 ~ $ which xwininfo
/usr/bin/xwininfo

But they don't exist inside Flatpak ProtonPlus and not inside Flatpak Steam.

However, I can see that your code looks correct (flatpak-spawn --host which <bin> is correct).

Either way, the current situation is as follows:

• Flatpak Steam's STL is not manageable by ProtonPlus since that version requires the dependencies to exist inside the Steam Flatpak environment, so the only way to solve that is via flatpak install --user com.valvesoftware.Steam.Utility.steamtinkerlaunch.
• Therefore, let's block attempts to manage Flatpak Steam's SteamTinkerLaunch via ProtonPlus.
• ProtonPlus should be checking the host's dependencies, and managing STL for the host (which uses the host's binaries).
• Snap (which I didn't even remember existing) is probably exactly the same. I remember working on Snaps 2 years ago and they contain a sandbox too, just like Flatpak. I don't think they use any host binaries.
• I will take some time now to move all Steam data to the host and then run installation/uninstall/usage tests on native Steam. :) Which is really where ProtonPlus is truly needed, since the Flatpak Steam already has the easy STL component anyway.

[Arcitec]

That's awesome since I don't have a steam deck, but as long as the base path becomes ~/stl/prefix for Steam Deck, it will work. :)

[Arcitec]

Wait, no! You are right! There is a Steam Deck bug! :D Time for... drumroll... PR 13 (ffs). :)

Edit: It's up: https://github.com/Vysp3r/ProtonPlus/pull/216/commits

[Vysp3r]

Ahah, I will wait for your PR then I will test it then

[Arcitec]

@Vysp3r It's fixed 5 min ago, but I guess I should have said "it's ready" since we had some accidental early merges today hahah. :)

[Arcitec]

Have fun testing on Steam Deck. :)

I noticed a harmless leftover at the top of window.vala which you can fix:

        construct {
            //
            this.set_application ((Adw.Application) GLib.Application.get_default ());
            this.set_title (Constants.APP_NAME);
            this.set_default_size (950, 600); // <--- delete that line :)

Because now we set the set_size_request and set_default_size together a few lines below instead. I didn't see that there was a call to that already at the top of the file, which now does nothing, so just delete it. 😅

[Vysp3r]

Done :)

[Arcitec]

After you test things on your end, the only remaining checklist would be this:

• Don't warn about missing dependencies on Steam Deck? (Edit: Steam Deck has everything except Yad, and STL downloads that itself. So no, don't check deps on Steam Deck.)
• Check if exec_stl (binary_location, ""); is the correct way to trigger dependency downloads on Steam Deck. (Edit: Yes, it is. That command triggers it to silently download dependencies.)
• Enable Swedish for Weblate in the LINGUAS file.
• Include Swedish in the repo.
• Steam Deck testing.
• Push to main branch.
• Wait for me to translate to Swedish.
• If you're the author of any translations, you should review and refresh those too (punctuation, remove surrounding whitespace, add %s, merge sentences, possibly change some words). Other authors will have to do it in subsequent releases.
• Write some metainfo release notes (suggestion here).
• Edit com.vysp3r.ProtonPlus.yml manifest to set the new release tag as build target and tag a new release, maybe v0.5 for the new STL feature if you use semantic versioning. (Edit: Use the new script for this: ./scripts/set-version.py 0.5)
• Publish new Flatpak manifest com.vysp3r.ProtonPlus.yml to Flathub and delete their old XML one. They may wonder why you need host-spawn privileges now, but it's inevitable for this app which needs to run STL on the host. Similar privileges were given to another app I worked on, Cartridges, for the same reason.

[Vysp3r]

Out of subject but what the heck is this

I just saw when trying to install from my deck

[Arcitec]

Oh my god what a rude idiot. I see it too. I wonder if GNOME can remove such violating comments. It has literally nothing to do with your app and is total brainrot. 😆

Edit: I am clicking "Report" on that review in the GNOME store.

EDIT: LOL this review too:

[Vysp3r]

The most annoying thing about those comments is the fact that all he's doing in shitting on my application without even giving insightful feedback for me to improve on.
Like instead of creating an issue on GH to say what's wrong and should change you just shit on it, because it's not to your liking without thinking there's people that put effort into it.

[Vysp3r]

Yeah that review is stupid too since the application is not based on protonup lol

[Arcitec]

Yeah that review is stupid too since the application is not based on protonup lol

He's just on another level from us.

[Vysp3r]

I think I found an issue
If I remember correctly on the SD you don't have to do the dependency check since STL manage that
I will check ProtonUp-Qt code to confirm that

[Arcitec]

I think I found an issue
If I remember correctly on the SD you don't have to do the dependency check since STL manage that
I will check ProtonUp-Qt code to confirm that

Oh yeah that's right. I don't think we need any dependency checks on Steam Deck. I wish I could have tested on a Steam Deck.

But I did read the STL source code and it downloads yad into ~/stl/deps or something like that, and possibly other tools too, so it seems like it downloads everything it needs.

Just double check if ProtonUp does anything else. Edit: Turns out Steam Deck has everything except yad.

I think the easiest fix for Steam Deck without messing with the code is just to change this single line:

if (missing_dependencies != "") {

to:

if (missing_dependencies != "" && !Utils.System.IS_STEAM_OS) { // Steam Deck doesn't need dependencies.

Sure we could refactor stuff into some dependency check function and only call it if not Steam Deck, but tbh who cares, we always do these checks on PC, a Steam Deck won't suffer from some useless calls, and we end up with 0-line fix for Steam Deck. 😆

[Arcitec]

You reminded me that I never investigated this line:

                // Trigger STL's dependency installer for Steam Deck, and register compat tool.
                if (Utils.System.IS_STEAM_OS)
                    exec_stl (binary_location, ""); // <----- this line... is it necessary?

                exec_stl (binary_location, "compat add");

I assume the "call STL without any arguments" is what triggers it to download dependencies on Steam Deck. 99% sure. But best to double check if that's how ProtonUp triggers it.

Edit: Yes. Confirmed below.

[Vysp3r]

So far I found that

[Arcitec]

Perfect, I've marked that point as finished. Updated checklist: #166 (comment)

[Vysp3r]

Oh okay I found what we were looking for

FYI SteamOS seems to have every dep necessary by default except for yad

[Arcitec]

Awesome. And that explains why I only saw yad when I investigated the STL code a few days ago. :)

Then the only question is "refactor or the easy fix?".

[Vysp3r]

We can simply skip the check if on SteamOS and ensure we run the command to install yad

[Arcitec]

Yeah. In that case I'd suggest moving the dependency checks into an if-statement, actually. Easier to read than a refactoring into another function.

With a comment that // Steam Deck doesn't need any external dependencies. (Comments are for future development, always useful when coming back and wondering wtf is going on later, and for new contributors who tend to "fix bugs" aka "create bugs" when they don't understand the purpose of the code.)

Edit: We already run the command to install Yad btw. :)

[Vysp3r]

I just pushed the fix for that problem
Now what's next

[Arcitec]

Hmm release notes. You can check boxes here for reference:

#166 (comment)

[Vysp3r]

By the way do you have discord/telegram?

[Arcitec]

Edit: Sent

[Arcitec]

🥳 🎆

We are finally about to merge STL support to main. It will take some time for a public release after that, but anyone who builds from source can use it already!

#217