Allow offline installing compatibility tools from archives

[DavidoTek]

#412 , #410

Allow for installing from an archive: this would make it so that any forked, custom version of proton can be installed easily to Steam

---

This needs another UI with following options:

• Archive (Textbox with select folder button)
• Launcher
• Type [optional] (e.g., Wine, DXVK, ...)
• Cancel, Install buttons

I would hide this behind advanced mode though. I'm not sure where we should put this button. There are 3.5 options:

1. Add another button to (a) the main window (b) some other dialog
2. Add it as an option in the drop down box of the install dialog
3. Add a drop down arrow to the "Add tool" button (not very Steam Deck friendly, I would not consider that option)

[sonic2kk]

I stated in earlier issues but will also state here: I love this idea! My input on the mentioned features:

Archive (Textbox with select folder button)

I think there should be an option to choose what the top-level archive is. This is possibly tricky to implement though. What I mean by this is, say a user downloads a custom Wine-tkg build from a fork via CI. It's going to be a ZIP artifact that contains another archive inside. If a user selects the ZIP archive we should prompt them to choose what the top-level folder to extract should be so that they extract the right item from the archive. A tool called ModOrganizer 2 allows you to do this to some degree to choose what the top-level mod folder is in an archive if it can't tell, so perhaps we should do something along these lines.

Either way we will also have to implement some logic to determine the archive type. I am unsure how to do that, but it is surely possible as this has been a solved problem for archive software since forever 😄

Launcher

When choosing a launcher we should filter out certain tool types that are not supported (i.e. DXVK/vkd3d is not supported for Steam).

Type [optional] (e.g., Wine, DXVK, ...)

Perhaps we could implement some logic to "guess" this based on directory structure. For example if something contains a proton script or something we can assume it's Proton. It doesn't have to go in an initial implementation or anything but possibly a nice QoL feature.

Similarly if we detect only DLLs and .so libs and if these are only one subdirectory deep (to make sure we don't match DLLs included with Proton flavours) we could assume it's a DXVK/vkd3d runtime.

That kind of would need to be wired in to account for the launcher though, as we don't allow runtimes for Steam for example. Potentially we could warn the user if we detect a tool that has a type which is incompatible with the current launcher, but whether that's helpful or not will depend on how accurate we could be at auto-detecting the type!

1. Add another button to (a) the main window (b) some other dialog
2. Add it as an option in the drop down box of the install dialog

I think both of these are good in combination. Having both options allows the user to either do it from the Main Menu or from the CtInfo.

But if we have to go with one, an option on the Main Menu is probably the most clear approach. We could add it as a util button with an archive icon, but that might not be super clear.

[Darthagnon]

Perhaps we could implement some logic to "guess" this based on directory structure. For example if something contains a proton script or something we can assume it's Proton. It doesn't have to go in an initial implementation or anything but possibly a nice QoL feature.

What about implementing some sort of top-level manifest.json standard? It could be proposed to the dependency maintainers; such a file is used in browser extensions to specify scripts, paths, icons, version numbers, etc. and could work here, too, to make the guesswork less critical.

[sonic2kk]

That would severely limit compatibility and be a file specific for use with ProtonUp-Qt. I don't see this being adopted or even being welcomed, remember these tools are also distributed ourside of ProtonUp-Qt. Other downstream projects would need to consider this file which means they may have to rework various pieces of logic and account for versions of the tool with and without this manifest. It would be a lot for downstream project maintainers to implement, and I don't see tool maintainers welcoming such a file. I would not welcome such a file in SteamTinkerLaunch, for example.

Plus we'd need to account for cases where this doesn't exist anyway, so we'd need to maintain two code paths instead of one. So it wouldn't make guesswork less critical. Even if it were adopted universally, we'd need to account for older tool versions that wouldn't have this manifest (something I don't believe is an issue for browser extensions in your example).

And on top of this, making inferences based on directory structure used to be the standard for determining Proton if a Proton version was a Valve Proton release or a third-party Proton version release (since Proton 9 they're the same I believe). It's not that tricky to do in most cases.

I see where this comes from, but this is not quite the same as browser extensions, there is no standard here. ProtonUp-Qt is not officially acknowledged by any of the tool maintainers (except Luxtorpeda iirc) and is not acknowledged by launcher maintainers.

Maybe it was unclear or poor wording but I also want to mention that ProtonUp-Qt doesn't download any dependencies for these compatibility tools and runtimes. It will notify if some dependencies are missing in the rare instance where a tool requires them, but it won't install them. On the other hand, these tools aren't dependencies either, they are third-party projects. I just wanted to clarify in case anything was unclear; all of these tools that ProtonUp-Qt can download are optional tools for launchers. Nothing it downloads should be considered a hard dependency of anything.