This sort of thing has been showing up on flyte designs more and more
so I want to start using it more over that rather ugly "overlined" text
that's there on multiplayer screens right now.
Closes https://github.com/ppy/osu/issues/25426.
Different approach to prior ones, this just disables the relevant
actions when something related to save/export is going on. Still ends up
being convoluted because many things you wouldn't expect to touch save
do touch save, so it's not just a concern between export and save
specifically.
Closes https://github.com/ppy/osu/issues/28369.
The reporter of the issue was incorrect; it's not the beat snap grid
that is causing the problem, it's something far stupider than that.
When the current selection changes,
`EditorSelectionHandler.UpdateTernaryStates()` is supposed to update the
state of ternary bindables to reflect the reality of the current
selection. This in turn will fire bindable change callbacks for said
ternary toggles, which heavily use `EditorBeatmap.PerformOnSelection()`.
The thing about that method is that it will attempt to check whether any
changes were actually made to avoid producing empty undo states, *but*
to do this, it must *serialise out the entire beatmap to a stream* and
then *binary equality check that* to determine whether any changes were
actually made:
7b14c77e43/osu.Game/Screens/Edit/EditorChangeHandler.cs (L65-L69)
As goes without saying, this is very expensive and unnecessary, which
leads to stuff like keeping a selection box active while a taiko beatmap
is playing under it dog slow. So to attempt to mitigate that, add
precondition checks to every single ternary callback of this sort to
avoid this serialisation overhead.
And yes, those precondition checks use linq, and that is *still* faster
than not having them.
Not only is this simpler, but it also is more correct (for explanation
why, try holding both shift keys while dragging, and just releasing one
of them - the previous code would briefly turn aspect ratio off).
Closes https://github.com/ppy/osu/issues/22783.
If the difficulty being edited has unsaved changes, the editor exit flow
would prompt for save *after* the deletion method has run. This is
undesirable from a UX standpoint, and also leaves the user in a broken
state.
Thus, just fake an update of the last saved hash of the beatmap to fool
the editor into thinking that it's not dirty, so that the exit flow will
not show a save dialog.
