If you multi-select, we will have a single common multi-category dialog. This can lead to overlap, where a game categories are in two windows. This doesn't seem to cause any real problems.
Also, move the game count into a subtitle so it fits better.
This is in case you do not realize the dialog is for >1 game; it will warn even if only one is being changed. If you are viewing 1 game and change it, no warning since that is the expected case.
This way if you try to use the Categories command while the window is open, it can just adopt additional games.
Though without a game list, it's hard to know what the dialog will actually do.
When a category is applied to some but not all selected games, an indeterminate checkbox shows. Click it and it becomes determinate (and checked).
On save, any remaining indeterminate categories are skipped, but we work out what categories are to be added or removed for each game in turn.
Resolves#5372
We'll load the latest Wine if you have the 'runners/wine' directory, but not if you do not.
The 'Update' button provided in preferences now pre-creates this directory if it is missing, enabling the update to proceed.
- Kills the wineserver process associated with the running prefix via the `wineserver` command in the UMU-Proton directory instead of wineboot which had lead to unreliable results
When the hidden column was removed from the games table in schema.py the setting of the column value was never removed from installer.py
This meant on a fresh Lutris install user's cannot install games and are met with "table games has no column named hidden" errors.
This cleans up that incorrect setting of the column value.
It really needs to be, or it's just useless - resulting in a UI error and potentially multiple threads syncing at once.
The problem is that _IS_LOCAL_LIBRARY_SYNCING is now a mutable global, and in Python this is treacherous. 'from x import G' copies G into scope, which is bad news for a global like this.
'import x' followed by 'x.G' works, but this is real dark corner, so I've added a global function just to read the global variable; it reads the original, not a copy, even if you copy the function reference into scope with 'from x import f'.
So this works without making LibrarySyncer a singleton.
The problem is that we often have .AppImage instead of the more Unixy .appimage, but the later occurs too.
So, We'll tolerate whatever CrAzY Casing you can come up with.
Resolves#5396
