Have addnonsteamgame GUI reopen after adding game

[CartoonFan]

System Information

• SteamTinkerLaunch version: steamtinkerlaunch-v14.0.20241003-2
• Distribution: Arch Linux

Feature Description

Hey there! Sorry for taking so long--I got sidetracked by a bunch of different things--but I thought I'd make an issue to request letting the addnonsteamgame GUI reopen after adding a game, per #968 (comment).

That's it! Nothing much else to add this time 😅

[sonic2kk]

Yeah, this is a good idea, I stand by my reply there still :-)

I think it really comes down to, how will we handle this. I can't remember what I was thinking at the time, but I guess we have the following options:

• This could be a separate button on the dialog at the bottom, like "Add and Re-Open" (probably with a better name). This would close the dialog, perform all the Add Non-Steam Game Logic, and then when complete it would re-open the dialog.
• It could be a checkbox, like we have to re-open SteamTinkerLaunch after a game runs (maybe this is what I was thinking on how to implement this). It could be called something like "Re-open dialog". But I feel like is more likely to be missed. But this would be acceptable and possible to implement.
• We could have a button on the dialog separate from the dialog action buttons at the bottom. This would be in the "form" (similar to what we have for the Winecfg and Winetricks buttons for One-Time Run), and when clicked would keep the dialog open but perform the adding operations. This is my least-preferred option, as we can't clear the dialog fields (so less visual feedback and the user would have to manually clear out the old data) and we could potentially run into some problems if the user tried to add a new game too quickly before the old one finishes (and there's no good way to display to the user that this has completed).

Those are my preferences in order. Most preferred would be a new button to close and then re-open the dialog after. The middle option is also feasible but a bit less intuitive in my personal opinion (but maybe others have different thoughts), and while in an ideal world we could keep the dialog open and let the user start filling in new information while the previous game is in the process of being added, I just don't see that being feasible with Yad.

If you have any other thoughts on how to do this from a UI perspective, let me know! There may be another approach I'm not thinking about.

[CartoonFan]

Honestly, I don't have too much of a preference on this one 😅

I'm fine with having it as a separate button if you want 👍

There are a couple of things I'm still curious about:

• When the GUI reloads, do you think it's better to clear the previous data, or leave it there? I'm thinking it's the former--based on what you said in the other issue--but I'm wondering what you think 🤔

• Again, partially from the other issue's comment: would arguments passed on the commandline also apply to the reopened window? I'm not really sure which approach would be best, in general 😅

Sorry for not replying right away, too 😅. Besides gaming, I've been considering using Pegasus Frontend as a side approach to putting all my games in one place and making them easily accessible 😅

The program itself seems pretty feature-rich--despite using Qt 5 instead of Qt 6--but the features have to be implemented through themes, and most of the features seem to be optional--which means that I'm sort of dependent on others for both style and functionality, unless I make my own theme 😓

Besides that, it seems like the game metadata would largely have to be entered by hand, which is quite an initial burden 😓

On Linux, the app can reliably load from Lutris and Steam, and supports start and end scripts--but metadata might still be a thing, and one of the improvements I could see on what Steam does is being both informative and appealing--something that would both tell me what a game is like and maybe make me want to play it, if that makes sense.

There's a scraper program here that's supposed to be compatible, but it just crashes on me 😞

Anyway, I know that's not your program, but I thought you might be curious 😆

Thanks again! 👍 💜

[sonic2kk]

No worries about not replying, we all do this when we can. I haven't had nearly as much time or motivation lately, don't feel bad about leaving this for a couple days 😄

When the GUI reloads, do you think it's better to clear the previous data, or leave it there? I'm thinking it's the former--based on what you said in the other issue--but I'm wondering what you think

Clearing it is the most straightforward. We could potentially keep it but it would be significant work. We would need a couple of things, which aren't bad features in themselves. We would need to be able to pass data to the UI function, and open the UI with that data populated. We'd need to be able to call AddNonSteamGame --arg1 val1 --arg2 val2 and then open the GUI with those values populated. The SteamTinkerLaunch function here calls the same functions as running from the commandline, so the commandline usage would also benefit here.

This is not a bad feature, I would like this at some point, but we'd need to because to do two things:

• Differentiate when a user wants to open the GUI if they provide all the data, and when they want to run the command. We could most easily do this with a command, something like --gui. This way if we provided a full command we would populate the UI rather than running the command.
• Add a way to parse that data from the commandline if it is passed, basically implement the above where it can take that data passed and load it into the GUI. This would be a bit of effort as we'd need to refactor how we check and populate the variables. Probably not too difficult, but effort.

Implementing this is an entirely separate piece of work, and personally I would prefer if this functionality wasn't present when reloading the Add Non-Steam Game GUI. So while this is functionality I would want, I wouldn't want it in this context. I think it's better to open again in a clean slate.

Perhaps some data could be carried over, like some installation path, although ideally Yad would remember the previous path it opened a dialog at and set that, so even if the path was blank, when you browse to the path, the last one you selected would be loaded.

Again, partially from the other issue's comment: would arguments passed on the commandline also apply to the reopened window? I'm not really sure which approach would be best, in general 😅

Eventually yeah, maybe you got the idea with my above spiel 😄 I would like these to carry over eventually, but that's independent of this work I think.

[CartoonFan]

No worries about not replying, we all do this when we can. I haven't had nearly as much time or motivation lately, don't feel bad about leaving this for a couple days 😄

Thanks for understanding 😄

Really, I can see the potential merits of both approaches, so I can't argue too hard for one side or the other. I'm just trying to think what might be best for myself--as a user, since I'm not a developer (I mean, you're a user, too, but hopefully you get what I mean 😅). I have quite a few Non-Steam games--and it looks like I'll be doing a lot of typing either way--so anything that can make the process easier would be my goal at the moment.

Hope that makes sense 🙏 💜