Page Up/Down function on ES Textlists (via LB/RB) Not Accurate?

philcsf

Pressing the button always goes 10 entries up/down from the selected entry, regardless of how many entries are displayed on a page.

On my theme that is resized to only show nine game entries in the textlist, this means that quickly scrolling through using Page Up/Down is actually skipping the display of every 1 in 10 games, making it a bit annoying when quickly scrolling through to look for a specific game (as it could be skipped over).

Here's the issue in TextListComponent.h (as I'm still not experienced enough with github to do it myself):

Instead of calculating screenCount value in render() every frame, calculate and save it as a member variable in the constructor (it's never going to change)
In input(), move up/down by mScreenCount every frame instead of the hardcoded 10/-10 values passed to listInput()

Thanks!

IanDaemon

@philcsf The arcade stick moves up/down one and there are buttons that move up/down ten on my machine. I'm using an arcade stick. Are you using a keyboard?

philcsf

@iandaemon No, that all works for me as well. The bug is that it always goes down a hard-coded amount (10), and not a 'page worth' (however many entries are being displayed in the textlist depending on size).

IanDaemon

@philcsf Ah, OK, so the current options are "one" and "ten", but you'd like "one" and "a screen's worth". I'm not sure if the developers of RetroPie can make changes to EmulationStation.

Lolonois

@philcsf you are right. The fixed amount does not match on smaller displays and/or large font themes and/or themes with a small visible list bounding box.

Emulationstation can also be run in a Window, so it makes sense to recalculate the max. visible entries everytime.

For the "Page Up/Page Down" logic some changes have to be considered:
In a usual file browser, on the first page down action the selection moves to the last visible entry without scrolling. On the subsequent "page downs" a full "page" is scrolled/moved. For Page Up this is the same, but in the other direction.

ES has a special case where you can push over the end of the list and land at the beginning of the list. Just push "page down" (or "down"?) once more when you are at the end. Again this also work upwards.

Currently the "+10" of ES puts the cursor in the middle in the visible listentries (on a 4:3 display with Carbon theme). I assume this decision was made "by design" since the widespread use has not been anticipated at that time ES was started. However, it is not cast in stone. :)

Maybe this discussion should be moved to "Ideas and Development"? @mitu, @dankcushions, @pjft, @BuZz

mitu

Maybe this discussion should be moved to "Ideas and Development"?

Yes, it's more appropriate there.

philcsf

@lolonois said in Page Up/Down function on ES Textlists (via LB/RB) Not Accurate?:

Emulationstation can also be run in a Window, so it makes sense to recalculate the max. visible entries everytime.

Ah yes, good point.

Thinking about it some more, changing the behaviour by default to be a single page instead of +/-10 may have knock-on effects for other users, maybe speeding up or slowing down the fast scroll that they're probably used to.

Maybe the compromise is a new field in TextList data of how many a page is. Defaults to 10 if not defined, but the scrolling speed can be overridden on a per-theme basis?

Lolonois

@philcsf I don' t like the idea of a scroll count on per theme basis (from an implementation viewpoint). I'd prefer a ES wide setting a la "legacy" mode (+/-10) or the "what the user expects" mode, i.e. the behaviour known from commonly used file browsers and the way you expect it too.

Lolonois

Submitted PR#740 to address this.