The subscription in which the guards were present was moved from
constructor to `ApplyDefaults()`, and at that point neither the sample
control point or the difficulty point can be the default point, because
there are explicit paths that overwrite those with blank points in the
same methods, prior to the subscription's registration.
The only worry would be that someone would set the default point on the
object themselves, but at that point that is most likely programmer
error anyhow.
In editor contexts, the `StartTimeBindable` subscription in `HitObject`
was firing before defaults were applied, which in the case of sliders
manifested in an infinite end time. `ApplyDefaults()` also did not
always set the time of the control point to the correct value, which
matters when the beatmap is encoded.
Ensure that the control points receive the correct time values during
default application, and only register the `StartTimeBindable` change
callback after defaults have been successfully applied.
Previously the slider path length would be snapped using the current
beat snap setting on *every* change of the slider path. As it turns out
this is unexpected behaviour in some situations (e.g. when reversing a
path, which is expected to preserve the previous duration, even though
the slider may be technically "unsnapped" at that point in time due to a
different beat snap setting being selected afterwards).
This has come up multiple times, with mappers citing that they have
muscle memory for mapping based on the centre of the playfield being in
the centre of the window.
The original plan was to have a second toolbar on the right hand side of
the screen to balance the padding, but we're not at that point yet.
Easiest solution is to do what stable does and allow the left-hand
toolbar items to overlap the playfield underneath it.
In edge cases where the user is running at an aspect ratio that causes
overlaps, they can choose to collapse the toolbars down. We can probably
work on this UI/UX a bit more as we update designs to be more friendly
to such cases.
The taiko-slider is not included in `Playfield`, so it doesn't get hidden when calling `drawableRuleSet.Playfield.Hide()`. Calling `drawableRuleSet.Hide()` hides the taiko-slider, in addition to the rest of the `Playfield`.
