What the actual heck is that magic number stupidity.
I'm not looking into why the test falls over so badly that it apparently
dies on some main menu logic just because assertions fail, because the
main menu logic is for hold-to-song-select-v2 and is thus temporary.
This aims to bring some conformity to naming to make it easier to
understand component structure for new components.
Renames are pulled out of the song select v2 changes and are more
relevant there due to many new classes being added.
- `V2` suffix is dropped, with v2 components being moved to a relevant V2 namespace.
- Related classes have a prefix of the area they are used.
- Experimenting with using partial/nested classes in the song select v2 implementation.
Not committing to this yet but want to see how it plays out.
- Moved base carousel components to a generic namespace to avoid confusion with actual beatmap carousel implementation.
The idea of specifying "bleed" is to make the carousel aware of its
vertical display area. The top bleed is under the filter control; bottom
beneath the toolbar. At the end of the day, the point of panel X offset
incursion, and the scroll target for current selection, should be at the
centre of the screen.
The fixes match code which already exists in the previous
implementation. Basically, without incorporating `BleedTop` into
calculations a second time, the centre position would not match
expectations (of being the centre including bleed).
RFC. Another attempt at this.
- Supersedes https://github.com/ppy/osu/pull/31881
- Supersedes / closes https://github.com/ppy/osu/pull/31355
- Closes https://github.com/ppy/osu/issues/29861
This is a weird diff because I am feeling rather boxed in by all the
constraints, namely that:
- Leaderboard state should be global state
- But the global state is essentially managed by song select and namely
`BeatmapLeaderboard` itself. That's because trying to e.g. not have
`BeatmapLeaderboard` pass the beatmap and the ruleset to the global
leaderboard manager is worse, as it essentially introduces two
parallel paths of execution that need to be somehow merged into one
(as in I'd have to somehow sync `LeaderboardManager` responding to
beatmap/ruleset changes with `BeatmapLeaderboard` which is inheritance
hell)
- Also local leaderboard fetching is data-push (as in the scores can
change under the leaderboard manager), and online leaderboard fetching
is data-pull (as in the scores do not change unless the leaderboard
manager does something). Also online leaderboard fetching can fail.
Which is why I need to still have the weird setup wherein there's a
`FetchWithCriteriaAsync()` (because I need to be able to respond to
online requests taking time, or failing), but also the
`BeatmapLeaderboard` only uses the public `Scores` bindable to
actually read the scores (because it needs to respond to new local
scores arriving).
- Another thing to think about here is what happens when a retrieval
fails because e.g. the user requested friend leaderboards without
having supporter. With how this diff is written, that special
condition is handled to `BeatmapLeaderboard`, and
`LeaderboardManager`'s state will remain as whatever it was before
that scope change was requested, which may be considered good or it
may not (I imagine it's better to show scores in gameplay than not in
this case, but maybe I'm wrong?)
I had a bit of a struggle getting header traversal logic to work well.
The constraints I had in place were a bit weird:
- Group panels should toggle or potentially fall into the prev/next
group
- Set panels should just traverse around them
The current method of using `CheckValidForGroupSelection` return type
for traversal did not mesh with the above two cases. Just trust me on
this one since it's quite hard to explain in words.
After some re-thinking, I've gone with a simpler approach with one
important change to UX: Now when group traversing with a beatmap set
header currently keyboard focused, the first operation will be to reset
keyboard selection to the selected beatmap, rather than traverse.
I find this non-offensive – at most it means a user will need to press
their group traversal key one extra time.
I've also changed group headers to always toggle expansion when doing
group traversal with them selected.
To make all this work, the meaning of `Activation` has changed somewhat.
It is now the primary path for carousel implementations to change
selection of an item. It is what the `Drawable` panels call when they
are clicked.
Selection changes are not performed implicitly by `Carousel` – an
implementation should decide when it actually wants to change the
selection, usually in `HandleItemActivated`.
Having less things mutating `CurrentSelection` is better in my eyes, as
we see this variable as only being mutated internally when utmost
required (ie the user has requested the change). With this change,
`CurrentSelection` can no longer become of a non-`T` type (in the
beatmap carousel implementation at least).
This might pave a path forward for making `CurrentSelection` typed, but
that comes with a few other concerns so I'll look at that as a
follow-up.