Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lutris: Add Basic Games List #192

Merged
merged 5 commits into from
Feb 22, 2023
Merged

Conversation

sonic2kk
Copy link
Contributor

This PR adds a Games List for Lutris, adjusting the data displayed to be relevant to Lutris games 😄 It displays games from all runners except Steam (as we already display Steam games in the Steam games list dialog), and also has full sorting support to match the Steam games list. Because I really wanted a change of pace from writing Bash 😅

I implemented this in pupgui2gameslistdialog.py. There was some logic there already in preparation for a Lutris games list it seems. I'm a bit undecided if this is "better" than having a separate dialog, but the ctinfo dialog is shared, and as mentioned there was already some prep work for a Lutris games list, so I figured it was fine at least for now :-)

image

Overview

Instead of displaying the compatibility tool, Deck compatibility, Anti-Cheat status, and ProtonDB rating, we instead display the following:

  • Game Name
    • Tooltip: Game Name (Game Slug)
    • Double click: Takes you to lutris.net page for that game, if an installer_slug is present (only games with an installer_slug have a page on lutris.net, games without are manually-added games)
  • Runner (with first letter capitalized as a small design preference)
    • Tooltip: Wine version, DXVK version, and vkd3d version; whichever are available
  • Install Location
    • Tooltip: Either Double click to browse, or a warning if the directory doesn't exist (Lutris has a separate section on its menu for games with invalid paths as well)
    • Double click: Opens that path with xdg-open, if it exists. Otherwise it does nothing.
  • Installed Date (ISO formatted)
    • Tooltip: ISO formatted date with time in brackets, e.g. 2010-07-28 (12:51:03)

The fifth column that the Steam games list has is hidden. The "Apply" button was also changed to "Close", since there is nothing to Apply in this menu.

I chose to put the Wine information in a tooltip because I figured it would be useful to show a "complete" Lutris games list, minus Steam games only because we already display that for the Steam runner. Since not all Lutris runners will have Wine information, I chose to put it in the tooltip when the runner is Wine.

There is the option of only showing Lutris games that have a Wine runner, and then we show the Wine version/DXVK version/vkd3d version in that column (in that fallback order, in case one is missing, and show the rest in the tooltip). In the case where there is no Wine version (yep, that can be a scenario...) we could display "Unknown". I am personally slightly more in favour of the approach I took but only because my personal preference is seeing a "full" Lutris game list.

Unlike the Steam dialog though, there is no way to "change" a compatibility tool, there is no dropdown in the Lutris list like its Steam counterpart, and there are a couple of reasons for this:

  • Related to above, not all runners have a Wine version to change
  • A game with a Wine runner can have its Wine, DXVK and vkd3d version changed independently. These could all be added to the dialog in separate columns, and there would have to be logic to skip/remove unset Wine/DXVK/vkd3d versions so that it uses the Lutris default, but users may inadvertently think they need to set the DXVK/vkd3d versions for games. This could potentially lead to confusion.
  • Bulk-changing Lutris Wine versions may not be as desirable as it is for Steam games, though updating to the latest, for example, Wine-GE may be desirable in some cases- But instead of this being implemented in this Games List, it could be better left to the likes of [Feature Request] Use a symlink to help auto update wine-ge #162 or DXVK Updater #139.

Other Changes

I made a couple of other changes along the way to implement this.

  • Updated logic in LutrisGame#get_game_config to use os.path.isfile instead of os.path.exists. If fn == '', then the result of os.path.join(os.path.expanduser(lutris_config_dir), 'games', fn) would point to {lutris_config_dir}/games/ (because fn was blank, the end of the path was just not filled in). This config dir path should pretty much always exist if Lutris is installed.
  • In lutrisutil.get_lutris_game_list, some extra logic was added to fetch the install path of a game and store it in install_dir. We don't bother checking if this directory actually exists as its still a valid Lutris entry regardless, and Lutris itself has a separate menu entry for games that are missing.
    • The Lutris query was updated to select directory, however this will only be set whn a game is installed via a Lutris installer, as during the install process it asks you for an install directory. Manually added games do not have this.
    • As a fallback if directory cannot be found, we check if the game has a Working Directory, which we can get from the Lutris game's config yml. This is an optional field as far as I know and Lutris will infer it probably from the exe base directory, but not all games have to have a working directory as far as I am aware (at least one of my games didn't 😅).
    • As a final fallback, if we don't have directory (i.e. this is a manually added game) and if we don't have a working directory, we use the base directory of the exe as the install directory. This may not always be correct, imagine a scenario where an exe is buried in some folder structure like /path/to/GameFolder/CompanyName/EngineName/Game.exe. However as far as I know, this exe path can't ever really be blank, so it serves as a good final fallback in my opinion.
    • If we don't have a directory from the query, or a working directory or exe directroy, we default to an empty string.
  • Remove the vertical header from the games list, as it doesn't appear to be used anywhere. I tested the Steam dialog as well and I was able to update compatibility tools, sort, etc without issue. If it is actually used I can re-enable it no problem though.

