[FEATURE] Adding Steam Tinker Launch to possible downloads #166
Comments
|
It was on my to-do list already, but I will use this issue for any updates on that. |
|
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, 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: There are also some other files here: https://github.com/search?q=repo%3ADavidoTek%2FProtonUp-Qt%20steamtinkerlaunch&type=code The https://github.com/DavidoTek/ProtonUp-Qt/blob/main/pupgui2/steamutil.py |
|
@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. |
|
@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. |
|
I just finished the dependencies verification. |
|
I just finished adding a verification to know if there's an install of STL which was not installed by ProtonPlus. |
|
@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 |
|
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. |
|
I was able to install STL with ProtonPlus just now! |
|
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. :) |
|
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. |
|
@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! |
|
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. |
|
Hey, great to hear from you Eamonn. You will always be a hero in my eyes for stepping up when STL needed help. :)
The code I've seen so far is based on the GitHub
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:
Hmm. Since the I have a suggestion there. Would it be possible to have a static text-file named something like 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: It could be listed in a format similar to Python requirements.txt. So something like this: Which means:
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. |
I think this is possible, although SteamTinkerLaunch is probably best used by just updating from master. Similar to what is possible with Winetricks' 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 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.
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 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 :-) |
|
I only need to code the part to remove what I added to shell files when you want to remove STL. |
|
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.
|
|
I just thought about it, but I forgot to fix the progress bar. |
|
Hey. I read your full responses and agree that we should talk about auto-tagging and
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:
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! |
|
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)? |
|
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.steamtinkerlaunchProtonPlus cannot see that it's installed, but the files can be seen inside the sandbox: 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): 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?
|
|
@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 However you might want to fetch the GitHub branches for the project and allow those as "versions," default to the In ProtonUp-Qt, we can treat branch names essentially like tags. In fact when building the download data, we take a So I don't think going as far as implementing specific hashes is necessary, only the latest commit to 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. |
|
Next test result, also highly worth mentioning: Test: Flatpak Steam. SteamTinkerLaunch NOT installed as a
|
|
The dependency check is done on the system itself and not Flatpak to my knowledge. |
|
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. |
That's strange, since I definitely have every dependency on the host: But they don't exist inside Flatpak ProtonPlus and not inside Flatpak Steam. However, I can see that your code looks correct ( Either way, the current situation is as follows:
|
|
That's awesome since I don't have a steam deck, but as long as the base path becomes |
|
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 |
|
Ahah, I will wait for your PR then I will test it then |
|
@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. :) |
|
Have fun testing on Steam Deck. :) I noticed a harmless leftover at the top of 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 |
|
Done :) |
|
After you test things on your end, the only remaining checklist would be this:
|
|
Out of subject but what the heck is this |
|
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:
|
|
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. |
|
Yeah that review is stupid too since the application is not based on protonup lol |
He's just on another level from us. |
|
I think I found an issue |
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 Just double check if ProtonUp does anything else. Edit: Turns out Steam Deck has everything except 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. 😆 |
|
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. |
|
So far I found that |
|
Perfect, I've marked that point as finished. Updated checklist: #166 (comment) |
|
Oh okay I found what we were looking for |
|
Awesome. And that explains why I only saw Then the only question is "refactor or the easy fix?". |
|
We can simply skip the check if on SteamOS and ensure we run the command to install yad |
|
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 |
|
I just pushed the fix for that problem |
|
Hmm release notes. You can check boxes here for reference: |
|
By the way do you have discord/telegram? |
|
Edit: Sent |
🥳 🎆We are finally about to merge STL support to |
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
The text was updated successfully, but these errors were encountered: