Ginormous Winetricks gui

[UltraBlackLinux]

Hey there,
I've noticed a problem with the winetricks GUI:

Yeah... Please fix this xD
Thanks!

[frostworx]

You do not even test/react on features which were implemented for you, that's why you're on my spam/ignore list
#298
#283

Expecting much and not giving back anything.

[UltraBlackLinux]

You do not even test/react on features which were implemented for you, that's why you're on my spam/ignore list #298 #283

Expecting much and not giving back anything.

Bruh sorry. I don't recieve notifications for closed issues. The things I have requested have worked perfectly - I just forgot to give you some status updates (because of notifs again.)
I have already told you about this multiple times - I am not trying to be an asshole here.

[frostworx]

Ok, accepted.
I was really annoyed that I did not even get a reply when spending my time on feature requests...

The giant gui is a yad bug, and no stl problem (usually you should be able to at least scale down the window to the allowed minimum to make it look a bit better, which doesn't fix the core problem of course)
I already reported the bug upstream a while ago, but looks like upstream is busy with RL (so am I very soon)
There are several other bug reports upstream which describe the same bug. It might help to test yad current master, as it is said to be fixed there.

[frostworx]

In this case the high boxes likely are a result from the pretty long winetricks packages list btw.

[UltraBlackLinux]

Ok, accepted. I was really annoyed that I did not even get a reply when spending my time on feature requests...

The giant gui is a yad bug, and no stl problem (usually you should be able to at least scale down the window to the allowed minimum to make it look a bit better, which doesn't fix the core problem of course) I already reported the bug upstream a while ago, but looks like upstream is busy with RL (so am I very soon) There are several other bug reports upstream which describe the same bug. It might help to test yad current master, as it is said to be fixed there.

Thank you.
Could you maybe also improve the Winetricks wiki page? I don't quite know, how to use the winetricks gui, like the select and install button (The names don't show anymore on hovering over top of buttons and checkboxes so I don't know what setting does what)

[frostworx]

Good idea. I guess the upper part of the gui is self-explanatory, but only the main SELECT, DONE and INSTALL buttons are not, right?
With above "In this case the high boxes likely are a result from the pretty long winetricks packages list btw." I meant
the "Currently selected packages" list at the bottom btw, they trigger the box bug.

[UltraBlackLinux]

but only the main SELECT, DONE and INSTALL buttons are not, right?

Yeah, I didn't quite understand those

With above "In this case the high boxes likely are a result from the pretty long winetricks packages list btw." I meant the "Currently selected packages" list at the bottom btw, they trigger the box bug.

I got that ;)

[frostworx]

Updated the wiki, I hope it is better understandable now:
https://github.com/frostworx/steamtinkerlaunch/wiki/Winetricks

[UltraBlackLinux]

@frostworx Thank you! It's way clearer now!
(Btw, I found a typo: "Using the INSTALL buton" buton)
One last thing though: Does the "Save winetricks proton" button install all selected packages into the selected proton version permanently?

[frostworx]

@typo. fixed, thx.
By default the proton/wine version used for installing packages into the wineprefix is the same which the game currently uses.
The gui offers the option to override the "winetricks" version via dropdown menu.
If the optional "Save winetricks proton" box is checked, the selected override will be used automatically by default in this gui to INSTALL additional packages later (so the user doesn't have to remember which version was used before and doesn't have to set it again)

(will add this answer to the wiki as well) Edit: done

[UltraBlackLinux]

@typo. fixed, thx. By default the proton/wine version used for installing packages into the wineprefix is the same which the game currently uses. The gui offers the option to override the "winetricks" version via dropdown menu. If the optional "Save winetricks proton" box is checked, the selected override will be used automatically by default in this gui to INSTALL additional packages altlaterer (so the user doesn't have to remember which version was used before and doesn't have to set it again)

(will add this answer to the wiki as well)

Ah okay, that makes sense.
Well there are just more and more things that I want to address xD
... The "Save winetricks proton" button duplicates the proton version in the proton-list - Is there a way to revert that/delete a specific proton version?

[frostworx]

... The "Save winetricks proton" button duplicates the proton version in the proton-list - Is there a way to revert that/delete a specific proton version?

It should be possible, but this would have to be changed in multiple dropdown menus.
Should be even possible with a little generic function, but I'm afraid I don't have the time anymore to change that.
TL;DR: maybe :)

[UltraBlackLinux]

... The "Save winetricks proton" button duplicates the proton version in the proton-list - Is there a way to revert that/delete a specific proton version?

