This is the last change of the `backend_refactor` branch. This makes
`RareCore` the centerpiece of Rare by moving initialization before the UI
is brought up. RareCore is now in control of creating and querying `RareGame`
objects, re-introducing the ability (incomplete) to refresh the games library.
As a result, ApiResults has been removed.
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
There are DLCs (for example KingletAztec) which are essentially
entitlements, a single file the allows access to already downloaded
content. Updates for such DLCs only change the metadata version number
without any actual new data. These DLCs are handled correctly by the
DLM, but our dialog would refuse to allow installing them due to 0 download
size. This change allows them to pass through the InstallDialog.
The other issue, which I don't know if it was only a result of our faulty
validation at startup or could occur in legendary too, is that a DLC might
be marked with needing verification. Currently we don't have a way of
verifying DLCs, so when verifying the game, we will also set the same
state for any installed DLCs. In effect verifying the game successfully
will also mark any DLCs as correct.
Note: the `__update_widget()` method, while it doesn't have any visible delay
has the potential for improvement. I didn't do it because it felt like
premature optimization.
MoveGamePopUp: update it to use RareGame and it's signals
RareGame: Add `install_path` attribute and change `needs_verification` setter
Now both setters will update the local `igame` attribute and save it too.
MoveWorker: Update it to use RareGame.
Other changes include moving "same-drive" moving into the worker and using
`os.path` methods instead of `PathLib`
SteamGrades: Remove worker, it is implemented in RareGame now.
The `status_label` displays what is currently going on with the game.
It reflects the current operation running on it or if it requires special
attention (update, needs verification etc)
The `tooltip_label` displays hover information such as what happens
if a part of the widget is clicked or in the case of the launch button if
the game can run (without version check, offline etc)
The context menu on the widgets will be updated and populated according
to the installation state of the game. Since the context menu was revised
the shortcut creation code was revised too to make it more compact.
the `create_desktop_link` and `get_rare_executable` functions are moved
from `rare.utils.misc` to `rare.utils.paths` to avoid cyclical imports and
better grouping. Two functions are added, `desktop_link_path` to uniformly
calculate the path of the shortcut and `desktop_links_supported` which
checks if Rare supports creating shortcuts on the current platform.
`desktop_links_supported` should be used as safeguard before `desktop_link_path`.
Desktop links are currently untested on Windows but if `shortcut.Description`
works as expected, it should be good to go.
`LegendaryCore.get_non_asset_library_items()` returns the same tuple
for `game_list, dlc_dict` as for regular games with assets, so
keep the result for API completeness, since `RareGame` can handle those
games properly.
While not sure if it is required, add an expiration date to the prepared
download 30 minutes after it was prepared. If a download has been in the
queue for more than 30 minutes, the download will be prepared again silently
before starting.
Return only the `InstallOptionsModel` in the result of the download thread
to avoid the potential mistake of re-using it. This required for the tray
notification signal to operate on the `app_name` instead of the `app_title`.
As a result, the notification slot was moved into the TrayIcon class for
better encapsulation.
They are used to insert and remove updates from downloads when
the installation of a game changes through `RareGame.set_installed`.
They piggy-back the signals with the same names in `GlobalSignals`
When importing a game from EGL, also check
Similarly to the installation procedure, when an uninstall is
requested, an `UninstallOptionsModel` is emitted by the `RareGame`.
`DownloadsTab` handles the signal and spawns the `UninstallDialog`.
After the `UninstallDialog` is closed, a worker thread handles
uninstalling the application to avoid UI lock-ups when a large
number of files is deleted.
Allows for uninstall actions to be spawned from anything having
access to the `RareGame` instance.
LaunchDialog: Don't check health on DLCs, they always will require
verification if they don't specify an executable.
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
When updates are queued, they are removed from the update's list. An exceptions is made
when the queued item comes from repairing (without updating), in which case the update is
disabled for the runtime.
A queued item can be either removed (if it is an update it will be added back to the
updates groups) or forced to be updated now. If a queued item is forced, the currently
running item will be added to the front of the queue. Downloads will be queued if
there is no active download but there is a queue already.
The download thread is now responsible for emitting the progress to `RareGame`
InstallDialog: Pass `RareGame` and `InstallOptionsModel` only as arguments.
The `update`, `repair` and `silent` arguments are already part of `InstallOptionsModel`
`RareGame` is used to query information about the game.
InstallInfoWorker: Pass only `InstallOptionsModel` as argument
Emit `InstallQueueItemModel` as result, to re-use the worker when queuing stopped games
RareGame: Query and store metadata property about entitlement grant date
RareGame: Add `RareEosOverlay` class that imitates `RareGame` to handle the overlay
LibraryWidgetController: Remove dead signal routing code, these signals are handled by `RareGame`
Directly parent library widgets instead of reparenting them
GameWidgets: Remove unused signals
EOSGroup: Set install location based on preferences and use EOSOverlayApp from legendary
GamesTab: Connect the `progress` signals of dlcs to the base game's signals
GamesTab: Remove dead code
GlobalSignals: Remove `ProgresSignals`
RareCore: Mangle internal signleton's names
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
The `GameProcess` class now acts as a persistent member of `RareGame`
that can be re-used for launching games. Its signals are handled and
repeated by `RareGame`.
Implements launching directly into `RareGame`
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
In the same vain, move `rare/game_launch_helper/message_models` into `rare/modes` since it is used in both the server and the client side.
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
Consistency is achieved by always updating the shared metadata dictionary
before writing it to the disk.
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
This merges a few of the internal features of RareCore such us
RareGame filtering and thus game grouping based on attributes.
This is required to properly connect a single signal from RareCore to
the downloads tab for game installation. This also includes filtering
games based on updates and other attributes.
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
Removed `rare.utils.legendary_utils`, the `uninstall_game` function
was moved to `rare.shared.game_utils` for now
Signed-off-by: loathingKernel <142770+loathingKernel@users.noreply.github.com>