I have only tested this on my main PC, which only has a selection of Lutris games. Further testing is, of course, very welcome here to make sure this works for more than my setup :-)


I decided to try and implement this on a whim, after I noticed the commented out lines to show the games list button for Lutris games. So I wanted to see if it would be feasible to implement a Lutris Games List. I don't use Lutris very much so it was just a bit of an experiment that could potentially end up being useful :-)

At the very least, I hope that this could serve as a "proof-of-concept" for a future Lutris games list implementation (perhaps similar to what I described with the Wine/etc comboboxes), if this simplistic "game information only" approach is not desirable.

Thanks!

@DavidoTek
Copy link
Owner

I implemented this in pupgui2gameslistdialog.py. There was some logic there already in preparation for a Lutris games list it seems. I'm a bit undecided if this is "better" than having a separate dialog

Okay. If there are some fundamental changes to the Lutris game list in the future, we can always separate it from the Steam game list.

we instead display the following: Game Name, Runner, Install Location, Install Date

Looks good to me

Since not all Lutris runners will have Wine information, I chose to put it in the tooltip when the runner is Wine.

Yeah, I think that is fine. If we ever decide to add functionality for changing the Wine version, we may utilize the fifth column for that.
But as you pointed out, users may also want to change DXVK/vkd3d versions. That can be done easily in Lutris own settings.

seeing a "full" Lutris game list

Agreed

[Feature Request] Use a symlink to help auto update wine-ge #162 or DXVK Updater #139.

Agreed

In lutrisutil.get_lutris_game_list, some extra logic was added to fetch the install path of a game and store it in install_dir

That's good. Even if the path may not be exactly correct, it should be good for users to get a rough idea where the game is stored and that's enough.

Remove the vertical header from the games list, as it doesn't appear to be used anywhere

It was originally used for showing game ids, but that feature was eventually removed (can't remember when and why).


Thanks for the effort to implement this. I think it is much better than the current situation: no game list 😄.
Adding this "game information only" list may encurrage users to think about more usecases for the dialog. Also, the "always non-empty install directory feature" is quite nice to have 😄
I will do some testing and merge it in the next days.

if os.path.isdir(install_dir_text):
# Set double click action to open valid install dir with xdg-open
install_dir_item.setToolTip('Double-click to browse...')
install_dir_item.setData(Qt.UserRole, lambda url: os.system(f'xdg-open "{url}"'))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that will work with the Flatpak version of ProtonUp-Qt. If inside Flatpak, it requires the prefix flatpak-spawn --host:
flatpak-spawn --host xdg-open /path/here/

Maybe we should add a function like host_which that runs commands on outside the sandbox.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not sure if it would work, I lifted this logic from Line 384-386 in pupgui2.py.

If this won't work in Flatpak, we could see about implementing something like host_xdgopen or something along these lines specifically for this action :-)

There is also the possibility that this won't work outside of Flatpak, if xdg-utils is not installed. But I think most systems, especially those for gaming (including Steam Deck) will come with xdg-utils.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. I did some testing yesterday and it didn't work. Tried again after a reboot, now it works.
It makes sense that xdg works with Flatpak, probably something wasn't running properly.

name_item = QTableWidgetItem(game.name)
name_item.setToolTip(f'{game.name} ({game.slug})')
if game.installer_slug:
# Only games with an installer_slug will have a Lutris web URL - Could be an edge case that runners get removed/updated from lutris.net?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine I guess. That shouldn't occur often.

@sonic2kk
Copy link
Contributor Author

users may also want to change DXVK/vkd3d versions. That can be done easily in Lutris own settings.

I think this is a good compromise, and using the fifth column for the Wine version is a good idea. The column is just hidden, so if we ever need to use it, it's just a case of removing self.ui.tableGames.setColumnHidden(4, True).

Or another possibility is removing the install time data and replacing it with the Wine version. Install time information could be moved somewhere else, maybe the tooltip for the game name or install path.

Adding this "game information only" list may encurrage users to think about more usecases for the dialog

Great point! I'm not a huge Lutris user so I'm sure Lutris users will have good ideas on improving it :-)

@DavidoTek DavidoTek merged commit bdae2b0 into DavidoTek:main Feb 22, 2023
sonic2kk added a commit to sonic2kk/ProtonUp-Qt that referenced this pull request Feb 24, 2023
sonic2kk added a commit to sonic2kk/ProtonUp-Qt that referenced this pull request Feb 24, 2023
DavidoTek pushed a commit that referenced this pull request Feb 24, 2023
* Fix Steam games list regression from #192

* Ensure installdir exists in appmanifest
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants