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.
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.
Closes https://github.com/ppy/osu/issues/28938.
This is related to reloading the composer on timing point changes in
scrolling rulesets. The lack of unsubscription from this would cause
blueprints to be created for disposed composers via the
`hitObjectAdded()` flow.
The following line looks as if a sync load should be forced on a newly
created placement blueprint:
da4d37c4ad/osu.Game/Screens/Edit/Compose/Components/ComposeBlueprintContainer.cs (L364)
however, it is not the case if the parent
(`placementBlueprintContainer`) is disposed, which it would be in this
case. Therefore, the blueprint stays `NotLoaded` rather than `Ready`,
therefore it never receives its DI dependencies, therefore it dies on
an `EditorBeatmap` nullref.
Touched on in https://github.com/ppy/osu/discussions/28581.
After a bit more usage of the editor I do agree with this and think that
making the fades a bit more gentle helps a lot.
Closes https://github.com/ppy/osu/issues/28741.
Regressed in a7b066f3ee.
The intent of the original change there was to ensure that addition
banks being set will put the ternary state toggles in indeterminate
state (to at least provide a visual indication that the selection does
not use a single bank). This would previously not be the case due to
the use of `.All()` in the original condition (a single object/node
was considered to have a bank enabled if and only if *all* samples
within it used it). However the attempt to fix that via switching
to `Any()` was not correct.
The logic used in the offending commit operates on extracted `Samples`
and `NodeSamples` from the selection, and would consider the ternary
toggle:
- fully off if none of the samples/node samples contained a sample with
the given bank,
- indeterminate if the some of the samples/node samples contained a
sample with the given bank,
- fully on if at least one sample from every samples/node samples
contained a sample with the given bank.
This is a *two-tiered* process, as in first a *binary* on/off state is
extracted from each object's samples/node samples, and *then* a ternary
state is extracted from all objects/nodes. This is insufficient to
express the *desired* behaviour, which is that the toggle should be:
- fully off if *none of the individual samples in the selection* use
the given bank,
- indeterminate if *at least one individual sample in the selection*
uses the given bank,
- fully on if *all individual samples in the selection* use the given
bank.
The second wording is flattened, and no longer tries to consider "nodes"
or "objects", it just looks at all of the samples in the selection
without concern as to whether they're from separate objects/nodes
or not.
To explain why this discrepancy caused the bug, consider a single object
with a `soft` normal bank and `drum` addition bank. Selecting the object
would cause a ternary button state update; as per the incorrect logic,
there were two samples on the object and each had its own separate
banks, so two ternary toggles would have their state set to `True`
(rather than the correct `Indeterminate`), thus triggering a bindable
feedback loop that would cause one of these banks to win and actually
overwrite the other.
Note that the addition indeterminate state computation *still* needs
to do the two-tiered process, because there it actually makes sense (for
a selection to have an addition fully on rather than indeterminate,
*every* object/node *must* contain that addition).
