Games List: Search Box, Apply Button UX Tweaks

[sonic2kk]

Overview

This PR adds a search field to the Games List, my new favourite home it seems :sweat_smile: The idea behind this is to make it easier to find games to set compatibility tools for. The column sorting helps a lot and that was one of the reasons I had in mind for implementing it, but if you have hundreds or even thousands of games installed, it might be faster to just search for them.

This applies to all current Games List: Steam, Lutris, and Heroic (Proton+Wine).

Search

Screenshots:

   

(I'll come back to the "Done" button in a bit)

The search field is hidden by default, and is shown when the user presses the new "Search" button. It shows up in the same position as the Steam warning label. If the label is not displayed, there is no change, but if it is displayed, then this label is temporarily hidden while the search field is present.

Searching preserves the current selected column sort, and sorting works even when the user is in the middle of searching. It also keeps this sort. If the user searches for, say, "Persona", and sorts alphabetically, then this sort will be remembered. Of course, selected compatibility tools are remembered as well!

When the user presses the "Done" button, the search filter is cleared. Once the user presses "Search" again, their last remembered search will be applied as well.

The Search field is automatically focused when the "Search" button is pressed, so the user can start typing right away. This may also help with virtual keyboards on Wayland, though I haven't tested :-) That's more up to the Desktop Environment and virtual keyboard library to detect, but it was something I considered as part of implementing that logic and so wanted to mention it.

UI Tweaks

There are also a a couple of smaller changes to the Games List UI logic:

• Store a boolean that checks if the Steam warning label should be displayed and set it once in setup_ui - This removes the extra calls to lblSteamRunningWarning.setVisible in the other launcher setup functions
• Use a method to determine the text for the "Apply" button and whether it should say "Apply" or "Close" based on three factors:
  • If Steam is running (only applicable to Steam)
  • If the current launcher is Steam (again, only applicable to Steam)
  • If the queued_changes >= 0 (nothing to apply if there are no changes queued) - Though it doesn't "reset" if the applied change is reverted i.e. if the compat tool is changed to STL and then back again to whatever its initial value was, though this is more likely related to the logic for populating queued_changes
• Center-align Anti-Cheat Icon in Games List
• Remove leftover TODOs from #199 -- I left these in, my bad

Improvements

There are a couple of things I would like to "Improve" on this PR that I'd like some feedback on.

Keyboard Shortcuts

The decision to have a dedicated "Search" button was deliberate, for users who may be using a touch screen (i.e. on Steam Deck). But I would also like the ability to trigger this with a standard Ctrl+F shortcut. I'm not sure how to do this though. The btn_search_clicked method would need to be called on Ctrl+F being pressed. I read online about a QKeySequence being used for this, and it can emit an activated but I'm not totally sure, I couldn't find too much (though it is late at the moment).

This may be a bit convoluted or over-the-top but it would also be nice if pressing "Escape" with the search field highlighted could perform some actions.

• If there is text in the search field, clear it (and refresh the list ofc), basically as a "cancel search" option
• If there is no text, act as though the "Done" button was pressed (hide the search box, etc)

This may be too complex to implement and not worth the effort, but it was an idea I had after opening the PR and experimenting with actually using the search box and behaviour that I would "expect".

"Done" Button for Search

My other concern is with the "Done" button for the search field. I'm not too sure if this name is good. It may be confusing for users. "Stop Searching" is a bit lengthy but could work as a replacement. Some way to better name this button would be appreciated :smile:

One potential solution is to have a layout with the search field that has its own "Done" button (which could be connected to the same signal as the "Search" button probably), and that button would then appear directly to the right of the search field, and would be shown and hidden with that field. That way the "Done" button is farther away from the "Close"/"Apply" button, but it could still end up being confusing.

Performance?

I only have around 307 Steam games installed, but on my PC the search is instantaneous. Maybe if there were thousands of games there could be a performance impact here. If there are ways to optimise the search I'm very open to it! :smile:

Future Implementations

This could be implemented in the compat tool about dialog. A user may be a bit more cramped for space here to include the button and search field but it should still work.

Search Criteria

A user can only search by Game Name. I wasn't sure how to implement searching by AppID in a clean way and I wasn't sure how useful it would be to begin with - if a user knows the AppID for a game off the top of their head, they probably also know the game name.

Translations

The placeholder/background/"hint" text is added to the .ui file edited in Qt Designer, so I am not sure how to handle the translations. Sorry :sweat:

---

I thought my last PR would be my last contribution for a while, but I found a note written down with this idea out of the blue and thought I'd try to implement it and keep the code cost down (tried to keep the Games List under 400 lines but failed...)

Thanks! :-)

