You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In general, if a user is not using an AppImage, then the path to their binary is stable, i.e., /usr/bin/wine64. If the user is using Proton though, a couple of things could move the location of that binary or require updating the path. This would require manually editing the config file, which works. But it still requires user modification. I have gotten around this on my system using Proton by creating a symlink at /home/thwright/bin/wine64 and /home/thwright/bin/wineserver. I no longer need to modify the config, but I now have to maintain the symlink.
We could automate this by allowing the user to trigger installer.choose_install_method() and utils.get_wine_options() from the control panel to update the binary path.
The trouble with using the existing code is that it assumes the menu being created should display all options (i.e., binaries and appimages) because it assumes this is a first run. Conditional logic should make this easy to get around by checking the WINEBIN_CODE config and only supplying binaries of the same code. Checking the WINEBIN_CODE config is necessary as I have seen issues in trying to switch from an AppImage to a binary or from Proton to a system binary. Perhaps there is something else going on.
A more heavy hammer would be cleaning the wine bottle of everything pertaining to the current WINEBIN_CODE, moving the Logos install to a backup, then rerunning the creation of the wine bottle as during a first install, then moving the Logos install from backup back into position, sort of a combination of set new binary and backup and restore.
Should we add such an option? How could we do it well?
The text was updated successfully, but these errors were encountered:
In general, if a user is not using an AppImage, then the path to their binary is stable, i.e.,
/usr/bin/wine64
. If the user is using Proton though, a couple of things could move the location of that binary or require updating the path. This would require manually editing the config file, which works. But it still requires user modification. I have gotten around this on my system using Proton by creating a symlink at/home/thwright/bin/wine64
and/home/thwright/bin/wineserver
. I no longer need to modify the config, but I now have to maintain the symlink.We could automate this by allowing the user to trigger
installer.choose_install_method()
andutils.get_wine_options()
from the control panel to update the binary path.The trouble with using the existing code is that it assumes the menu being created should display all options (i.e., binaries and appimages) because it assumes this is a first run. Conditional logic should make this easy to get around by checking the
WINEBIN_CODE
config and only supplying binaries of the same code. Checking theWINEBIN_CODE
config is necessary as I have seen issues in trying to switch from an AppImage to a binary or from Proton to a system binary. Perhaps there is something else going on.A more heavy hammer would be cleaning the wine bottle of everything pertaining to the current
WINEBIN_CODE
, moving the Logos install to a backup, then rerunning the creation of the wine bottle as during a first install, then moving the Logos install from backup back into position, sort of a combination ofset new binary
andbackup and restore
.Should we add such an option? How could we do it well?
The text was updated successfully, but these errors were encountered: