Option to circumnavigate menus.

[sduensin]

I would love to be able to circumnavigate menus. Go up off the top to reach the bottom, etc. Pretty please? :-)

[hex007]

So is it one way (up on first goes to last) or both ways?

[pjft]

It would be both ways.

I believe there were some challenges with that in previous attempts at implementing it, but it's definitely worth pursuing. I suspect it was related to buttons vs menu items, but I don't have the full context.

I believe @zigurana took a stab at it at one occasion, maybe he can share more info or even code, if there was a PR sent over.

[hex007]

If it is implemented hard both ways then input config dialog has issues as you cannot exit. What can be done is a parameter/method can be used to disable this behavior.

[pjft]

I'm not sure a parameter would help or be ideal here.

The ideal would be, if you're at the top and push up, you'd go to the (visually) bottom row in the menu - is there are buttons, the first button is selected; if no buttons, then the lowest row. If you're in the bottom (meaning, the button row, or if no buttons then on the last row) and push up, you'd go to the top.

If you're in the buttons and push up, you're back at the bottom menu entry row. Just like now.

If you're at the buttons and push down you go to the first menu entry row.

If you're at the last row and there are buttons, and you push down, you go to the buttons, like now.

Is this what you had in mind?

Edit: I missed you mentioning "input config". What do you mean? I'm not as familiar with it, but I didn't see anything wrong with it at first glance. I don't think we can navigate it anyways?

[sduensin]

Is this what you had in mind?

Exactly!

[hex007]

This seems doable. @joolswills is this acceptable?

Was the input configuration dialog the only problem?

@pjft input config is the dialogue that appears where you configure your input device like gamepad or keyboard

[pjft]

I don't recall the input configuration dialog being any particular problem

• what's your concern with it? Doesn't it automatically navigate until the ok button is reached? How do you see that changing our being affected?

The problem, if I recall, is that you'd have to explicitly cater for the fact that the buttons are a separate element and not a Row Element in the list for you to simply iterate through.

As I said, @zigurana would have more details, but if you see it being feasible, it'd be good to see what problems you're anticipating with the input dialog as we may certainly be missing them!

Thanks! On Sun, 11 Jun 2017 at 04:27, Saket [email protected] wrote:

This seems doable. @joolswills https://github.com/joolswills is this acceptable?

Was the input configuration dialog the only problem?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-307603771, or mute the thread https://github.com/notifications/unsubscribe-auth/AVAV7Zn2YM352G_eii36FL4VP831N1fDks5sC16kgaJpZM4N2REf .

[hex007]

I dont remember where i read this but someone had pointed out that the list would cycle as B for back was not available on that dialog and it was not possible to access OK button then.

I am not aware of any progress made after that.

[pjft]

Oh. Don't remember reading that, so can't comment, but if it's only that dialog that poses challenges then we can certainly tackle it as a one off if needed.

Still, I'm under the impression the previous attempt did not cycle through the buttons as we're describing here, but only through the menu items.

If you cycle through items + [button row as a single entry, if present] as described here, it should not be a problem. On Sun, 11 Jun 2017 at 06:38, Saket [email protected] wrote:

I dont remember where i read this but someone had pointed out that the list would cycle as B for back was not available on that dialog and it was not possible to access OK button then.

I am not aware of any progress made after that.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-307608101, or mute the thread https://github.com/notifications/unsubscribe-auth/AVAV7S6zqg4UaI553BJE8yd_2qa-sg9nks5sC31tgaJpZM4N2REf .

[hex007]

Yes I agree. This would be excellent feature.

Additionally in the input config dialog we can try setting that if two keys are pressed simultaneously then focus moves to OK button. Many people dont use the entire available buttons.

[pjft]

I suspect that won't be a problem. Currently you skip an input by holding any button for X seconds.

If you cycle as described, you'll get to the ok button as intended.

Also, at the moment the input architecture of EmulationStation doesn't cater to detecting simultaneous button presses, unfortunately.

That in itself would be a nice change, albeit a separate one. :) On Sun, 11 Jun 2017 at 06:47, Saket [email protected] wrote:

Yes I agree. This would be excellent feature.

Additionally in the input config dialog we can try setting that if two keys are pressed simultaneously then focus moves to OK button. Many people dont use the entire available buttons.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-307608380, or mute the thread https://github.com/notifications/unsubscribe-auth/AVAV7cPNRzNfArpmClRhSA3qgmanVJ9Gks5sC39_gaJpZM4N2REf .

[talex-tnt]

Hello there,

if you haven't fixed this yet, you might be interested in checking out this code from my fork: https://github.com/talex-tnt/RetroStation/commit/2b3d78c9785cf69df2d68989d308eaecc2121f22

Still testing it but it looks working so far.. as I'm able to loop through lists and grids (keyboard).

I did some further experiments a few weeks ago, but they didn't work out..

This is the less invasive and hacky approach I could find that didn't require to refactor massive amounts of code. It can also easily disabled from the settings menu.

Hope it might be of some help.

Cheers, Alex

[zigurana]

Had a brief look from my phone at this, and this looks promising! Do we need the set/reset focus methods as well for this?

Op zo 25 jun. 2017 17:33 schreef talex [email protected]:

Hello there,

if you haven't fixed this yet, you might interested in checking out this code from my fork: talex-tnt/RetroStation@2b3d78c https://github.com/talex-tnt/RetroStation/commit/2b3d78c9785cf69df2d68989d308eaecc2121f22

Still testing it but it looks working so far.. as I'm able to loop through lists and grids (keyboard).

I did some further experiments a few weeks ago, but they didn't work out..

This is the less invasive and hacky approach I could find that didn't require to refactor massive amounts of code. It can also easily disabled from the settings menu.

Hope it might be of some help.

Cheers, Alex

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-310909492, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0i2BaoN71_IriMXQumhj1qcIwCs8sDks5sHn3AgaJpZM4N2REf .

[talex-tnt]

Hi zigurana,

I'm going to thank you first for your contribution as I used one of your branches as reference to start implementing my own "Favorites" feature - recently upgraded to "Game Collections".

Regarding the set/reset focus methods, I'm not sure to get what you mean..

Here's a sum-up of what I did: For each gui component that can focus some element in it, I implemented a custom version of SetFocus(FocusPosition pos, bool enableFocus) - now renamed as UpdateFocus(...) this method is called from the root node in the NavigationController.

UpdateFocus updates the cursor position according to the FocusPosition argument, and eventually also set itself as Focused - second argument. It also forwards the call down to its children.

The NavigationController as some notes in it as well.

In any case my fork shouldn't be too different from the retropie/master, with some minor changes it might work there too.. If it doesn't.. you might have to apply some of the other changes I made to the base gui system.

Cheers

[zigurana]

Cool! Thanks for the explanation. I'll have a look later this week, to see if we can re-use your work!

Thanks!

Op zo 25 jun. 2017 18:22 schreef talex [email protected]:

Hi zigurana,

I'm going to thank you first for your contribution as I used one of your branches as reference to start implementing my own "Favorites" feature - recently upgraded to "Game Collections".

Regarding the set/reset focus methods, I'm not sure to get what you mean..

Here's a sum-up of what I did: For each gui component that can focus some element in it, I implemented a custom version of SetFocus(FocusPosition pos, bool enableFocus) - now renamed as UpdateFocus(...) this method is called from the root node in the NavigationController.

UpdateFocus updates the cursor position according to the FocusPosition argument, and eventually also set itself as Focused - second argument. It also forwards the call down to its children.

The NavigationController as some notes in it as well.

In any case my fork should be too different from the retropie/master, with some minor changes it might work there too.. If it doesn't.. you might have to apply some of the other changes I made to the base gui system.

Cheers

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-310912444, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0i2Ktd9WUcKmqtdF42RF0GcWU7kRq2ks5sHolMgaJpZM4N2REf .

[kaltinril]

+1 Up-vote this. Find myself pressing down so often to get to the bottom of a menu.

[pjft]

You can also use R1, for reference. But agreed, this is definitely an useful improvement. On Mon, 21 Aug 2017 at 00:35 Jeremy Swartwood [email protected] wrote:

+1 Up-vote this. Find myself pressing down so often to get to the bottom of a menu.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-323619124, or mute the thread https://github.com/notifications/unsubscribe-auth/AVAV7QRyfsLWlThfHuqUZBoZDzc6ijCCks5saMKtgaJpZM4N2REf .

[hex007]

Are you interested in one way transition from top to bottom when you click up from first item or you want bidirectional movement?

[pjft]

I personally imagine both ways is the standard. I think we had discussed this and alternatives somewhere in the past...? On Mon, 21 Aug 2017 at 07:46 Saket Dandawate [email protected] wrote:

Are you interested in one way transition from top to bottom when you click up from first item or you want bidirectional movement?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/RetroPie/EmulationStation/issues/158#issuecomment-323660053, or mute the thread https://github.com/notifications/unsubscribe-auth/AVAV7duZJKYefzUMnQMXkfXw60b1I9CDks5saSfegaJpZM4N2REf .

[hex007]

Doing it one way would be way easier. You wont need to worry about buttons