search

0neGal / viper

Launcher+Updater for TF|2 Northstar
https://0negal.github.io/viper
GNU General Public License v3.0
151 stars 21 forks source link

feat: Gamepad/keyboard navigation support #239

Open 0neGal opened 2 months ago

0neGal commented 2 months ago

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

0neGal commented 1 month 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.

GeckoEidechse commented 1 month ago

My schedule is too busy atm to test this, sorry :/

0neGal commented 1 month ago

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. :)

barnabwhy commented 1 month ago

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 :)

0neGal commented 1 month ago

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)

Jan200101 commented 2 weeks ago

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.

0neGal commented 2 weeks ago

I do yup, if you're able to test it then that'd be much appreciated! :)

Jan200101 commented 2 weeks ago

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

0neGal commented 2 weeks ago

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

0neGal commented 1 week ago

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.

Jan200101 commented 1 week ago

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)

0neGal commented 1 week ago

turns out, I did a goof here and mixed itu p

whoopsie, welp, amended and should be fixed now...

Jan200101 commented 1 week ago

re-tested, works perfectly.