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.
Found in testing of previous commit. This would break seeking between
bookmarks.
Reproduction steps on `master`:
- open map with bookmark
- delete the first bookmark
- undo the deletion of the first bookmark
- seek to previous bookmark will now always seek to the first bookmark
rather than closest preceding regardless of current clock time
- Bookmark menu items get disabled when they would do nothing.
- Bookmark deletion only deletes the closest bookmark instead of all of
them within the proximity of 2 seconds to current clock time. Action
is only however *enabled* within 2 seconds of a bookmark.
Additionally, logic was moved out of `Editor` because it's a huge class
and I dislike huge classes if they can be at all avoided.
I was trying to be smart about things and make use of our
`SynchronisationContext` setup, but it turns out to not work in all
cases due to the context being missing depending on where you are
calling the method from.
For now let's prefer the "works everywhere" method of scheduling the
final work back to update.
