I don't know if we are supposed to be able to install individual cores, but we have no code to do it, so remove the call that tries to call that missing code.
The text is now formatted as Lutris does in the game bar, and I've added a function to parse this.
It's a bit picky, but should tolerate localization at least.
Resolves#5151
This way, if you are using a flatpak, you can have a command that's several 'args' long, and for Linux it is 0 args log. The launch configs exe and args go on the end of that.
This should fix#5148
So, get_command() will return a suitable command for flatpak because the flatpak runner implements it to do so.
Linux returns [] for this now, since no prefix need be added to run a Linux game.
The rest just call get_command() to get the check that their exe exists.
When media download completes, we queue an idle function that queues a redraw of all windows. This should generally wind up being a single redraw per window once the drawing finally hits.
This way, you can use AsyncCall to download media and not provide a callback that redraw the windows.
If we found no files needed, we should skip ahead past the files page. Since the false return is now lost in the void of AsyncCall.
Instead, we'll just call launch_installer_commands in the callback.
The handlers log the error and continue; this prevents Lutris from crashing on startup, but leaves you insensitive to the system-wide dark-theme-light-theme setting.
We already handle errors this way for the TrashPortal.
I suspect the right answer here is to wrap DBus in some more civilized interface that could take care of this. But this commit will help until we figure that out.
If found a way to fake a repro; if an exception is handled after the installation starts, it needs to be handled with the error message page. This should not allow the back button at all - once the installation has begun there's no going back. But that page allows 'Back'.
So, turn that button off on that page.
You can't configure a combo box from a worker thread. And there's no reason to - this is used only for the MAME 'Machine' entry that spawns its own thread to populate a file with the data anyway.
We need to load each runner configuration, but we only do this for installed runners, and we cache the result until a runner config is changed to minimize performance impact.
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
