[Feature Request] `removenonsteamgame` Command

[trentondyck]

System Information

• SteamTinkerLaunch version: v14.0.20231212-1
• Distribution: SteamOS

Feature Description

removenonsteamgame|ansg <args>      Remove a non-steam game from Steam
                                       opens gui without args
      <args>:                          for cli min arg is'-an'
      -an=|--appname=
      -id=|--appid=
      -re=|--regex=

Something like this, for me it would be useful for writing some integration tests. I know we can just delete the folder but STL does a number of other things like modifying VDF files etc. Would be nice to have a clean uninstall experience.

[trentondyck]

                steam steam://uninstall/${app_id}

Unless this is enough, I guess.

[sonic2kk]

(Sorry for the delay, I have a bad flu the last several days and haven't been around)

The Steam command may prompt a Steam uninstall dialog, can you test if this command can silently uninstall Non-Steam Games? I think for Steam games it'll prompt you, but maybe not for Non-Steam Games (I'm not even sure it prompts you if you try to remove Non-Steam Games from the Steam UI). If that solves the issue already, this feature request would be a bit lower priority, but still not necessarily without merit since there are arguments we could pass for bulk-remove. Although in the case we would simply use the command arguments to fetch Non-Steam AppIDs based on AppName/regex, and then feed that into the Steam command.

---

If that command isn't sufficient, it should be feasible to implement this outselves, just get every shortcut block and write it out again to the shortcuts.vdf, and skip the one with the given AppID at a basic level. I should note though that Steam will need to be restarted for the effects to be visible on the UI. Not relevant for integration tests which I assume will just check the contents of shortcuts.vdf, but worth noting from a user standpoint.

Removing based on App Name alone would be a bit too risky I think since you could end up with duplicates. Unless that's the point, which feeds into my next question: What would the regex argument do? If the point is to bulk remove shortcuts then the name and regex Args could be pretty cool.

Although I should say if we're passing regex it'll likely be Perl-style regex since afaik this is the most broad and thus useful one we can use with Bash commands (such as grep and sed). Not a huge deal but something to note.

I'm not sure if this command would need a GUI component but that should still be possible to implement, just a straightforward Yad dialog that calls into this command.

No ETA for this, but I can see the use-case. I'll see when I have time to add something like this, not sure if it'll get in before 14.0 (see #992).

Thanks! :-)

[sonic2kk]

Updated the issue title mostly for my own reference 🙂

[trentondyck]

yeah it doesnt prompt, for non steam games. havent tried it for steam specific games.

no rush on this ticket. your regex use cases are valid, for me its just a matter of "I don't know what the appid is so I want to remove a game with name like '%foo%'."

If it's dangerous we could consider a confirmation prompt/popup, with the list of games names/ids that are going to be removed.

[sonic2kk]

One potential downside to relying on the Steam command is that the command may exit before the shortcut is removed. It may just send the command to the Steam Client to remove that shortcut, but it may take a while in some circumstances (though probably faster than Bash could do it anyway). This won't be an issue for most users but when you want to make sure the shortcut is removed before running any other code such as with tests, this option may not be as ideal.

As well as the above, implementing this on the STL side would allow for an option to remove grid artwork when removing the shortcut, which could be handy. On a related note we could also have an option to remove prefixes, as Steam does not do this (I think I opened an issue upstream at Steam for Linux).

Related to the above, I had an idea a while back for a command to clean up Non-Steam Game misc files, such as prefixes, game grids, and STL metadata info. It would've worked by somehow inferring when an AppID represented a Non-Steam Game and if that AppID wasn't in shortcuts.vdf we would remove the data in, say, the grid folder, or the compatdata folder. This was never implemented because I never found a reliable way to absolutely infer this solely from an AppID (and Steam AppIDs are rapidly approaching the same length, so length was not reliable). So having this functionality on remove could be useful.

I also just thought of a case, perhaps as a separate command, where a user could pass multiple AppIDs. And better yet on a UI we could display a table with all of the found Steam shortcuts, and a user could check those and bulk remove shortcuts (with a checkbox to optionally remove game art and prefixes). I'm thinking of a UI design along the lines of what we have for the Vortex games list, although of course this would function entirely differently.

On the other hand, using this command has the benefit of updating the Steam library without needing a UI restart. Although then again that may mean the Steam Client will have to be running, which is not ideal for all scenarios, not even on SteamOS for those of us that close the client and use the Deck in Desktop Mode with a keyboard+mouse+monitor.

---

I think having a remove command and another command/some kind of option to remove multiple (could be possible to combine these in some way, I'm sick in bed and can't think of a way off the top of my head) is the way forward here, and the more I think about it, the more benefit I see to having it on the STL side. This will likely come after #960 and thus still after v14.0 (it is a Non-Steam Game Improvement, but there is no in-progress work for this feature like there is for the linked issue), but I think having this in STL is a good approach :-)

[trentondyck]

Yeah I just put the steam command there because thats what I use since STL doesnt have one, not that it would be intrinsically better than a custom bash command. I'm happy either way, thanks for taking a look at this.