[feat-578] remove dotnet and screen dependency on linux

[silentrald]

Scope

closes https://github.com/Zagrios/bs-manager/issues/578

Implementation

Removed dotnet and screen dependencies. Then used proton and wine binary files which comes package in Steam. They should be linked with the protonFolder which is stored in the static config.

On startup as well, there is a check if the protonFolder is correctly configured, else the user will be blocked by a modal to configure the protonFolder.

Screenshots

How to Test

• Setup

  • Prompting the linux setup modal
    • Remove the proton-folder key within config.json.

• Feature Tests

  • Check if setting the protonFolder to an invalid value is handled properly, both on the modal and settings page
  • Check if setting the protonFolder to a valid value is correct, both on the modal and settings page

• Functionality Tests

  • Check if you can install mods (especially BSIPA) within anyBSVersion
  • Check if you can launch any BSVersion

New Resource Text

List of added resource text

misc.unknown: An unknown error occurred ¯\(ツ)/¯

pages.settings.proton-folder.title: Proton folder pages.settings.proton-folder.description: Change the folder to the Proton path. (eg. Proton - Experimental) pages.settings.proton-folder.choose-folder: Choose folder pages.settings.proton-folder.errors.title: Setting the Proton folder failed pages.settings.proton-folder.errors.invalid-folder: Invalid Proton folder path

modals.linux-setup.title: Linux Setup modals.linux-setup.proton-folder: Proton folder modals.linux-setup.proton-folder-description: Choose the folder to the Proton path. (eg. Proton - Experimental) modals.linux-setup.choose-folder: Choose folder

notifications.bs-launch.errors.PROTON_NOT_SET: Proton folder not set notifications.bs-launch.errors.PROTON_NOT_FOUND: Proton binary not found notifications.bs-launch.msg.PROTON_NOT_SET: Set the Proton path in settings notifications.bs-launch.msg.PROTON_NOT_FOUND: Set the Proton path in settings

Emoji Guide

For reviewers: Emojis can be added to comments to call out blocking versus non-blocking feedback.

E.g: Praise, minor suggestions, or clarifying questions that don’t block merging the PR.

🟢 Nice refactor!

🟡 Why was the default value removed?

E.g: Blocking feedback must be addressed before merging.

🔴 This change will break something important

Blocking	🔴 ❌ 🚨	RED
Non-blocking	🟡 💡 🤔 💭	Yellow, thinking, etc
Praise	🟢 💚 😍 👍 🙌	Green, hearts, positive emojis, etc

[Zagrios]

@silentrald Do you know if there is a guide or something created by Steam that explains what Proton is to users? (What it is, where to find it, etc)

[silentrald]

@Zagrios I think it's in the Proton's GitHub page.

What - https://github.com/ValveSoftware/Proton Where - https://github.com/ValveSoftware/Proton/wiki/Proton-FAQ#where-is-proton-installed

Although I could defaultly open the $HOME/.local/share/Steam/steamapps/common on the folder modal, for a faster navigation of the proton binary.

Is there anything that should be added if there are any non-technical linux users that may come upon this modal screen?

---

Might add some additional changes, to use the user's wine executable if its installed in the users machine, else fallback back to the wine bundled with proton.

Also sometimes the Beat Saber.exe isn't found so we have to explicitly tell where it is. As discussed in https://github.com/Zagrios/bs-manager/issues/585#issuecomment-2367253761.

[Zagrios]

@silentrald I was testing on my Ubuntu machine, and I couldn't get the BSIPA installation to work. So, I tried running that command in the terminal to see what would happen, and it turns out that Wine takes over 5 minutes to start IPA.exe. Is that normal behavior?

'/home/mathieu/.local/share/Steam/steamapps/common/Proton - Experimental/files/bin/wine64' '/home/mathieu/BSManager/BSInstances/1.37.5/IPA.exe' '/home/mathieu/BSManager/BSInstances/1.37.5/Beat Saber.exe' -n

And also for me, it only works with wine64; otherwise, using wine gives me a kernel32.dll not found error. :thinking:

[silentrald]

@Zagrios normally the first call to wine, assuming that your /.wine environment isn't initialized yet, should download the necessary things for it work which makes it slow. Then for subsequent calls on wine should be fast. What I think that happened as well is that you ran the mod install which the spawn call timed-out, meaning that the wine process is not terminated in the system. Then you ran another instance of wine, which is getting blocked or waiting for the original wine process to be done. So I think you just needed to kill the wine process.

For the wine (32 bit) fallback, on Arch it works normally but in my Ubuntu VM, seems I'm encountering the kernel32.dll as well. Seems the problem lies in some dll dependency files that are not available in Ubuntu. However, wine64 seems to work there so I might change it to that and since electron-builder is only limited to --x64 arch as well unless there is support for x86 for linux with that argument.

Also ran some problem with the installed wine with Ubuntu since this needs to have a wine-mono installed, which can be solve by this https://askubuntu.com/a/992215. Can add this to the wiki troubleshooting part so that it would be easier to install. Although, side note on Arch, wine ask you to install missing dependencies which is when you run the wine command, that's why its very weird that Ubuntu doesn't do this.

So which wine implementation do you think is the best here:

• (My preffered option) Use only proton wine/wine64 binary depending on the architecture. Or we can just support wine64.
• Check if wine is installed and do the troubleshooting if necessary, if no wine is installed fallback to proton wine/wine64
• Use proton wine/wine64 then fallback to installed wine.

[Zagrios]

I think I will support only the proton/wine64

[silentrald]

I actually didn't notice this but Ubuntu installs wine 9.0 in their stable release while in my build it uses 9.20. Followed this winehq tutorial (https://gitlab.winehq.org/wine/wine/-/wikis/Debian-Ubuntu) on how to upgrade it to 9.20 and BSIPA works, just have to adjust the spawn timeout or remove it, since wine-mono install takes a long time to download. This might be better since if wine updates to their next stable release, installing wine OOTB would have no more issues.

Might follow this flow instead:

• Run wine --version and check if its version
  • >= 9.20 use installed wine, if does not exist fallback to proton wine64
  • < 9.20 use proton wine64

This also details this command to support for 32 bit machines

sudo dpkg --add-architecture i386 

---

Wdyt, or just always use proton wine64 would be better?

[Zagrios]

Hmm, I think always using Proton/Wine64 would be better. This way would reduce a bit the complexity and therefore minimize potential points of failure

"best code is no code" 😅

We know Proton/Wine64 works well, so that should be enough.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[Zagrios]

Okay I've re-tested everything, and everything was working perfectly :raised_hands: Thanks @silentrald ! Merging :rocket: