-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Steam Deck Experience Improvements [Community Contributions Wanted] #859
Steam Deck Experience Improvements [Community Contributions Wanted] #859
Comments
SteamOS support may be pulled soon, I am not very interested in maintaining it in any official capacity, and apparently given 4 months of zero community interest, neither is anyone else. So this issue is less relevant than it was back then. But I will leave this open for a while longer in case someone wants to help. |
Updated to include information from #1046 (comment). |
I see 2 issues with STL on steam deck:
I can do some tests and helps if you need it on testing etc. |
If you mean in Desktop Mode, then you need to maximise the window. If you mean in Game Mode, this is bug with GameScope and not something I can fix.
It's worth noting as well that you can configure the config files manually, so if you really want to avoid the GUI, you can edit everything manually from a text editor. Then you can just let SteamTinkerLaunch load as normal in Desktop Mode (or Game Mode if you're using it there, which is probably not a good idea as it's prone to issues with graphical programs). SteamTinkerLaunch is a versatile tool, just because you only use it for these mysterious trainer programs doesn't mean others do. If someone designs and implements a use-case for such a feature with a good, detailed proposal, it can be discussed further, but I personally don't see the value in it, and that's not what this issue is for. On that note:
I appreciate it, but this issue is exclusively asking others to support SteamTinkerLaunch on SteamOS. I no longer use and will likely never again use SteamTinkerLaunch on SteamOS. This issue is detailing work that others should step up to do if they want to continue seeing SteamTinkerLaunch supported on SteamOS, as if they do not, I will no longer advertise support for nor give support to people on the platform. However it seems no one is interested, given that it has been close to a year. I will continue waiting until the 1 year mark, but after that, I will likely have to say goodbye to official Steam Deck support. No code will be removed but I cannot in good conscience advertise support for Steam Deck when I don't even test on it anymore. I shouldn't even be doing it right now, I'm just hoping someone will come forward to help and trying to hold out as long as possible, because I know people are going to be really pissed off when support is dropped. |
I can try to help on code but right now I am just interested on the trainer part. |
So I am trying to download the steamos image for steam deck and getting running on virtualbox: https://steamdeck-images.steamos.cloud/recovery/ I will let you know about the task to detect with bash if the system is a steam deck. I am thinking of a function that just return true if it is a steam deck. |
So right now 2 of the task here are in WIP. About yad the repo is in readonly right now, but yad is not archlinux https://archlinux.org/packages/extra/x86_64/yad/ so I think that we can do the same way for innoextract/cabextract. What do you think? This simplify a bit the release management. About the update dependency in my opinion the best way is just at every run of a new version, download again the dependencies in this way we are sure that they are always updated. |
New Yad AppImage was built and pre-released at sonic2kk/steamtinkerlaunch-tweaks/releases/Yad-fbfb0fa-x86_64.AppImage. PR is up to bump the Yad AppImage at #1077. |
Can we move the discussion for the Automatic update and automatic dependency check in a new ticket? I think that we can merge them and do that at every new update of STL everything gets updated at the first run of the new version. |
Sure, sounds good! Please remember though that all of this is specific to SteamOS.
Hm, we could do this. We should store the current version in We could easily parse this out of the file I think, not sure if we have a specific method to check this already. I suspect we do since STL can update the configs on version change. For automatic updates, that would only be shown for SteamOS. I don't know how all the conditional menu stuff that Frostworx implemented works, but probably, we could create a separate submenu for SteamOS options and just have the option there. Then by default we would put this at the top of the file. The problem is we'd need to add some kind of conditional to only show this on SteamOS. Maybe it could go under something like If you'd like, two separate tickets could be created, since implementing these requires very different and distinct work. |
I think that the first thing we can do is an automatic update checker at every new version if the dependency are installed by STL. Also you can create a label on github for steam deck stuff. |
I agree with the first part, but remember, dependencies are only managed on SteamOS. That is the only time we ever try to overstep for the user in this way, and it's because there is no easier way to get these dependencies on SteamOS because of the decision to make SteamOS immutable. On the subject of automatic dependency updates, I think we should have an internal variable to control this. Users can disable this from the config file if they're doing some specific dev work or are using STL downstream.
This is a big no, sorry. And actually, when considering my reply, I think we can remove automatic updating entirely. The only reason we had it before was when SteamOS support was in early stages and rapidly changing. At this point it's unlikely to change much. On the Linux Desktop, we should absolutely not do this. SteamTinkerLaunch should ideally be installed via package manager, and package maintainers should package a git version - Some maintainers only package git versions, like Pacstall. Having some kind of automatic updating would be dreadful, very few projects fit doing this, the only one I can think of is Winetricks. Software installation is best left to the package manager. Looking at other utilities off the top of my head that I use, they also do not do this when installed manually. They tell you when you try to build that dependencies are missing and it's up to you to get them. If this cannot easily be done, then that's where the package manager comes in. There's no need for us to become a package manager. SteamTinkerLaunch can be installed locally from ProtonUp-Qt, but you can just download again from ProtonUp-Qt to update in that case. ProtonUp-Qt also tells you the dependencies conveniently, they are on the wiki also but I also included them in the ctmod description. And ProtonUp-Qt should not be installing dependencies for tools for the same reason: It's not a package manager. It doesn't make sure you have all the Steam/Lutris/Bottles/Heroic dependencies, nor does it make sure you meet the dependencies for the tools you can use with these tools. I see no reason to implement automatic updating on the Linux Desktop, and having had time to think, no reason to implement it at all. I think it's fine to put the owness on the user to update. I hope I explained it in a clear way. Once automatic dependency updating is in place, we can strip out all the stuff related to STL updating itself. When we can check and update dependencies, installing a new version with newer pinned dependency versions should manage updating them, so no need for STL to also update itself. This will simplify all of the UI work too as a bonus. In hindsight, the SteamOS auto-updating thing was probably a bad idea. When I added it to this issue, it was to make it easier to disable, and now that I've thought some more, it makes more sense to remove it altogether. I'll score it out as a wontdo in this ticket.
Unless you're talking about something else, we already have this label. I appreciate the ideas you put forward, and I feel like disagreeing can come off as hostile, so I'm sorry if that's the case. |
So I tried with SteamOS for steamdeck on VM but as it is updated on 2022 doens't work pretty well and is impossible to update it on VM. So right now I am not able to test a steamdeck in a VM. |
Arch Linux will not simulate SteamOS development. SteamTinkerLaunch has to do specific checks for SteamOS that aren't present on vanilla Arch. SteamOS is based on Arch but it is entirely different. I use Arch on my PC, that's what I develop SteamTinkerLaunch on, and it does not simulate SteamOS at all. Also, installing SteamTinkerLaunch on an Ubuntu VM is probably not a great experience if you use ProtonUp-Qt because Ubuntu does not package an up-to-date Yad. You're much better off installing SteamTinkerLaunch via Pacstall. You should only use ProtonUp-Qt to install SteamTinkerLaunch if you already have Yad installed or if you cannot get SteamTinkerLaunch from your package manager. |
Ok I will try with a archlinux on VM to have the most similar situation. |
Arch really isn't similar to SteamOS, you won't be able to test SteamTinkerLaunch's Steam Deck behaviour on Arch. You might be able to spoof a couple of the checks but it's not ideal, and you'd have to put a lot of hacky workarounds in the code and then remember to remove them. SteamTinkerLaunch explicitly checks if it's on SteamOS and has alternative functionality and UI, downloads binaries (innoextract and cabextract), and updates the path to use those binaries. But those binaries may not be compatible with Arch, and may be built against and thus require an older version of When targetting SteamOS specifically with pieces of functionality, really the only way is to do it on SteamOS, and it's a real pain - which is why I don't do it, and I don't feel like buying a Steam Deck just to develop on. I did it before, and have decided I won't do it again, I'm keeping STL off my Steam Deck OLED and no longer own my LCD Steam Deck. You can try on Arch but keep in mind that SteamTinkerLaunch will not function how it does on SteamOS out of the box, and you'll have to implement workarounds yourself in the code, and you may hit other road bumps. |
Glad I stumbled across this. I had been searching for a way to disable the launcher's auto updates on steam deck. Interesting to see some of the thoughts about it. |
You should always check the GitHub issues for information first and foremost, if such information is not on the wiki. For some reason, people seem to go to social media first, despite there being no official channels for SteamTinkerLaunch discussion outside of GitHub. |
For me, it was a matter of the right keywords. I had been searching '"steamtinker" automatic updates' in google which brought me to the wiki, but it didn't mention specific steps or how to turn it off. A GitHub search in the repo for "automatic" eventually got me here, but I wouldn't have known this particular Issue would contain info about it from the title alone. |
I'm not trying to be awkward, but I think that indicates that it doesn't exist. Also, for what it's worth, when searching in future it might be a good idea to use "SteamTinkerLaunch" or "STL" - The program is not called SteamTinker or SteamTinkerLauncher, common (frustrating) misspellings I have seen for years. It's not a launcher, it's a wrapper tool.
Hm, I named the issue as such to hopefully encourage all Steam Deck users to check here and, with some luck, contribute. It's pinned to draw users' attention to it. But good to know. Maybe I just use GitHub weirdly :-) |
I actually searched many iterations of the name, I didn't want to list all of them out.
Would be hard to find since that's everything baseball. 😆
There's a ton of settings, I was merely stating that I had to search and make guesses just to be sure I couldn't turn it off. I play around with hundreds of repos and usually you can turn off something like that. It was uncommon, so I had to make sure I wasn't overlooking anything.
Can't really blame people for that one; it has the word "launch" as part of its name. 🙂
It would be nice for everyone to look here, but the average user probably wouldn't see it (or even be aware it exists) since the common path is:
You might have better luck with having a little message (that flashes for attention) like "Hey people, this might go away. See the repo and give me your opinions". It could pop up on first installation and when the program is updated; Too often would make people ignore it by habit. Then you could have the message as part of the GUI in the main menu so their eyes see it while they configure stuff. It should be an obvious hyperlink (that shows the url); people tend to lean toward the path of least resistance, especially when you make it so easy. |
Yikes, I would hope most technically-minded people wouldn't do this. People should read official sources first and foremost. People using SteamTinkerLaunch should be using this repo as their primary source. If they aren't, and only follow instructions from a YouTube video, that to be blunt isn't my problem.
The thing is, this isn't for opinions as such. This is for development. Keeping things restricted to GitHub helps enforce that this tool is for Linux enthusiasts, who would check GitHub for regular updates and who, ideally, can also contribute back. Not all users will or can, but keeping things to GitHub helps overall I have found. I feel like if things were too broadened people the wrong impression that this is some kind of general tool for Linux newbies would just propagate further. And everyone has to start somewhere, but SteamTinkerLaunch shouldn't be that starting point. You should know what you're doing and have some familiarity with Wine and the different components of Proton before, say, trying to tinker with your prefixes. SteamTinkerLaunch on SteamOS, plain and simple, will not be officially advertised if the number of people willing and able to contribute doesn't increase. This isn't here for people to comment the increasingly non-technical opinions about "Please don't get rid of SteamOS support because I use it", this is for people to look at what is missing, what is needed, and how to contribute.
I think this is silly, there is a difference between "launch" and "launcher". The "launch" part refers to how this launches with Steam games, not that it's a launcher. The GitHub description also describes it as a wrapper tool. But I guess from what you've said people don't check the repo... Then again, people don't realise this is a tool for tinkerers and enthusiasts based on the "tinker" part of the name, so maybe I'm being too optimistic.
I was about to say this doesn't work with Yad, as I believe it didn't always, but it appears to work now ( |
True, you shouldn't have to care; just letting you know the general flow. I started off with "I want to run a mod manager on steam deck" it led to YouTube (since Google has been pushing Video super hard it's everywhere) which got me up and running with your program. I generally check sources like GitHub whenever I have a question about how something works, so I understand the sentiment.
Right. I was just giving an example of letting people know.
There are controls in GitHub to help with that; automatically closing Issues, tagging as irrelevant, keeping the notice up about your thoughts, etc.
Understandable, just putting what I see from my perspective. I cared enough to bother posting here. Otherwise I would have not bothered and remained silent.
I understand what you mean, but we shouldn't get too caught up in semantics.
True, but I think I saw somewhere where you have logic to detect if someone is running on a steam deck. I can't remember where though. I should say, the main reason I posted here was because of that. I just wanted to say "Hey, I'm another person who noticed this" |
The Steam Deck runs Linux, it runs a variation of Arch Linux. I hope this doesn't come off as semantic. However, it runs a different version of Linux compared to your traditional Linux desktop as it doesn't easily allow you to install persistent packages from a package manager like most distributions. The other major painpoint is with Valve's "Game Mode", which is a gamescope session. Also, for the record, I used to care a lot about SteamOS support, until the demographic didn't really lend itself well to an enthusiast tool. In the beginning I had hoped SteamOS would bolster the Linux enthusiast scene, but it has almost drowned it out. It became very stressful trying to help users who weren't tinkerers. Trying to start from first principles and explain various things, even basic things like what Wine is, is not ideal for a project that is for tinkering. Traditionally, on the Linux Desktop, users that would find SteamTinkerLaunch were familiar with all of these concepts. It allowed users to automate various things they were already doing manually. This is also a strength of using Bash (although I'm not sure if this is why it was chosen specifically), as users who would write their own Bash scripts to do these things would have a head start reading the codebase. I am not talking bad about users who don't know these things, what I'm getting at is, starting from the very beginning to explain how to troubleshoot problems to users is time consuming when it is pretty core to Linux gaming. And to add to this, I love my Steam Deck, but I don't like developing for it, because it's not the same as developing for Linux Desktop users from a design perspective.
SteamTinkerLaunch has been around long before the Steam Deck, the project was started by a different maintainer back in mid 2020. Many users that are not nearly as constructive as you have been, are very entitled, thinking that Linux gaming didn't exist before they came along and that all Linux Desktop software was designed with them in mind, when the vast majority was not. They refuse to understand that SteamTinkerLaunch was not made for SteamOS.
I entirely agree with you. That's exactly what this issue is meant to do. Apart from a Yad version bump, everything here will have to be done by the community. Most of the legwork for a Yad version bump was actually done by a community member who did the investigation. I will no longer be maintaining SteamOS support, as I do not use SteamTinkerLaunch on my Steam Deck. This issue is specifically for features I have identified as missing, and as per the title, the community will have to implement them. There may be more. Unless I picked you up wrong, in my head I think this is putting the owness on the community to actually step up. And a couple of people have, but it's few and far between. This issue is my identification of missing SteamOS features, and putting it out to the community that they'll need to implement these missing features, because I will not be doing it.
I agree and apologies, I think I was delving too deep into semantics. |
Hello! I would be interested in assisting with this. I am no expert but I have always been a tinkerer and Arch Linux is my main OS. I do not have a large amount of free time due to work and raising some new baby kittens but I think I have enough to be helpful and at least keep this open. Big fan of STL on my pc and would love to make sure it can remain available to people on Steam Deck. I do own a steam deck so no worries about virtualization. I am not concerned about tinkering in Steam OS on my deck either. Catching up with this thread it seems we have 2 action items:
When I get some time in the next couple weeks I will clone this repo and start looking into how STL currently manages dependencies and see where to go from there. I think the version marker sounds like a good start. I don't want to get anyones hopes up but I am very interested in this! |
I appreciate it! I'm not working on this and I haven't heard if anyone else is tinkering around with it yet. For what it's worth, I wasn't an expert when I started with STL, and I'm still far from it. Feel free to ask any questions along the way, or even open a dedicated issue for this (I probably should've did that, as was pointed out either here or in another issue). I'll try to give you a little bit of background. To clear up any confusion, dependencies are only managed on SteamOS, so all of the code for dependency management is specific to SteamOS (as on the traditional Linux Desktop, dependencies come from your package manager). As for the approach, the one @Mte90 suggested still stand I think:
I previously had the idea that we should have a checkbox to control this, but this would mean STL could run without downloading dependencies in some cases. So I don't think there is any benefit to disabling the automatic dependency updates (it'll fail if the user is offline already, so no concerns there). We should decide whether to check for dependency updates based on whether the SteamTinkerLaunch version has changed. So we need a way to get the previous version. One way to do this might be to store it somewhere. We can probably put it in a text file in If Otherwise, if the version string in So I see the flow will work like this:
I'm writing this at 4am so I hope it makes sense 😅 Now onto some very quick-and-dirty implementation details! The whole Steam Deck logic is contained within the I am thinking we can create a function to do this, and call it in this part of the code: https://github.com/sonic2kk/steamtinkerlaunch/blob/04ae6e9ea8733d980fe5d78fa93327230a9c34e2/steamtinkerlaunch#L26084 -- After We could call this function something like # (Note that `# ...` is used to illustrate where existing code is that I have omitted for brevity)
# Create this variable towards the top of the script to define the path for 'lastvers', probably somewhere around here: https://github.com/sonic2kk/steamtinkerlaunch/blob/04ae6e9ea8733d980fe5d78fa93327230a9c34e2/steamtinkerlaunch#L346
# Feel free to call it something else
STLSTEAMDECKLASTVERS="$STLCFGDIR/lastvers"
# ...
# Then put this somewhere around where the Steam Deck-related functions are, order isn't too important though
function checkSteamDeckLastVers {
# This function just makes sure that the 'lastvers' file exists at the defined path
if ! [ -f "$STLSTEAMDECKLASTVERS" ]; then
echo "$PROGVERS" > "$STLSTEAMDECKLASTVERS"
fi
}
# ...
# This function already exists, I am including it here to illustrate how and where
# you would add the new line to the function
function steamdedeckt {
# ...
if [ "$STEAMDECKSTEAMRUN" -eq 0 ]; then
installFilesSteamDeck
checkSteamDeckLastVers # New line, feel free to exclude the spaces in your
checkSteamDeckDependencies
# ...
fi
# ...
}
So that's an idea on how to store the last used installed version. It will make sure that it exists and if not, it will create it, and it will create it after each Steam Deck installation. To actually use it, we'll want a way to compare if this version matches the existing version ( # This function will check if the version in `$STLSTEAMDECKLASTVERS` does not match the current version
# For example, if we had v14.0 installed before, 'lastvers' would have v14.0
# Then, if we were updating to v15.0, 'lastvers' would be 'v14.0' but 'PROGVERS' would be 'v15.0'
function checkSteamDeckSTLUpdated {
# This is how updateCfgFile gets the config file version, so re-use it
CHECKLASTVERSSTEAMDECK="$( cat "$STLSTEAMDECKLASTVERS" )"
if [ "$CHECKLASTVERSSTEAMDECK" = "$PROGVERS" ]; then # I don't know if this exact check will work
writelog "INFO" "${FUNCNAME[0]} - Last known SteamTinkerLaunch install version ('$CHECKLASTVERSSTEAMDECK') and the current version ('$PROGVERS') match -- There has been no update since last launch"
return 0
else
writelog "INFO" "${FUNCNAME[0]} - Last known SteamTinkerLaunch install version ('$CHECKLASTVERSSTEAMDECK') and the current version ('$PROGVERS') do NOT match -- It seems there has been an update!"
return 1
fi
} Hope it's making sense so far. Now onto actually using this in the dependency check. The dependency code for SteamOS-related shenanigans is under if [ -f "$(command -v "$DEPCMD")" ] && [ "$CHECKCMD" = "OK" ]; then
writelog "INFO" "${FUNCNAME[0]} - Using '$DEPCMD' binary found in path: '$(command -v "$DEPCMD")'"
echo "Dependency '$DEPCMD' already installed, nothing to do."
else
writelog "INFO" "${FUNCNAME[0]} - Downloading $DEPCMD version automatically from URL '$REPOURL'"
writelog "INFO" "${FUNCNAME[0]} - curl -Lq \"$REPOURL\" -o \"$DEPDIR/$DEPFILENAME\""
# ...
fi Which basically says, if the dependency exists and can be executed successfully, then assume it is valid. Otherwise, download the dependencies. However we will want to update the code to perform the check to see if we need to update. In the first code block, we make sure we have a reference to the last installed version before updating. In the second block, we make sure we have a function that lets us check if the version from the last installation has changed. Now, we'll actually use it, and we'll change the check to be as follows: # The check now says, don't update dependencies if all of these conditions are true:
# 1. The dependency file exists
# 2. The dependency can actually be ran, confirming it is a valid file
# 3. SteamTinkerLaunch has not updated, so there would be no change in dependency version and thus no need to update
# If any of these are false, we need to check our dependencies (if a file is missing we would need to update, or if it cannot be used we need to update, and also if STL updated we may need a newer version, so update).
if [ -f "$(command -v "$DEPCMD")" ] && [ "$CHECKCMD" = "OK" ] && [ "$( checkSteamDeckSTLUpdated )" -eq 0 ]; then # Could also store in a variable or something
writelog "INFO" "${FUNCNAME[0]} - Using '$DEPCMD' binary found in path: '$(command -v "$DEPCMD")'"
echo "Dependency '$DEPCMD' already installed, nothing to do."
else
writelog "INFO" "${FUNCNAME[0]} - Downloading $DEPCMD version automatically from URL '$REPOURL'"
writelog "INFO" "${FUNCNAME[0]} - curl -Lq \"$REPOURL\" -o \"$DEPDIR/$DEPFILENAME\""
# ...
fi There is one caveat that will need to be explored here. The logic up to this point should work, but when we actually try to update the dependencies with There may also be some trouble as when the archives are downloaded, they are possibly not cleared again. That is, the dependencies are downloaded and extracted, but the archives remain, and if they remain, STL will just try to extract the dependencies from the existing archives (to aid in offline installation, if a user downloaded dependency archives ahead of time, STL will just use that). This is where some of the complexity comes in. Up to this point I think we can manage to get STL to see "ok, our version changed, now let's update the dependencies". But the With this, dependency update should be in place. Of course a lot of testing will need to be done, but hopefully this gives you a bit of a start on where to look around the codebase and what you would need to touch, and some idea on implementation. If you have a better idea on doing things please feel free to go ahead and run with it! I am not saying it has to be done this way, this is just to give you a rough idea of how you might want to approach the problem. Oh, and about the Yad AppImage version bump, I can handle that. We have a bumped version but it was built against my too-new Arch install, so we'd either need to wait for SteamOS to rebase onto a newer Arch snapshot (one with a newer |
We may want to make
function steamDeckOptionalDepFail {
# $1 is the optional dependency pretty name, i.e. 'innoextract'
printf "\nWarning: Failed to install optional dependency '%s' - Installation will continue but some functionality may be missing!" "${1}"
writelog "WARN" "${FUNCNAME[0]} - Failed to install optional dependency '${1}' - Installation will continue but some functionality may be missing!"
} Its usage would replace function checkSteamDeckDependencies {
# ...
installDependencyVersionFromURL "$INNOEXTRACT" "$INNOEXTRACTFILE" "$STLDEPS" "$INNOEXTRACTURL" || steamDeckOptionalDepFail "$INNOEXTRACT"
installDependencyVersionFromURL "$CABEXTRACT" "$CABEXTRACTFILE" "$STLDEPS" "$CABEXTRACTURL" || steamDeckOptionalDepFail "$CABEXTRACT"
# ... I thought about implementing this as part of #1136 but I didn't want to make any significant changes. Also it might need some other considerations, or may not be super important to most users after #1111. But I wanted to leave this here to show it was considered and maybe spark some ideas for any future contributors! |
I just thought about the way dependencies are installed. With #1111, the easiest way to deal with this would be a branch with the new dependencies because it allows us to switch to specific branches while updating accordingly to the new libs. Thus, STL would follow the SteamOS Stable releases and preview/beta users would only need to switch to Making them optional could also be an option in the future though |
System Information
Feature Description
SteamTinkerLaunch runs on SteamOS, but there is room for improvement. This issue intends to describe, at least at a high level, the improvements I would like to see to SteamTinkerLaunch on SteamOS. There are not in any particular order.
Anyone from the community is free to contribute to these if they are welcome. I would ask that you leave a comment stating that you want to work on it. I'll be happy to offer support, ideally in a comment chain on a PR rather than here, solely in the interest of keeping this issue thread clean. I don't plan on working on any of these issues anytime soon, but if that changes, I'll leave a comment stating that I'm working on one as well.
I may extend this issue if anything comes to mind, but I don't intend for this to be a "living" document. Steam Deck-specific enhancements are still welcome, though I may expand and consolidate them here. Generally though these are just point-in-time improvement ideas I've had for a while now but don't have the time or motivation to work on.
If you're interested in getting involved with SteamTinkerLaunch development, this would be a great way to make a massive difference. I would be only too happy to review PRs related to Steam Deck improvements. If you want to work on a Steam Deck improvement please feel free to open an issue+PR combo too.
When a feature is added, the title will be stroked-out, a PR will be added to the side of it, and the entry in the TODO at the bottom of this issue will be checked with the PR beside it as well.
Automatic Update Checkbox ❌
After further consideration, I decided that it would be best to remove the automatic updates once automatic dependency updates are in place. Then when updating STL, any relevant newer dependency versions will be installed. See #859 (comment) for more details.
SteamTinkerLaunch will check for its dependencies on each update and also try to update itself. This worked well when SteamOS support was heavily experimental, but is not necessary now. We should gate automatic updates behind a checkbox on the Global Menu.The issue with this is that I would prefer to only show this checkbox on SteamOS. Conditional Yad UI logic like that exists for ModOrganizer 2 (it won't show the MO2 options unless MO2 is installed), so it should be possible. Perhaps we could have a SteamOS section with various other options, who knows.My vision for this though is to have a SteamOS checkbox near the top or near the bottom of the Global Menu, with a "SteamOS Settings" heading, and a checkbox to toggle automatic updates. When this is enabled, we'll skip a lot of the logic in thesteamdedeckt
function and just run SteamTinkerLaunch without making any network calls.This feature will also improve the commandline usage experience on Steam Deck, as there won't be annoying "Checking dependencies" messages.Automatic Dependency Updates
This itself could be a separate checkbox on the global menu as well.
Some of the SteamTinkerLaunch dependencies are not available on the Steam Deck. Mainly, Yad is not. But some useful dependencies like
innoextract
aren't available. This is seemingly required to install ModOrganizer 2 on SteamOS, though I'm not sure why.These dependencies are currently downloaded to
/home/deck/stl/deps/usr/bin
, and are stored as regular binaries. They are fetched from the AUR, save for Yad, which is downloaded from the SteamTinkerLaunch Tweaks repository. The AppImage is, at time of writing, about 18 months out-of-date and based on Yad 10.90.The version of the dependencies to download is defined in the SteamTinkerLaunch code. However, we currently have no way to know which version of a dependency is downloaded. The
innoextract
version is still justinnoextract
, we can't tell if we have, say, v1.8 or v1.9. We also can't tell package version changes, such as the difference betweenv1.9-6
andv1.9-7
. Even this distinction is vital for SteamOS compatibility, as SteamOS version bumps (such as 3.3 to 3.4, or the upcoming 3.4 to 3.5) may require version bumps to these dependencies.We need a way to track the currently downloaded version of a dependency, and then we need to check if the STL script expects a newer version. For example, if we previously downloaded innoextract v1.9-7 for STL 12.12, but STL 14.0 requires innoextract 1.9-8, we need to know that the newer STL version expects a newer innoextract version.
One way of doing this would be to give dependencies a name matching their binary, and this text file would contain the current version. For example, innoextract would have an equivalent
innoextract.version
, and this would note the version STL downloaded last, such as1.9-7
. We would then read this text file to see if we need to update. For Yad, we should be able to get the version with the-v
command, if the Yad binary exists, but we could note this too.Note: This is essentially the equivalent to #719, but consolidated into this wider Steam Deck improvements proposal. Mainly because in #854, the
cleardeckdeps
command was added which will remove dependencies, offering a quicker-fix. This is just a stop-gap to temporarily address the wider issue here.Improve Checks around Valid Dependency ✔️
(See also: #1046)
This feature was implemented with #1054.
Right now ininstallDependencyVersionFromURL
we check if a dependency file exists and use this to dictate if we need to download the file. However, we can end up with a situation where a file that we can execute with the name of our dependency exists. This can be because a download failed. For example, if/home/deck/stl/deps/usr/bin/innoextract
exists, we assume it is valid. This is not necessarily true though, as the file may not have downloaded properly.The problem with this is that dependencies cannot be effectively used in this case. They are invalid files, so cannot be executed.There are a few approaches we could take to solve this off the top of my head, though of course other ideas are welcome:Check that a file is > 0 bytes ininstallDependencyVersionFromURL
. This would turn our check into something likeif [ -f "$(command -v "$DEPCMD")" ] && [ -s "$(command -v "$DEPCMD" ]; then
.This would not account for cases where the executable exists, and is partially downloadedTry to run the dependency and check if we get a success status code returned, and if we do, we can assume it executed successfully and can be used by SteamTinkerLaunchThe problem is thatinstallDependencyVersionFromURL
is generic, and we would assume binaries are correctly returning status codes, which hopefully they are but that is an assumption we should note for future dependencies (of which hopefully we will not add any more).Other file validity checks, such as usingfile
and grepping for some kind of output we would expect from a valid, fully downloaded, ready-to-use native Linux binary.I don't know what this would be or if there's anything generic and viable, but it's a path we could explore.Even one of these would be better than what we have today, but if all of them are viable, I would not be opposed to implementing all of themBump Yad AppImage version ✔️
(See also: #1060)
This feature was implemented with #1077.
See also:
Special thanks to @AtomHare for their work over at sonic2kk/steamtinkerlaunch-tweaks to help with this!
It would be nice if we could bump the Yad AppImage version. There may be no specific need to but it would be useful to do so imo. The Yad AppImage is available from the SteamTinkerLaunch Tweaks repository.Building a newer Yad AppImage and publishing it as a release would be very useful, though responsibility may fall on me to do this. However getting some community testing on newer Yad AppImage versions would be very helpful once I build one, because I don't know how compatibility is on SteamOS.TODO:
Automatic Update CheckboxThe text was updated successfully, but these errors were encountered: