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.
This was pointed out as an issue in the osu!taiko editor, but actually
affects all rulesets. Has now been fixed everywhere.
---
Closes https://github.com/ppy/osu/issues/31548.
osu!mania could arguable be consdiered "more correct" with the old
display, but I don't think it's a huge deal either way (subjective at
best).
Closes https://github.com/ppy/osu/issues/25608.
Logic mostly matching stable. All operations are done on `ComboOffset`
which still makes overridden combo colours weirdly relatively dependent
on each other rather than them be an "absolute" choice, but alas...
As per stable, two consecutive new combos can use the same colour only
if they are separated by a break:
52f3f75ed7/osu!/GameModes/Edit/Modes/EditorModeCompose.cs#L4564-L4571
This control is only available once the user has changed the combo
colours from defaults; additionally, only a single new combo object
must be selected for the colour selector to show up.
As I look into re-implementing the ability to choose combo colour for an
object (also known as "colourhax") from the editor UI, I stumble upon
these wretched ternary items again and sigh a deep sigh of annoyance.
The structure is overly rigid. `TernaryItem` does nothing that
`DrawableTernaryItem` couldn't, except make it more annoying to add
specific sub-variants of `DrawableTernaryItem` that could do more
things.
Yes you could sprinkle more levels of virtuals to
`CreateDrawableButton()` or something, but after all, as Saint Exupéry
says, "perfection is finally attained not when there is no longer
anything to add, but when there is no longer anything to take away."
So I'm leaning for taking one step towards perfection.
No issue thread for this, was pointed out internally:
https://discord.com/channels/90072389919997952/1259818301517725707/1316604605777444905
Due to the custom setup that editor has with its nested
"screens-that-aren't-screens", the logic that selects the closest
timing point to the current time would only fire on the first open of
the screen. Seems like a good idea to have it fire every time instead.