Add redesigned beatmap wedge for new song select

[frenzibyte]

• Depends on Define standard font specifications and update new beatmap panel designs accordingly #32673

Design reference: https://www.figma.com/design/GjPIkoh2kvt7hSLrqeinTQ/Client%2FSong-Select?node-id=6484-8213&t=GdkHN5mAyNgP0sdX-4

Preview:

CleanShot.2025-03-20.at.13.10.29.mp4

Follow-up tasks:

• Display mod adjustments in beatmap difficulty statistics
• Introduce a BeatmapSetLookupCache class to cache online beatmap attributes such as play & favourites count

[peppy]

There's quite a bit of movement in the fill flow line with play counts. I think it would help to pad each one so they (in the majority case) don't change position.

[minisbett]

What about making the length and BPM right-aligned?

Another thing I thought about is what if you could click the heart icon (or whole UI element) of the favorite count to favorite the beatmapset? And when it's favorited, the heart appears in pink.

Overall the design looks really cool.

[frenzibyte]

Right-side alignment won't work well for BPM since it's length is variable, also generally aligning anything on the right side on the wedge itself probably won't look good.

[frenzibyte]

Added minimum padding to statistics as per suggestion.

video

CleanShot.2025-03-21.at.08.56.55.mp4

[tomm13]

In the design the bars above CS, OD,. AR, HP are the same width, this makes it easier to visually compare values

[frenzibyte]

The width is based on the statistic label so it doesn't accumulate too much space to the left, giving hit count statistics a breathing space.

this makes it easier to visually compare values

I don't follow this part, it's not like the statistics move around when switching between beatmaps, what's hard to compare here?

[Tanza3D]

The width is based on the statistic label so it doesn't accumulate too much space to the left, giving hit count statistics a breathing space.

this makes it easier to visually compare values

I don't follow this part, it's not like the statistics move around when switching between beatmaps, what's hard to compare here?

i know the stacked comparison doesn't line up with the design but it gets across the point i think?

(just to explain what the person meant by that, not going to argue/suggest one way or another)

[peppy]

Agree they should all be the same width. I'm also not sure about the colour of the bars changing with the SR. Something about it is perturbing to me – it's updating dynamically but not with the thing it's representing.

Doesn't need to be changed immediately, but I think it may work better being coloured (or at least lightened) in line with the local number it's representing.

[Joehuu]

The fixed width doesn't work for other languages. The statistic can probably be autosized x, and the bar fixed to 65. I think it looks fine if the text is exceeds the bar (right now in english, the approach rate text is 70 and exceeds it).

[frenzibyte]

I've adjusted that in some form in 6ca3685, now all statistics accumulate a width enough for the longest label across them.

[Joehuu]

Size invalidation doesn't seem to work reliably. Can reproduce when pressing up/down arrows on language dropdown.

Also I'm not really fond of this extreme case (one long translation and all others are wide):

[frenzibyte]

Also I'm not really fond of this extreme case (one long translation and all others are wide):

I'm not sure that can be improved besides adding some spacing between the count and difficulty statistics, unless you have any bright ideas I'm not interested in dissecting this.

[Joehuu]

As I've said in the initial review, have the bar have a fixed width and text autosize. I consider this less broken than the huge amounts of whitespace in my previous image:

The figma also shows approach rate text width slightly over than the bar, unless that's an oversight.

[frenzibyte]

How would this look if a statistic in the middle has a longer label than everything else, the bars will no longer be equally spaced and it'll look awkward in my eyes.

[Joehuu]

You might have a point, so I'll just wait for other opinions.

[peppy]

Closing this PR as un-reviewable due to chained PRs with unclear dependencies.

For changes of this size, it's nigh impossible to review on a per-PR basis. Some PRs in the sequence are very unclear on why they "depend" on the previous PR. There are hundreds of commits but individual commits are not meaningful.

#32673 -> #32480 -> #32496 -> #32533 -> #32715

will (attempt) review of #32715 alone