[sonic2kk]

Pushed a small commit that now prefixes the dialog title with the current launcher e.g. "Steam Games List", "Heroic Games List".

I took a stab at implementing the Ctrl+F keyboard shortcut for the games list. This seems to work, though it had to be set twice: In setup_ui and then again in btn_search_clicked. I'm not sure why it has to be set in here again so if this can be fixed I'm very open to that :-)

Still not sure how to implement the "Escape" shortcut I talked about.

---

Also as a small note: The black text for the search box hint is a KDE bug with Qt6 applications. Here's an example with the light theme:


[sonic2kk]

Pushed a couple of commits which do the following:

• Use the same QShortcut approach as #205, which imo is a better approach than binding a shortcut directly to a button. It also means we don't have to do that second call to setShortcut in btn_search_clicked. It goes from being a few lines to set the shortcut to just one!
• Clean up the logic a little bit in search_gamelist_games. I didn't realise QTableWidget had a setRowHidden method, so now we just call that. It might be slightly faster maybe(?) but really I think it's just cleaner :-)

---

The more I look at the search bar UI, the more I think we should hide the search button when the search bar is visible, and show a "Done" button beside the search bar that gets shown/hidden with it. But I'm not sure if having a bunch of hidden widgets is such a good idea. We could also just move the search button if that's possible.

[DavidoTek]

Thanks, that is a nice addition! :tada:

The search field is hidden by default, and is shown when the user presses the new "Search" button. It shows up in the same position as the Steam warning label. If the label is not displayed, there is no change, but if it is displayed, then this label is temporarily hidden while the search field is present.

Sounds good.

The decision to have a dedicated "Search" button was deliberate, for users who may be using a touch screen (i.e. on Steam Deck). But I would also like the ability to trigger this with a standard Ctrl+F shortcut.

That's very good, having suport for mouse and touch screens as well as a keyboard shortcut.

I only have around 307 Steam games installed, but on my PC the search is instantaneous. Maybe if there were thousands of games there could be a performance impact here. If there are ways to optimise the search I'm very open to it! smile

Code looks good. Looping over hundreds (or few thousands) of items once and doing a simple string comparison should be fast enough with Python.

This could be implemented in the compat tool about dialog. A user may be a bit more cramped for space here to include the button and search field but it should still work.

Yeah, that could be an optional future addition. Having it in the Game List should be enough for now.

The placeholder/background/"hint" text is added to the .ui file edited in Qt Designer, so I am not sure how to handle the translations. Sorry sweat

No worries. Ui file translations are automatically included by Qt.

Also as a small note: The black text for the search box hint is a KDE bug with Qt6 applications

I also noticed some problems with some themes. I may need to change the custom theme, specified in constants.py.

The more I look at the search bar UI, the more I think we should hide the search button when the search bar is visible, and show a "Done" button beside the search bar that gets shown/hidden with it. But I'm not sure if having a bunch of hidden widgets is such a good idea. We could also just move the search button if that's possible

In theory, we could add a little X action button besides the text field, though people might confuse it with "clear text box". Personally, I think it looks okay as it is.

I thought my last PR would be my last contribution for a while, but I found a note written down with this idea out of the blue and thought I'd try to implement it and keep the code cost down (tried to keep the Games List under 400 lines but failed...)

Yeah, there is always something you will find to improve/change. As always, thanks for looking into those :smile: