Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One-Time Run Improvements #788

Closed
6 tasks done
sonic2kk opened this issue Apr 14, 2023 · 2 comments
Closed
6 tasks done

One-Time Run Improvements #788

sonic2kk opened this issue Apr 14, 2023 · 2 comments
Labels
enhancement New feature or request Initiative Issues detailing a significant set of features/enhancements

Comments

@sonic2kk
Copy link
Owner

sonic2kk commented Apr 14, 2023

System Information

  • SteamTinkerLaunch version: git
  • Distribution: Arch Linux

Feature Description

There are various improvements I want to implement for the One-Time Run dialog. As there are several, I feel it would be useful to list them here.

When features from this list are implemented, I will add their PR hash into the subheading. I am currently working on an overhaul of how One-Time Run is written in #786 to allow for the first item in this list, command-line usage, so further changes should probably wait until that is merged, if at all (hopefully it will be though 😉)

UPDATE 11/06/23 - Out of nowhere, One-Time Run now seems to require STEAM_COMPAT_CLIENT_INSTALL_PATH="$SROOT" to be set. MO2, Vortex, and custom commands still appear to work fine. This was fixed as part of #833.

Command-line usage for One-Time Run (#786)

Allowing full One-Time Run usage from the command line would be pretty sweet. It is currently possible to use steamtinkerlaunch otr but it isn't documented on the help page. More than that, it just opens the GUI. I want the ability to fully run something from the command line with STL.

This would be pretty handy for automation as well. An option to execute the One-Time Run command based on saved values would also be pretty useful I think as well, if enough are saved. That way automated scripts could be implemented, and it could be useful for #625, if/when that gets implemented.

Defaults Button (#833)

Reset any saved parameters for the One-Time Run GUI by writing out blank values to the game config. There is currently no straightforward way to "clear" values from the frontend, this is especially a pain for the working directory dropdown. This option should also clear any "saved" values.

This should be fairly straightforward to add.

Native Linux program support (#801)

One-Time Run only supports running with Proton at the moment. It should be possible to check when we are given a native Linux binary, and to ignore the Proton version. Language files will probably need updated slightly to reflect this, off the top of my head it would be nice of the Proton dropdown mentioned explicitly that this will be ignored for native Linux programs.

Custom commands already have some logic to differentiate between a native Linux binary and a Windows binary, so we should be able to reference that implementation for this feature in the One-Time Run logic.

Force Proton for Custom Programs (#801)

Once the above native Linux binary support is implemented, there may sometimes be issues. The logic for differentiating Windows and Linux programs isn't perfect, as shown by #710. It seems Windows binaries built on Linux (apparently a rarity, as only one user has reported the problem 😅) report different information and there is no solid way of telling them apart

To resolve the issue, 77e0772 added a checkbox to force Proton. We should add something like this to the One-Time Run menu as well. However it should be noted that adding an extra checkbox here will change the order of the form elements, so that will need to be considered when implementing this.

Overhauled User Interface

The One-Time Run GUI currently uses the Yad form layout. This worked in the past, but has become a little more cumbersome to work with behind-the-scenes. Given that the work outlined here will also expand the menu even more, it might need a bit of the same treatment that the GameScope menu got for v12.12 (#722).

The user interface was deemed acceptable as no new features are planned for One-Time Run. If this changes in future, a GUI overhaul for it can be revisited.

Use Steam Linux Runtime with Custom Command (#826)

Issues regarding the Steam Linux Runtime were resolved with #737. Things may change in future and we may be unable to get the SLR again, but for now it is working, and for me it has been quite reliable (allowing it for Non-Steam Games even fixed an issue with them for a user, see #772). It would be useful to allow it for One-Time run as well, though we should be cautious as sometimes it causes issues.

This option should be disabled by default. Some tweaking of the logic may be needed, to check SLRCMD (which is what setSLRReap sets). It may be worth breaking this SLR fetching logic out somehow at some point, if it is too hacky to implement with SLRCMD in the One-Time Run menu.

As well as this, we should confirm that a command using/not using One-Time Run does not interfere with the SLR options on the Game Menu. Perhaps storing the value of SLRCMD and resetting it before execution would be an option, if we don't break the SLR fetching out into a separate function in the meantime.

Notifier Usage (#834)

It is not immediately obvious when a One-Time Run may fail; if the Proton version is invalid for example, it will be logged, but we could easily show the notifier/use echo (for command-line usage) to tell users what went wrong.

Use Wine with One-Time Run

An option to use Wine versions with the One-Time Run would be nice as well. Likely, this would have to be a separate checkbox. It may be best to refactor the One-Time Run menu when it comes time to add this, to have two headings: A "General options" and a "Wine options". Not sure though, maybe just a checkbox and a dropdown on the current UI would be fine.

Building the launch command for One-Time Run would need to be changed somewhat as well, to account for the Wine path versus the Proton path. Shouldn't be too difficult though, just a bit of a delicate refactor. Testing will be needed to ensure nothing breaks here; Proton and Wine should both work and not conflict.

It was decided that One-Time Run and Wine is not feasible because of the limitations with running applications with Wine in a Proton prefix.


Progress List:

@sonic2kk
Copy link
Owner Author

sonic2kk commented Jul 7, 2023

Adding an option to use Wine might be difficult given the limitations of using Wine in a Proton prefix.

@sonic2kk
Copy link
Owner Author

sonic2kk commented Jul 8, 2023

I think the One-Time Run GUI is fine how it is, so no GUI overhaul required.

As mentioned, running with Wine is probably a non-starter. So this can probably be closed now. Lots of work went into this over the last couple of months and I'm quite proud of how OTR turned out. I think it's a lot more useful now, at least I get a lot more use out of it :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Initiative Issues detailing a significant set of features/enhancements
Projects
None yet
Development

No branches or pull requests

1 participant