feat: Gamepad/keyboard navigation support #239
Conversation
Far from complete, but this does the bulk of the work, the rest is just fixing places where the selection moves in weird ways after doing some things, and overall improving the look and feel of it.
This will be particularly useful for #239
This will be particularly useful for #239
Either with the top bumper buttons on a gamepad, or with Q/E on a keyboard instead.
It now waits until the button has been released before that button can again do its action.
The lower delay that was there previously would lead to the axes/joysticks moving around the UI way too fast.
This is for when you use Q/E on keyboard or the bumper buttons on a gamepad, this prevents your selection from being on an element that is no longer visible.
If a selected element has its bounds changed, so should the `#selection`, this makes it so it now does that.
|
This PR is pretty much done, and the only thing that's really missing is confirming other gamepads are supported. More importantly, whether the SteamDeck works as intended, i.e the gamepad is detected, and the buttons are correct (A button = Accept, B button = Back, etc) I would therefore love if someone with a SteamDeck (@GeckoEidechse), or even other gamepads could test this. Builds are available at the bottom of the initial PR description. |
|
My schedule is too busy atm to test this, sorry :/ |
|
Ah I see, I'll likely keep the PR open for a lil while, due to being busy myself, if you do get the chance to test it lmk. Even if not, I will likely merge this and make a release at some point when I get around to it. :) |
|
I think this is awesome, but I'm not sure if your sampled approach to finding elements to navigate to is the best way of doing it. Like if it performs well and does what you want, that's swag. However, these are my thoughts after making something similar for TFORevive: fyi i made it in tfor after seeing this pr and getting inspiration from it :) |
|
I've done similar things in other projects before, it's effectively just caching the results, and I did intend to sorta get around to doing something My idea originally was to make a wrapper for I did know this wasn't very performant while writing it, but just never got around to fixing that :p, mostly due to how it could pretty easily be fixed without requiring major refactoring. I also considered something like a resize observer for invalidating the cache etc... I'll probably either implement it whenever I get the time, then merge, or merge, then fix it in post, so to speak... (possibly just the prior) |
Do you still need someone with a SteamDeck to test this? |
|
I do yup, if you're able to test it then that'd be much appreciated! :) |
|
Works just fine on Fedora 40 x86_64 with Haute42 (Generic Xinput), Xbox One Controller (Wired and Wireless Dongle) but the situation is a bit different on the steam deck: by default the Steam Deck uses a desktop layout (this can be toggled by holding the start button for a few seconds) the desktop mode mostly works: the L1 and R1 bumpers are bound to Alt and Ctrl by default (afaik) so that doesn't quite work, but you can navigate there via the dpad regardless. One other thing I have noticed that I found a bit annoying is that pressing left on the launch button put me on the navigation bar, not on the sidebar |
I guess I could map those to the action the bumpers normally have, I don't think this would have any negative effects, and trying to just detect whether it's a SteamDeck first would be clunky and there's likely other devices that'd want this...
Yeah, the UI navigation is made to be adaptive/agnostic, so there's no hints from the UI on where to go, so it instead tries to guess where the right place to go is, might still need some tuning... :p |
|
SteamDeck bumper buttons should now work in the desktop layout (hopefully?), although, I did find it weird that L1 is Alt and L2 is Ctrl and not reverse, due to their typical location on most keyboards, so it's not as intuitively useful outside of the SteamDeck, but that's a minor thing. |
|
turns out, I did a goof here and mixed itu p |
0neGal
force-pushed
the
gamepad-support
branch
from
8552462
to
7403086
Compare
whoopsie, welp, amended and should be fixed now... |
|
re-tested, works perfectly. |
This PR aims to add support for navigating the UI with the keyboard, but more importantly a gamepad aka a controller. While it is far from complete, the bulk of the work is here, and works quite well. The selection may still move slightly erratically in situations that have been untested, especially after changing popups and scrolling, but that's one of the things I'm intending to deal with before merging.
viper.mp4
TODO
TESTING BUILDS
Linux: here
Windows: here