Notably, for 'bool' values. This did seem to work, as sometimes defaults got preloaded into the config. But not always, so let's consistently handle defaults for all option types.
The frames around config options no longer disappear when they contain only one options; instead options appear in frames if they have a "section" option set for them, and not if they don't.
Some things don't, but if we want to put every option in a frame, we can do that now.
This is really while the prelaunch stuff is happening; there's no obvious way to wait until the game is really up and running.
Since this is often very quick, the animation will always perform one cycle, even if it goes directly to STATE_RUNNING.
This was the only option to use the 'scope' feature, and in 0.5.14 it was available in system and runner options, but not games.
This fix restores that behavior.
The trick is to pass the config_level through to the various option boxes, not just the config_section. The first is which dialog you are in (roughly) and the second is which tab.
We'll stop the game process (lutris-watcher, I think that is) and also any new process started since the game started, but those are counted only if they have the magic LUTRIS_GAME_UUID env var and also mention the game directory in the command line for the process.
Resolves#5181
This fixes the bug where the Wine app-usage dialog can't be closed with its 'OK' button.
This commit moves on_response() up to the 'Dialog' base class and override it in a few places where this is required.
'response' is how dialogs close, 'delete-event' doesn't even fire for them, so I've removed this event handler from the dialogs.
This is a bit baroque, and maybe we should just not just the TrashPortal for runners. But it is an 'uninstall' and I don't want to be too much of a crazy axe murderer with deletions.
The problem is that the UI updates must wait until the runner folder is gone, because that is was triggers self.is_installed to become false; if we emit early the UI see no change and does not change itself.
So, this defers the signal via a callback given to TrashPortal. The UI does not try to update until the folder is gone, and all is well.
This log message is excessive, but may help with troubleshooting #5174. Need to back this off before release. I'd use the debug flag here, but it's not initialized soon enough.
There are several places where we need the directory deleted now, not asynchronously, because we are about to replace it. I think these are in places where deletion is okay - stuff like installing runtime updates.
Also, I put deletion of temp directories back on the deletion plan. I don't think anyone wants to see our temp files in the trash.
It can't tell if the folder was deleted without blocking for it, but no users of it actually care about this.
Also, beef of TrashPortal error handling so exceptions (from say opening the file) don't crash Lutris.
Also, also, add callback functions so if we do need to do something with errors or after deletion is complete, it's possible to do that.
There's a spacing of 12 px from the base class, we'll use that alone, and it all lines up nicely. It also makes it a little bit tighter; not a bad thing since the updates box doesn't fit vertically.
Also some spelling and warnings.
By tracking the names of the updaters that are running, we can make sure we never enqueue any one twice at the same time.
But you can start checking for Wine updates while runtime updates are running, if it's not in the queue already. Or vice versa.
