[Feature request] [Ozone] Multiple line scroll in Ozone playlists

[jvook]

There is no feature to multi-line scroll in Ozone menu driver, only scrolling by full letter increments. In large file lists it can take over a minute to scroll line by line to a title. For the worst example, in a full MAME set, it can take over a minute to scroll past the mahjong titles alone. Ozone driver needs a multiline scroll similar to pressing left/right d-pad in RGUI menu driver.

[Ryunam]

I believe in any playlist you can press R1 to do multi-line scrolling, as in advancing to the first entry in the list that has the next starting letter in the alphabet.

[jvook]

Yes I am asking for a regular multiline scroll, like the one in RGUI (to scroll say 10 elements, idk), because scrolling by a whole letter can be hundreds of titles.

[sonninnos]

Yep, not sure if we really need 2 different buttons (Left+Cancel) for returning from a playlist, as in Left+Right could/should be easily used for paging instead.

[Ryunam]

I totally agree with the idea of making Left+Right behave like in RGUI and instead restrict playlist navigation to Confirm+Cancel. As long as the change is consistent all across the Ozone UI, I don’t mind it at all.

[jvook]

Yep, not sure if we really need 2 different buttons (Left+Cancel) for returning from a playlist, as in Left+Right could/should be easily used for paging instead.

This is the most logical solution to me, but it's worth mentioning that a couple other solutions exist:

1. Use left-right d-pad to scroll multiple lines, as in RGUI
2. Use L2/R2 to scroll multiple lines (or better yet, use L2/R2 to scroll by letter and L1/R1 to multiple line scroll)
3. Implement an accelerating scroll a la EmulationStation. Holding the up/down button will scroll by a single line, then after a few lines it will accelerate to scrolling multiple lines.

[jvook]

I totally agree with the idea of making Left+Right behave like in RGUI and instead restrict playlist navigation to Confirm+Cancel. As long as the change is consistent all across the Ozone UI, I don’t mind it at all.

There is some inconsistency currently. For example, in the Quick Menu, pressing left or right on certain elements (e.g., Start recording, cheats, etc.) will multiline scroll, while pressing on others (any save state option) will change the state slot. This creates a situation where pressing left scrolls up, then pressing right changes slot instead of scrolling back down.

Next inconsistency is that using the "Load content" menu items allows scrolling with left/right d-pad, but playlists do not. The design philosophy behind this difference seems to be that when the "Vertical menu" on the left side is hidden (as in load content, quick menu, etc.), then left/right will act as multiple line scroll. If the vertical menu is shown, as in playlists, then the left d-pad backs out and the right d-pad does nothing. In order to make this fully consistent, the vertical menu would need to be hidden while in playlists.

[ghost]

Alternatively, you can use the search feature to reduce the number of entries you need to scroll through.

[i30817]

The reason left exists for playlist movement is exactly because of the search function. Imagine you want to search for final fantasy games and the explore feature is its usual underwhelming; either because you scanned manually or the database just doesn't have them. You can work around it by searching for 'final fantasy', pressing left and search the other playlists for all 'final fantasy' games because the search continues active until you press cancel.

I'm not going to tell you how to do your program but i feel this feature is more valuable when you want it than 'go down list fast', at least in the pc where you do have the search and can use it easily.

Also in ozone in particular, left is 'intuitive' as 'go back to the menus' because the menus are on the left. This one is not a serious objection like the other because you can get used to cancel and ok quickly though.

Unless there is a option to make searches search all playlists, and show a nice UI for it showing which playlist it was from, and starting with the current playlist first match selected, i personally do not agree with changing this.

Without that, I'd think it would be better if either there was a option to switch the behaviour of the shoulder buttons in the retropad or there was a option to use the L and R buttons for the different types of jumping titles if the current controller has both.

[sonninnos]

But isn't the "Explore" menu much easier/better for global searches..? Feels kinda like a lucky accident rather than intentional that that kind of playlist searching can be used in Ozone and XMB, but not others. And it sure is inconsistent that it is menu specific.

[Ryunam]

@sonninnos However, you can make a case about the Explore menu not working the same way as the search method does, because the Explore menu does not seem to detect custom playlist entries that do not rely on a database.

I am seeing the same thing happen with some Arcade custom entries I made for myself: the Explore search does not find those pieces of content at all, while I can easily get them by searching for the same name manually and then inputting 'left' to switch from one playlist to another.

The name of the searched content is even appended to the Playlist name in the header when doing a manual search, which looks rather nice actually:

Considering this, I vote for the following approach:

• change L1/R1 to a multi-line scrolling that is identical to what happens in RGUI and allows very fast (or increasingly fast) movement in the playlist;
• set L2/R2 to behave like L1/R1 do right now, as in a method of scrolling that is based on the starting letter;
• provide a visual indication of both these controls in the UI footer.

[i30817]

BTW, i believe right now, due to the work of @jdgleaver, keeping 'up/down' pressed inside playlists will increase the speed already, so i don't think it's a particularly good idea for the L/R buttons to have acceleration. I'd rather think you'd use it when you want precision (for searching for 'next/previous letter' or completeness/precision, when paginating up or down).

Lots of people use custom sets without database entries, including with your own puae emulator @sonninnos - i use the retroplay whdload set with it (not on the database), and 'fix' the images with my utility for fuzzy download that adapts those very different names to the thumbnails on the server. Other people will use custom names for dosgames based on the .conf files they setup because they scanned for conf files for dosbox, because they want those configs, instead of the generic, likely to be broken one that loading a 'blessed' exe on the database does, etc.

Many valid reasons for the 'roms' in the playlist to not be recognized, not just 'not on the database, probably a bad dump' that you'd expect from consoles (and even there, you want the hacks&softpatches not to be id'ed as the original game, so using a renamed hardlink/softlink is useful). And although it's unusual, some executables are self-modifying... in the disk. The very unwise DOS game 'Hook' saves its games in a zone of the executable. Assuming the emulator does not do copy on write for diskettes/disc images of course.

Yes, it's often a shame to lose metadata, but between metadata and a working emulator configuration (like in that .conf case), i'll use the configuration file as the 'launcher' playlist file every time (assuming i'm even using a 'eXXos dump' instead of a random install i had and the game would even be recognized that way).

Basically, i never use the 'normal scanner' - including for consoles because of softpatches - and thus having 'something' in the explore menu is always incomplete, and depends on having the right ROM name, so it's not unusual, to see for example, the DOS collection have no hits there because the names are different than expected.

[sonninnos]

Considering this, I vote for the following approach:

* change L1/R1 to a multi-line scrolling that is identical to what happens in RGUI and allows very fast (or increasingly fast) movement in the playlist;

* set L2/R2 to behave like L1/R1 do right now, as in a method of scrolling that is based on the starting letter;

* provide a visual indication of both these controls in the UI footer.

Yep, I think this is de wey.

[jvook]

Considering this, I vote for the following approach:

* change L1/R1 to a multi-line scrolling that is identical to what happens in RGUI and allows very fast (or increasingly fast) movement in the playlist;

* set L2/R2 to behave like L1/R1 do right now, as in a method of scrolling that is based on the starting lett

I'm happy with this solution

[jvook]

Doesn't it also make sense to remove the left/right dpad scroll that is currently used in e.g., the load content and quick menus? Especially re: the inconsistency I discussed in first paragraph here https://github.com/libretro/RetroArch/issues/14134#issuecomment-1173133035