add optional scroll buttons to overflowing track context menus

[ronso0]

https://mixxx.discourse.group/t/love-the-software-just-a-few-issues/24530

A lot of playlists or crates may make submenus of the track context menus overflow, potentially covering the entire screen.
While we may argue that context menus are simply not designed for such an insane amount of items we should consider that case.

One possible solution (the quickest and easiest that comes to mind) is enabling scrollbars via stylesheets. Adding this snippet to each skin's style.qss enables scroll buttons at the top and bottom of submenus oveflowing screen height (like implemented for QComboBox by default).

WTrackMenu QMenu {
  menu-scrollable: 1;
}

[Daniel Schürmann (daschuer)]

Scrolling is only the second best solution. A hierarchical menu works faster, but that would be no 2.3.3 band-aid.

* Cates A .. H
* Cates I .. Z
* new Crate

[ronso0 (ronso0)]

I agree.

For best experience for all users (all submenus fit the screen)
we should
a) show hierarchical menus only if required
b) adjust the splitting so submenus are equally sized and don't overflow (A-M, O-Z, or
   A-N, M-T, U-Z)

Since 'fits the screen' depends on skin stylesheets it can only be detected _after_ the Crates menu was constructed, for example by reading (protected) QMenu::columnCount and QMenu::size. So, if it would overflow we'd need to rebuild the menu with N submenus.
That feels inefficient. Maybe we can construct a dummy menu with one action, read its size, add some buffer for separators and possible QMenu padding, then compare that to the available screen height and create the submenus so everything fits nicely.

[ronso0 (ronso0)]

yeah, or dynamically generated so each submenu holds approx. the same number of crates.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10691