Do not create multiple library views and remove the ability to switch
between them on the fly. Add an option in settings to select the preferred
view. The view will be used the next time Rare is started.
* Add an option to select the library view mode.
This will allow us to instantiate only one library view at startup,
reducing time and complexity of the process.
* Remove base Qt translations from repo, load translations from Qt itself
* Prefix translation `qm` files with `rare_`.
* Rename `translation_source.ts` to simply `source.ts`
* If the selected language matches the system local, remove the option from the configuration.
* Instead of using legendary's locale as fallback, use system't locale
as default.
* Do not hardcode language names and countries but use QLocale on
the translation filenames.
Also add a dialog to select optional downloads before verifying
and refactor the move widget into a full-fledged dialog.
To keep dialogs in a common format and allow them to share the same
properties, three classes of dialogs have been implemented inheriting from
each other.
The classes are `BaseDialog` -> `ButtonDialog` -> `ActionDialog`
* Basedialog: is the basis of all dialogs and is responsible for
rejecting close requests from the window manager and the keyboard.
It also restricts access to `exec()` and `exec_()` because they are harmful.
It serves as the basis of Launch and Login dialogs
* ButtonDialog: is offering buttons for accepting or rejecting the presented
option. It implements its own buttons and exposes abstract methods to
implement handling in them. It restricts access to `close()` because these
dialogs should always product a result.
It is the basis of Uninstall, Selective dialogs.
* ActionDialog: in addition to the ButtonDialog, it offers an action buttom
with to validate the form or to make the dialog unable to close. It serves
as the basis of Install and Move dialogs.
Accordingly all dialogs in Rare have been updated to use these classes.
The default widgets only implement the settings for the `default` "app_name"
The game specific widgets sub-class the default widgets and implement
whatever they additionally need locally.
Remove multiple calls to save config and save when the game settings gets hidden.
* Use `vars()` instead of directly accessing `__dict__`
* Remove `auto_update` from RareGame's metadata
* Correct check for updating the Steam App ID (We want to keep any changes from the user)
* Collect both Wine and Proton prefixes when removing overlay registry keys.
* Add few convenience functions in config_helper and paths.
This allows compatibility tools that use the SteamAppId environment
variable to make decisions or apply fixes do their job more accurately.
Also use the stored variable to provide a link to protondb through
the grade label in GameInfo.
The steam grades now use the orjson library to load Steam's ~6MB
database faster.
Add a sub-application to Rare to launch the webview for logging into EGS.
The sub-application operates similatly to the `laucher` sub-application and
it is autonomous. After a successful login in returns the exchange code
to the standard output to be parsed and used by the login dialog.
The reason this implementation was chosen is because when pywebview uses
pyqtwebengine as the GUI library, we cannot launch it through Rare as
it tries to spawn a QMainWindow inside an existing event loop, which is
prohibited by Qt.
Despite that, EGS login page doesn't work correctly with QtWebEngine,
so on linux default to the GTK backend for pywebview, and this change
helps keeping applications using different toolkits separate.
At this moment, spawning the sub-application blocks the execution of the
main application.
This change should make it easier to authenticate through Rare inside
a gamescope session, such as the steam deck.
* Don't create path when preparing overlay download, it fails on updates.
* Concatenate the overlay install path in InstallDialog instead of passing it as `base_path`
* Respect RareGame state in in the EOS overlay form
InstallDialog uses that property so RareEosOverlay should have it too.
Also calculate the base_path for the overlay case instead of passing it as
argument
Yes, we are back at this. Entitlements are important to have early
as Ubisoft redemption requires them, and they don't depend on anything
else.
* Move config helper initialization into RareCore to make it available
earlier.
* Add options in settings to not request non-asset games and entitlements.
This greatly improves startup time but reduces functionality a bit. Both
options are disabled by default.
* Remove the old options to exclude Win32 and Mac games as they were no longer relevant.
* Add a performance context manager to log execution time when used.
* Fixed an issue with UbisoftGroup where multiple threads would spawn.
* Uninstalling the Overlay now goes through the same procedure as
uninstalling any other game.
* The available prefixes are now listed instead of hiding them inside
a combo box.
* Each listing works indepedently to enable/disable the Overlay for the prefix
The new methods are the following
* `has_update`: to check for updates
* `is_enabled`: checks if the overlay is enabled (on wine platform, on prefix)
* `enable`: enables the overlay (on wine platforms, on prefix, for app_name)
* `disable`: disables the overlay (on wine platforms, on prefix, for app_name)
* `install`: Install using Rare's existing facilities
* `uninstall`: Uninstall using Rare's existing facilities
Because there are two dialogs for editing optional downloads, refactor
the separate implementations to select them into a common reusable widget
and use it in SelectiveDialog and InstallDialog.
To keep dialogs in a common format and allow them to share the same
properties, three classes of dialogs have been implemented inheriting from
each other.
The classes are `BaseDialog` -> `ButtonDialog` -> `ActionDialog`
* Basedialog: is the basis of all dialogs and is responsible for
rejecting close requests from the window manager and the keyboard.
It also restricts access to `exec()` and `exec_()` because they are harmful.
It serves as the basis of Launch and Login dialogs
* ButtonDialog: is offering buttons for accepting or rejecting the presented
option. It implements its own buttons and exposes abstract methods to
implement handling in them. It restricts access to `close()` because these
dialogs should always product a result.
It is the basis of Uninstall, Selective dialogs.
* ActionDialog: in addition to the ButtonDialog, it offers an action buttom
with to validate the form or to make the dialog unable to close. It serves
as the basis of Install and Move dialogs.
Requesting the pixmap in `paintEvent` only loads the
pixmap when the widget first becomes visible, making loading
the library smoother. Also avoid spawning multiple singleshot
QTimers and use QObject's internal timer, with CoarseTimer precision.
Also set some more defaults for legendary because Rare lacks support for
them. Forced at startup.
* Set `disable_auto_crossover` to `false` because we don't support CX yet.
* Set `egl_sync` to `false` because issues.
This property reports the default platform to use for a game based
on legendary's configuration and if they platform is available in the
game's assets.
Using that property we can make better choices on what platform to operate
on without user intervention. Currently we use it to infer the platform
in when installing, importing, and calculating game versions.
* Infer the displayed to reflect where the affected directory is
If base_path is set outside of InstallDialog, display that.
If the game is already installed, show the installation directory
If neither of the above is true, use legendary's inference based on
the default platform if the game supports it. Fallback to Windows.
* Disable irrelevant and potentially harmful options when the game is
already installed, such as the installation path, the platform selection
and creating a shortcut.
* Infer the correct platform based on the existing installation. If it
is not installed, use the default platform if the game supports it and
fallback to windows.
* Move the horrible lambda used to populate the error box when the
platform was unsupported into a separate method.
