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:

• the button bar in the bottom is on an area that on external mouse is not clickable, i mean is not possible to move the button over there, only with a steam deck outside the dock station and touchscreen I press them
  • this open to another issue, the scrolling as it is very bad as the scrollbar is over the UI elements so clicking where should be often get selected the item behind
• Another one is that I use it only for trainers and I have to always the same step, game manu set fork command etc and a path and save and start the game hoping that starts
  • wondering if there is a way to open automatically STL to game menu and already prefilled so I just need to set the trainer itself (and maybe change the proton version so I can use the GE version that include dotnet for some of them)

I can do some tests and helps if you need it on testing etc.

the button bar in the bottom is on an area that on external mouse is not clickable

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.

Another one is that I use it only for trainers and I have to always the same step

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 can do some tests and helps if you need it on testing etc.

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 I have a VM with SteamOS for steamdeck, with some investigation:

So I think that to detect if a steam deck is enough uname -n (I have still to update the image but I think that still works with the latest version).

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.
I don't know how to do that with an appimage package but the simplest solution is to save somewhere the actual stl version and at every run check if it is the same on the script, in cose it is different just do the upgrade.

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.

Can we move the discussion for the Automatic update and automatic dependency check in a new ticket?

Sure, sounds good! Please remember though that all of this is specific to SteamOS.

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.

Hm, we could do this. We should store the current version in global.conf. At the top of the file we have ## config version:, followed by the version string from PROGVERS at that launch.

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 \#CAT_steamos`` or something, I don't know.

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.
Later we can add the check of steam deck, so we can test it and do the UI more freely as I think that the update automatically is helpful also on non-steamos.

Also you can create a label on github for steam deck stuff.

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. Later we can add the check of steam deck

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.

I think that the update automatically is helpful also on non-steamos. I think that the update automatically is helpful also on non-steamos.

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.

Also you can create a label on github for steam deck stuff.

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.
I tried holoiso and holoiso_tweaked in VM but after installing they doesn't work.

So right now I am not able to test a steamdeck in a VM.
I was evaluating an archlinux install to simulate the steamdeck without the gaming mode, in the meantime I will try a ubuntu VM with protonup-qt and steam to install everything.

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 libboost.

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.

but it didn't mention specific steps or how to turn it off.

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.

but I wouldn't have known this particular Issue would contain info about it from the title alone.

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 :-)

might be a good idea to use "SteamTinkerLaunch" or "STL" - The program is not called SteamTinker or SteamTinkerLauncher,

I actually searched many iterations of the name, I didn't want to list all of them out.
The point was I made it to the wiki.

or "STL"

Would be hard to find since that's everything baseball. 😆

I'm not trying to be awkward, but I think that indicates that it doesn't exist.

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.
In fact, my persistence is what led me to this very Issue.

It's not a launcher, it's a wrapper tool

Can't really blame people for that one; it has the word "launch" as part of its name. 🙂

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 :-)

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:

• "I want to do x"
• Watches a flashy YouTube video that says open store and use ProtonUp-Qt to install SteamTinkerLaunch

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.

Watches a flashy YouTube video that says open store and use ProtonUp-Qt to install SteamTinkerLaunch

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.

You might have better luck with having a little message (that flashes for attention) like "Hey people, this might go away. See the #859 and give me your opinions".

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.

Can't really blame people for that one; it has the word "launch" as part of its name. 🙂

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. ☹️

It should be an obvious hyperlink It should be an obvious hyperlink

I was about to say this doesn't work with Yad, as I believe it didn't always, but it appears to work now (yad --text="<a href=\"https://google.com\">Test text</a>"). Although users will either have downloaded from GitHub, or can access GitHub from the ProtonUp-Qt info button. Plus, this is something exclusively for SteamOS, I would rather not annoy non-SteamOS users with SteamOS-specific stuff on the UI as much as possible (users like myself have increasing frustration towards Linux software catering to SteamOS too much).

If they aren't, and only follow instructions from a YouTube video, that to be blunt isn't my problem

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.

The thing is, this isn't for opinions as such. This is for development.

Right. I was just giving an example of letting people know.
I was completely unaware that SteamTinkerLaunch was Linux first and that you didn't care about Steam Deck. I seriously had no idea until I really sat down and read things in GitHub.
Just using the Steam Deck to install, I saw the interface seemed to be designed for Steam Deck and kept it at that. Until I wanted to learn more that is.

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.

There are controls in GitHub to help with that; automatically closing Issues, tagging as irrelevant, keeping the notice up about your thoughts, etc.
Also, just because someone has an opinion (including me 😉 ) about a direction they would like doesn't mean you have to do it.
In fact, you could put the burden of creation on them if they really want a certain feature. Worked pretty well when I dealt with >5k users back in the day. If anything, I got some really good ideas from people who actually cared.

SteamTinkerLaunch on SteamOS, plain and simple, will not be officially advertised if the number of people willing and able to contribute doesn't increase.

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 think this is silly, there is a difference between "launch" and "launcher"...

I understand what you mean, but we shouldn't get too caught up in semantics.

I would rather not annoy non-SteamOS users with SteamOS-specific stuff on the UI as much as possible

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.
It was just an idea though. I thought I'd bring it up since I noticed there was hardly any reply on this Issue (just one other person) while this seemed like a pretty important thing more people should be aware of.

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"

I was completely unaware that SteamTinkerLaunch was Linux first and that you didn't care about Steam Deck. I seriously had no idea until I really sat down and read things in GitHub.

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.

Just using the Steam Deck to install, I saw the interface seemed to be designed for Steam Deck

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.

In fact, you could put the burden of creation on them if they really want a certain feature.

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 understand what you mean, but we shouldn't get too caught up in semantics.

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:

• Automatic Dependency Updates
• Bump Yad AppImage version

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!

Hello! I would be interested in assisting with this. I am no expert [...]

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 think that the first thing we can do is an automatic update checker at every new version if the dependency are installed by STL.

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 ~/.config/steamtinkerlaunch and call it something like lastvers. We can then write to this on installation of SteamTinkerLaunch on SteamOS with the value of PROGVERS (we wouldn't ever need it on any other case, and there is no convenient way to get it that I can think of outside of SteamOS). Since installing on SteamOS involves running SteamTinkerLaunch, in the Steam Deck installation code we can have a check that will create lastvers if it doesn't exist and initialize it with PROGVERS.

If lastvers exists though, we should check it and compare it with the current incoming version (PROGVERS). If lastvers and the incoming version are different, we should run our dependency updating logic. Then, once updating is complete, we update the value in lastvers.

Otherwise, if the version string in lastvers and the current incoming version are the same, we should skip updating dependencies.

So I see the flow will work like this:

1. STL starts up on Steam Deck.
2. If the Automatic Update checkbox is off, don't do any checks and skip.
3. Otherwise, we check if SteamTinkerLaunch has updated by comparing the value in lastvers with that of the incoming version (we can get the incoming version from PROGVERS)
4. If the version stored in lastvers is the same as the incoming version, do nothing (this will prevent the constant echo spam on each launch stating that STL needs to be updated)
5. If the version in lastvers does not match the incoming version string, we should try to update our dependencies, as the newer STL version may specify a newer version of a given dependency
6. Once everything is complete, update the version string in lastvers so that we know we already checked for dependency updates for this version.

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 steamdedeckt function, this is what orchestrates all of the calls to do various dependency management and other things. It is here, before dependency checks, that we will need to create lastvers if it doesn't exist, using the value from PROGVERS.

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 installFilesSteamDeck and before checkSteamDeckDependencies.

We could call this function something like checkSteamDeckLastVers, and it might look like this (entirely untested, just a loose idea):

# (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 (PROGVERS). We can make a function to do this too:

# 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 installDependencyVersionFromURL. The check right now looks like this:

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 fetchAndExtractDependency, it needs investigated whether or not it can actually overwrite existing files. I believe it can.

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 fetchAndExtractDependency may be a bit troublesome here, and may not be able to overwrite existing dependencies in this case. That will need to be tested, though.

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 glibc version specifically) or build against a distro with older libs like Ubuntu (for me in a VM most probably as I don't have any hardware running Ubuntu to hand), as it is more broadly compatible. The only thing really remaining here is the dependency changes described here.

We may want to make innoextract and cabextract optional dependencies. This is because since #1054, we fail if dependencies don't return a success code from a --version check. Right now on SteamOS 3.6 Preview, the Arch snapshot base is bumped, so the innoextract dependency will fail this check even if it extracts correctly because the older version cannot run on SteamOS Preview 3.6. This failure to install causes installation to abort.

innoextract (and cabextract) are optional dependencies, failing to install if they don't extract was probably a bit short-sighted. One way we could make these optional would be to make a new function called steamDeckOptionalDepFail.

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 steamDeckInstallFail when using installDependencyVersionFromURL.

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 steamos-3.6 (or steamos-beta) which is only a click away when using protonup-QT until beta becomes stable for example.

Making them optional could also be an option in the future though