Open 0neGal opened 2 months ago
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:
Repeatedly calling document.elementsFromPoint
is really expensive and it caused stuttering in tfor, so instead we went for an approach of making a list of all the elements that are in an area and with this list of elements we can just for loop through them to find the closest.
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 elementsFromPoint()
that effectively just caches the values, i.e 0,0
gets a lil cache, and we only actually run elementsFromPoint()
if this cache is slightly outdated (or an element was created), i.e if its older than 100-1000ms old or similar.
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)
I would therefore love if someone with a SteamDeck
Do you still need someone with a SteamDeck to test this? I have SteamDeck LED with stock SteamOS which should be great for testing purposes.
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: a = enter b = esc dpad & left stick = arrow keys
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
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.
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...
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
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
L1/LB is Left Ctrl
and R1/RB is Left Alt
I've still gone ahead and tested it and it works without a hitch (ignoring that it goes in the wrong direction)
turns out, I did a goof here and mixed itu p
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.
https://github.com/0neGal/viper/assets/33325154/8924ccaa-35b6-434d-a0d1-74cf4297c212
TODO
TESTING BUILDS
Linux: here Windows: here