It should be possible, but this would have to be changed in multiple dropdown menus. Should be even possible with a little generic function, but I'm afraid I don't have the time anymore to change that. TL;DR: maybe :)

Ah okay.
Thanks for your assistance!

[frostworx]

A quick and dirty
--field="$GUI_WTPROTON!$(strFix "$DESC_WTPROTON" "$BUT_INSTALL")":CB "${WTPROTON//\"}!${PROTYADLIST//!${WTPROTON//\"}}" \

here

would fix this in most cases, but not when the first available option is the current selection

[UltraBlackLinux]

A quick and dirty --field="$GUI_WTPROTON!$(strFix "$DESC_WTPROTON" "$BUT_INSTALL")":CB "${WTPROTON//\"}!${PROTYADLIST//!${WTPROTON//\"}}" \

here

would fix this in most cases, but not when the first available option is the current selection

That's chinese for me now at this point xD

[frostworx]

Hehe.
Looks like it fixing this with a generic function is pretty simple.
Just added it for winetricks. Please test.
Will add it for all other dropdowns as well then.

[frostworx]

oh, wait a sec, need to push the commit first :)

[frostworx]

78e31e4 should fix it for winetricks

[UltraBlackLinux]

78e31e4 should fix it for winetricks

It kinda fixed it, but only for a few entries, this is what it looks like in the proton override option:

[frostworx]

thanks for testing. Yes, the current commit only fixes the winetricks gui, just fixing all other (~55) dropdowns

[UltraBlackLinux]

thanks for testing. Yes, the current commit only fixes the winetricks gui, just fixing all other (~55) dropdowns

Well I rather meant that as a comparison between before-and-after. As the screenshot shows, the first two entries got fixed, but all of the others seem to be the same as before

[frostworx]

Hah, that is a different problem. I thought you mean that the current selection is listed twice in the dropdown (which I'm about ti fix just right now)
For your problem:
The list of available proton versions is generated once initially (and hopefully always when a proton version was added).
The temp list can be found under /dev/shm/stl/ProtonCSV.txt
Chances are high, that you have the same Proton version in multiple places and therefore it is listed twice.
Of course removing duplicates would be possible here as well, but the user will never see that duplicates are even installed, that's why I leave this as is.

[frostworx]

"removed the duplicate of the current selection in all dropdown menus" added in a5e8b5f

[UltraBlackLinux]

Hah, that is a different problem. I thought you mean that the current selection is listed twice in the dropdown (which I'm about ti fix just right now) For your problem: The list of available proton versions is generated once initially (and hopefully always when a proton version was added). The temp list can be found under /dev/shm/stl/ProtonCSV.txt Chances are high, that you have the same Proton version in multiple places and therefore it is listed twice. Of course removing duplicates would be possible here as well, but the user will never see that duplicates are even installed, that's why I leave this as is.

Oh yeah, I see. This is very annoying, as steam has a local root folder pointing to the steam folder (In my case it's on a separate drive) - That's another compatibility thing probably. - and stl detects the config folder, but also the drive itself:

proton-3.16-9;/home/maus/.steam/root/steamapps/common/Proton 3.16 Beta/proton
proton-3.16-9;/run/media/maus/Steam/steamapps/common/Proton 3.16 Beta/proton

Could you try to exclude /run/ devices when creating this file? The steam backwards compatibility hacks are probably never going to die

[frostworx]

This doesn't look like default behavior. Are any symlinks involved here?
If so please carefully list the exact symlinks involved, so I might be able (can't promise anything)
to remove any duplicates in the proton list, caused by symlinks.

[UltraBlackLinux]

This doesn't look like default behavior. Are any symlinks involved here? If so please carefully list the exact symlinks involved, so I might be able (can't promise anything) to remove any duplicates in the proton list, caused by symlinks.

╭─maus@lolcat in ~/.steam
╰─λ ls -la .
lrwxrwxrwx   23 maus 10 Oct 12:12  bin -> /home/maus/.steam/bin32
lrwxrwxrwx   33 maus 10 Oct 12:12  bin32 -> /run/media/maus/Steam/ubuntu12_32
lrwxrwxrwx   33 maus 10 Oct 12:12  bin64 -> /run/media/maus/Steam/ubuntu12_64
lrwxrwxrwx   21 maus 10 Oct 12:12  root -> /run/media/maus/Steam
lrwxrwxrwx   29 maus 10 Oct 12:12  sdk32 -> /run/media/maus/Steam/linux32
lrwxrwxrwx   29 maus 10 Oct 12:12  sdk64 -> /run/media/maus/Steam/linux64
lrwxrwxrwx   21 maus 10 Oct 12:12  steam -> /run/media/maus/Steam
.rwxr-xr-x 6.0k maus 10 Oct 14:04  registry.vdf
.rwxr-xr-x  204 maus 19 Jun 12:43  registry.vdf.bak
.rwxr-xr-x 2.9k maus 12 May 22:39  registry.vdf20200921204158
.rwxr-xr-x 2.9k maus 12 May 22:39  registry.vdf20200926222113
.rwxr-xr-x 3.3k maus 12 May 22:39  registry.vdf20201031212736
.rwxr-xr-x 3.5k maus 12 May 22:39  registry.vdf20201120232627
.rwxr-xr-x 3.8k maus 12 May 22:39  registry.vdf20201221162913
.rwxr-xr-x 4.0k maus 12 May 22:39  registry.vdf20210405213854
.rwxr-xr-x 4.2k maus 12 May 22:39  registry.vdf20210413215033
.rwxr-xr-x 4.6k maus 26 May 22:21  registry.vdf20210526222117
.rwxr-xr-x 4.2k maus  1 Aug 12:39  registry.vdf20210801123923
.rw-r--r--    7 maus 10 Oct 12:12  steam.pid
|rw-------    0 maus  3 Oct 16:22  steam.pipe
.r--------   16 maus 10 Oct 12:12  steam.token

I can't think of anywhere else... - Where is STL searching?

[frostworx]

Weird, I assume you didn't create those symlinks manually, did you?
Which distro is this?
Should be fixable, but not today. RL calls.

[UltraBlackLinux]

Weird, I assume you didn't create those symlinks manually, did you? Which distro is this? Should be fixable, but not today. RL calls.

I did not create these symlinks. I might just rename that folder and have steam recreate that. It's old as heck. I think I switched my steam folder 1-2 years ago on Manjaro. A few months ago I switched to Garuda Linux

EDIT: I really can't figure it out :/

[frostworx]

udisks2 automounts to /run/media, mayve this is not even the problem.
You wrote that the steam local root folder is "on a separate drive" in your case. Means you changed the path manually, right?
Do you have that separate drive also as additional steam library path? If So this would explain the duplicates.

[UltraBlackLinux]

udisks2 automounts to /run/media, mayve this is not even the problem. You wrote that the steam local root folder is "on a separate drive" in your case. Means you changed the path manually, right? Do you have that separate drive also as additional steam library path? If So this would explain the duplicates.

I didn't do it manually manually, I changed it in steam, back then when there was the old gui - I don't know how to do it in the new one, since I removed the /home/ entry last time, but in the new gui you can't do that anymore (I have no clue)?

[frostworx]

No problem.
readlink -f ~/.steam/steam/compatibilitytools.d does point to the corresponding /run/media path on your system, right?

[UltraBlackLinux]

No problem. readlink -f ~/.steam/steam/compatibilitytools.d does point to the corresponding /run/media path on your system, right?

exactly.

[frostworx]

ok, then I'll simply rewrite all related parts of getAvailableProtonVersions to always use the "readlink -f path", and filter duplicates afterwards (maybe not today)

[frostworx]

This commit 3bb44a7 should fix it already.

The previous fix for removing duplicates in dropdown menus leads to a (harmless?)
GLib-WARNING g_strcompress: trailing \ yad warning now, which requires a fix as well. fixed

[UltraBlackLinux]

This commit 3bb44a7 should fix it already.

The previous fix for removing duplicates in dropdown menus leads to a (harmless?) GLib-WARNING g_strcompress: trailing \ yad warning now, which requires a fix as well. fixed

Oh, seems like your attempt at fixing this wasn't too successful :/

experimental-6.3-20210930;/home/maus/.steam/root/steamapps/common/Proton - Experimental/proton
proton-6.3-7;/home/maus/.steam/root/steamapps/common/Proton 6.3/proton
proton-3.16-9;/home/maus/.steam/root/steamapps/common/Proton 3.16 Beta/proton
proton-5.13-6b;/home/maus/.steam/root/steamapps/common/Proton 5.13/proton
experimental-6.3-20210930;/run/media/maus/Steam/steamapps/common/Proton - Experimental/proton
proton-6.3-7;/run/media/maus/Steam/steamapps/common/Proton 6.3/proton
proton-3.16-9;/run/media/maus/Steam/steamapps/common/Proton 3.16 Beta/proton
proton-5.13-6b;/run/media/maus/Steam/steamapps/common/Proton 5.13/proton
Proton-6.15-GE-2;/home/maus/.config/stl/proton/custom/Proton-6.15-GE-2/proton
Proton-6.18-GE-2;/home/maus/.config/stl/proton/custom/Proton-6.18-GE-2/proton

The problem stil remains - Apparently your check didn't trigger:

Mon 11 Oct 08:04:53 CEST 2021 INFO - listAllSettingsEntries - '/dev/shm/stl/setentries.txt' already exists - nothing to do
Mon 11 Oct 08:04:53 CEST 2021 INFO - createDefaultCfgs - STOP
Mon 11 Oct 08:04:54 CEST 2021 INFO - initOldProtonArr - Creating an initial array with available Proton versions using the file '/dev/shm/stl/ProtonCSV.txt' which was created during a previous run
Mon 11 Oct 08:04:54 CEST 2021 INFO - initFirstProton - Initializing Proton
Mon 11 Oct 08:04:54 CEST 2021 INFO - initFirstProton - Initial Proton version 'FIRSTUSEPROTON' from '/home/maus/.config/stl/default_template.conf' is 'proton-6.3-7'
Mon 11 Oct 08:04:54 CEST 2021 INFO - getGameName - Found Game Name '"BeamNG.drive"' in '/home/maus/.config/stl/gamecfgs/id/284160.conf'

Oh I see. You are checking if the file contains the whole line (Which is never true when there are two locations), and not if the name already exists: This fixes it, I don't know how to open pull requests xD
1731 if [[ ! " ${ProtonCSV[*]} " =~ $protonfileV ]]; then

[UltraBlackLinux]

In this case the high boxes likely are a result from the pretty long winetricks packages list btw.

Regarding this - Four packages and still fat buttons.
The size of them seems to actually scale with the amount of text at the bottom - Compare this with the video:

[frostworx]

Oh I see. You are checking if the file contains the whole line (Which is never true when there are two locations), and not if the name already exists:

Nah, that's why I compare the readlink paths and not the original paths - this should be fine.
Your duplicates probably just came from an old /dev/shm/stl/ProtonCSV.txt.

Anyway find doesn't follow symlinks by default which needs to be fixed - else some proton version might not be found, so this needs some more attention anyway.

This fixes it, I don't know how to open pull requests xD

bad excuse!

1731 if [[ ! " ${ProtonCSV[*]} " =~ $protonfileV ]]; then

should work as well, but comparing the whole line $PCSV should be fine anyway

[frostworx]

The core problem of your duplicates is simply that the
(recently added) ~/.steam/steam/config/libraryfolders.vdf contains the base ~/.local/share/Steam as well,
where the previously used ~/.steam/steam/config/config.vdf doesn't.
Since someone reported, that their paths are only in libraryfolders.vdf, I check both everywhere.

(grep "BaseInstallFolder\|\"path\"" ~/.steam/steam/config/libraryfolders.vdf
vs
grep "BaseInstallFolder\|\"path\"" ~/.steam/steam/config/config.vdf)

A simple fix would be to remove the whole DEFSTEAMAPPSCOMMON check, but only if it is safe to assume that everybody has the base ~/.local/share/Steam in their config.vdf. Until then, I'll add a check in DEFSTEAMAPPSCOMMON

A filter for possible duplicates caused by (likely user created) symlinks is good to have anyway.

[UltraBlackLinux]

Oh I see. You are checking if the file contains the whole line (Which is never true when there are two locations), and not if the name already exists:

Nah, that's why I compare the readlink paths and not the original paths - this should be fine. Your duplicates probably just came from an old /dev/shm/stl/ProtonCSV.txt.

Nope. I deleted ProtonCSV.txt before trying my fix, and I can confirm, that it wasn't working before I put it in place.

[frostworx]

96ba751 looks good

• use the original path of all autodetected steam paths generally (might be helpful to be more distro independant)
• follow symlinks to find proton installations (and therefore trigger the previously duplicate removal everywhere)
• skip the separate proton check in base ~/.local/share/Steam if config.vdf has it as path as well

This and changes above should cover every possible combination of possible proton duplicates
(of course it still can happen that the version in the proton shipped version files have duplicates, so duplicates in the short list (dropdown) can still be possible, but they have different paths)

[UltraBlackLinux]

96ba751 looks good

* use the original path of all autodetected steam paths generally _(might be helpful to be more distro independant)_

* follow symlinks to find proton installations _(and therefore trigger the previously duplicate removal everywhere)_

* skip the separate proton check in base `~/.local/share/Steam` if `config.vdf` has it as `path` as well

This and changes above should cover every possible combination of possible proton duplicates (of course it still can happen that the version in the proton shipped version files have duplicates, so duplicates in the short list (dropdown) can still be possible, but they have different paths)

Works!
Close?

[frostworx]

.