Custom Gamescope arguments get overwritten

[sonic2kk]

Problem

If you pass a custom argument to Gamescope from the Game Menu and then edit some options in the Gamescope menu, the custom Gamescope arguments get overwritten by only the flags selected in the Gamescope UI. Normally, this wouldn't really be a problem, as those that edit Gamescope options probably aren't going to use the Gamescope menu anyway, so it would be a relatively minor issue.

Real world use-case

What makes this slightly less of a minor issue is a bug with Gamescope and Proton 7.0 (ValveSoftware/gamescope#438, ValveSoftware/gamescope#420) that can be resolved by passing the -e flag. This flag is for "Steam integration," though there is not meant to be a reason for a user to use this flag as far as I know (I saw it from someone on the Gamescope project, but I can't find the comment now). The bug also affects GE releases of Proton.

The official description of the flag in gamescope --help is as follows:

-e, --steam                    enable Steam integration

It is probably not really the responsibility of a project like SteamTinkerLaunch to manage working around bugs in upstream like this. Trying to solve this specific issue has a few challenges too:

• Passing -e breaks non-Steam games
• Passing -e silently may work fine for Steam games for now, but its behaviour may change in the future, so passing it even silently may be a problem
  • If a user removed it too and their input stopped, they may be confused as to why it stopped
• Having an option for -e in the Gamescope menu may be confusing, because the behaviour may change in the future while for now it is used to workaround a bug

Potential Solutions

With this use-case out of the way, my main reason for creating this issue is to at least document that SteamTinkerLaunch currently overwrites any custom Gamescope arguments once the Gamescope UI is used and "Done" is clicked (triggering an update of the Gamescope arguments).

Fixing this may be challenging, but I see a few possibilities:

• Implement a setting for every Gamescope option, hiding more advanced settings under a dropdown (is this even possible with yad?). This would require some work and may be unreasonable, most of the Gamescope flags are probably not useful to the average player.
• Display a Gamescope arguments textbox on the Gamescope menu. This may be problematic as whenever an option is selected (such as enabling fullscreen), the box would need to update. To my understanding, with the way the Gamescope menu works currently, a display value would need to be used for this textbox and then that would be written out as the actual Gamescope argument value. I'm not even sure if this kind of behaviour is feasibly possible with yad, and is giving me a headache just thinking about it 🤯
• Update the wiki to note Gamescope overwrites custom arguments. The input workaround with the -e argument could also be mentioned. I could update the wiki to include this information as I'm already working on updating the Gamescope wiki 🙂

I'm no expert with the technologies used here, Gamescope or STL, so there could be a much simpler solution to this. I'm just outlining the problem and potential fixes I could come up with hopefully to help development 😄

[frostworx]

Hi, thanks for the report!
Unfortunately this is almost impossible to fix.
The cause for this behavior is indirectly yad:

No offense, yad is nice (imho), but not built for huge complex guis:
The main reason here is, that you cannot simply start internal functions from a regular push button
(so f.e. all those, which are on the top of the main settings menu), but only from the main gui buttons (those at the bottom of every window - f.e. "PLAY").
To workaround this, the upper buttons call an external (2nd) steamtinkerlaunch instance with specific command line parameters (in this case: steamtinkerlaunch gs to open the gamescope window)
Of course the main (1st ) steamtinkerlaunch instance doesn't know what was changed using the selected button and therefore the changes made are available after a new start.

I already had multiple other issues with yad before:
it is kind of able to work with tabs (which once were used in an older steamtinkerlaunch build), but unfortunately the implementation is (imho) kind of "hacky", because it merges multiple yad instances into one window by joining them with some gtk black magic and multiple pids. This would not be the problem, it worked fine, but unfortunately this construct is not wayland compatible (I opened an upstream bug back then), so I rewrote the whole gui system.

I would love to rewrite pretty much every gui element to look better and make it better usable, but yad is really the handicap here.
yad is by far the best gui framework for bash scripts, but for monsters like yad it is not flexible enough.
(whenever a different, better framework for bash scripts rises, I'd rewrite it, when I still work on this then :))

If I knew earlier how big steamtinkerlaunch will become, I would not even have started it with bash, but with cpp using a qt gui, but that train left long ago.

Also, not sure if you have seen in the code how the flexible menus are created in steamtinkerlaunch (so, f.e. the favorites menu or all category menus), but it is extremely complicated and an absolutely crazy implementation, which nobody should have to write to workaround missing gui features.

I'm afraid solving this via gui is nearly impossible (yeah, advanced settings would have been a dream for steamtinkerlaunch, I doubt this is possible, but I don't say that I know it is impossible, because many yad features are kind of easter eggs and you do not find that many different examples on the web what yad can do)

Thank you very much for writing a new gamescope wiki! Like many other wiki entries the current one is terrible :)
I think a combination between a note in the wiki and an additional gamescope option with a note in the tooltip would be the best option here.
(did you know btw, that the wiki for almost all steamtinkerlaunch windows can be opened by pressing F1 when the window is open? this only works though, when yad has built-in webkit support)

[sonic2kk]

Yeah, I've seen a similar sentiment, that yad is not really great for more complex UIs. I can see now why it might be pretty tricky to stop the arguments being overwritten, it may be difficult to know what the existing Gamescope arguments actually are without some hacky implementation. The overwriting shouldn't be too much of an issue overall for most users, once the Gamescope issue is fixed.

but unfortunately this construct is not wayland compatible

Much appreciated for looking out for those of us on Wayland! 😄

I think a combination between a note in the wiki and an additional gamescope option with a note in the tooltip would be the best option here.

Sounds good to me as well 🙂 I actually did end up finding the comment that said the -e option currently does not have any user-facing changes with any publicly available versions of Steam. I will include reference to this in the updated wiki page as well.

did you know btw, that the wiki for almost all steamtinkerlaunch windows can be opened by pressing F1 when the window is open?

Oh wow I just tried it and that is cool! Thanks for the tip!

From the overarching issues with yad here, I'm definitely inclined to agree that fixing this is likely at least unreasonably challenging and unnecessary given the development costs. I'm not sure if I should close this issue or not, so I'll leave that up to you :)

[frostworx]

After you have already fixed it anyway, I think this can be closed here :)

On the other hand, I think this issue explains for the first time, why the steamtinkerlaunch gui is structured and "complicated" as it currently is.
I know many people don't like steamtinkerlaunch for that, but giving above reasons, it would be impossible for them
to suggest or offer a better alternative if they tried to. 🙄