@Zigurana Perfect.
And you're saying you fixed it now by "exposing the loopType and setting the loopType for that particular list to NEVER_LOOP."? That's a misleading name if I've ever read one - I wouldn't have found that one out :)
I'm not especially keen on removing buttons myself based on the rational that it's needed to get cyclic menus working. I believe if we want to remove the buttons for UX clarity, that's fine, and if we want to make menus cyclic that's also fine, but making one contingent on the other may make the behavior unclear and unexpected when there need to be buttons and such.
That being said, I can understand it's tricky in the current architecture.
In my view of the world, in the right-side picture, pressing UP from the "System Volume" selection should take you to the "Back" button, and pressing DOWN on the back button should take you to the "System Volume" selection.
That way it'll be fully cyclic regardless of the menu layout - there are quite a few menus with buttons where cyclic behavior would be a positive - I'm thinking of the scraping and metadata editor menus, but I'm sure there are others.
Furthermore, if we're being nitpicky, most (if not all) dialogs where there are options to be changed could/should have a "Cancel" and "Apply" button rather than a "Back" button, which would in turn disregard any changes, or apply the changes. But that would require a larger overhaul of the menus as they currently are, and I'm sure that's not a priority for anyone, and that's outside of the scope of the discussion. :)
Summarizing:
a) I don't oppose removing the button, in principle. Your point is valid: single button dialogs probably don't need it anyway.
b) I don't really support removing it because having it causes a new behavior not to work as intended. Would rather try to make the behavior work well with the buttons, instead, so that it works across the board.
c) I won't oppose if a) and b) are done together, though. :)
