Improve gamepad navigation and on-screen keyboard handling

[danprice142]

This pull request introduces several improvements to gamepad navigation and on-screen keyboard handling. The changes improve controller navigation in settings, add support for shoulder bumpers, refine analog stick handling, and ensure better integration with on-screen keyboards.

[flyinghead]

Can you explain what you are trying to achieve with this PR: the changes involved and the problem(s) being solved?

I see several changes that significantly change the way the UI is used, and I don't have any rationale for it. It looks like a right thumbstick is now required to scroll. What if the user's gamepad doesn't have one? (The original dreamcast controller, and it's modern reincarnation don't). Why this change?

Last time I worked on the Xbox platform I had no issue navigating the UI with a gamepad, and the on-screen keyboard was working fine. I clearly remember it because I was working on network stuff and that required me to enter IP addresses, user name, etc. And nobody has reported any UI-related issue on Xbox afaik.

You are disabling flattened navigation in some areas, which makes them difficult to use with a gamepad and degrades user experience (IMHO).

Also, why is UWP-specific code now needed in generic UI code? What is it doing?

I'm really worried about the potential regressions from this PR, including on the Android platform with its touch interface. So please make sure that this is tested on this platform too.

[danprice142]

At least on UWP the on screen keyboard did not open for Cheats and ISP User Name, I have always been able to navigate the rest of the UI fine with a gamepad but since adding all the new custom path options that's no longer true I tried a few things with no luck so I added the scroll as a workaround, got a little carried away and added left stick to navigate round the UI, controller bumpers to switch between tabs and made it so you do not need to press a button to show a tabs content, these last three things are minor improvements but are not needed and do not fix anything just makes the UI a little smoother to navigate.

As for flattened navigation I'm sure I just forgot to change it back after a earlier attempt and has now been reverted, the UWP specific code was mainly to get the keyboard to open and actually type as well as close properly without reopening, this took me a few attempts to get right and I do not have the means to test it on all platforms so I made it specific to UWP but maybe could be done differently/better? About testing on Android I do not really have a sufficient device but could make a build and get someone else to test it?

[flyinghead]

I did some test on Xbox with the current dev branch and here is what I found:

1. The on-screen keyboard works fine for the most part. The only issue I found is for multi-line inputs (Add Cheat window). Once editing is done, the user must press B to hide the keyboard then press A to validate the input. This is obviously not user-friendly. I suppose this is the reason behind the various ImGui::ClearActiveID() in your PR.
2. Navigation with DPad or keyboard keys doesn't work with buttons inside list boxes (paths lists Add, Set and Delete buttons): if the button isn't visible you can't navigate to it and the window won't scroll to make it visible. This isn't specific to Xbox and happens on all platforms. But this is a serious problem without a mouse or touchscreen.
3. Scrolling with the gamepad thumbstick doesn't work in child windows (such as list boxes). More precisely, if the child window is scrollable, the parent won't be scrolled. Combined with the previous issue, it makes navigation even more cumbersome.

I'm still investigating to find out how these problems can be fixed. Navigation and scrolling problems are likely ImGui bugs or limitations but some work around is needed.
However I only had a minor issue with the on-screen keyboard. In particular the keyboard shows up every time I press Y on a text input widget, and disappears when I press B. So let me know if there are things I overlooked.

[flyinghead]

I used some of your code to fix the on-screen keyboard problem: eab952f
Adding an InputPane hiding event handler and clearing the active ID when this happens, which validates the text edit.

For the navigation issues, I got rid of list boxes and replaced them with a simple frame. No more child windows = no more nav problems.

I don't think anything else is needed for these issues. What remains is the tab navigation with triggers feature so if you want to rebase this PR and remove everything else, I'll merge it.