Struck me as weird when reviewing https://github.com/ppy/osu/pull/29057.
Like sure, that PR adds the replay button, but it's a bit terrible that
clicking the button quits the daily challenge screen and you're back at
main menu when done watching...?
Also extended to cover playlists and multiplayer, which have the same
issue.
You wouldn't think this would be an actual thing that can happen to us,
but it is. The most important one by far is `MaximumStatistics`; that
is the root cause behind why stuff like spinner ticks or slider tails
wasn't showing.
On a better day we should probably do cleanup to unify these models
better, but today is not that day.
- Convert cursor trail coordinates to local space before storing.
- Apply necessary transformations to align with other UI elements.
- Ensure cursor trail remains connected during UI panel movements.
Closes https://github.com/ppy/osu/issues/29066.
Initially I fixed this at where the assert is right now:
9790c5a574/osu.Game/Screens/Ranking/ResultsScreen.cs (L333)
but because of the weird way that visible state management is done in
this screen that made it possible for the extended statistics to be
visible *behind* the score panels, without the score panels making way
for it. So this is in a way safer, because it prevents the visibility
state of the extended statistics from changing in the first place if
there is no score selected (yet).
This can be also seen in playlists, at least.
Closes https://github.com/ppy/osu/issues/28916.
The previous behaviour *may* have been intended, but it was honestly
quite baffling. This seems like a saner variant.
This sort of thing is bound to happen when rewriting screens from
scratch without invoking abstract eldritch entities sometimes. Damned if
you do, damned if you don't...
Closes https://github.com/ppy/osu/issues/28983.
While the direct cause of this is most likely mouse confine in
full-screen, it shouldn't/can't really be disabled just for this,
and I also get this on linux in *windowed* mode.
In checking other apps, adding some tolerance to this sort of
drag-scroll behaviour seems like a sane UX improvement anyways.
I'm not *super* sure why this works, but it appears to, and my educated
guess as to why is that it counteracts the effects of a change in the SV
of the juice stream by artificially increasing or decreasing the
velocity when running the appropriate path conversions and expected
distance calculations. The actual SV change takes effect on the next
default application, which is triggered by the `Update()` call at the
end of the method.
