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.
Originally this was an intentional choice (see
https://github.com/ppy/osu/pull/18088) when these controls were more
transparent and didn't for a solid toolbox area.
But this is no longer the case, so for now let's always block scroll to
match user expectations.
Closes#31262.
More specifically, this fixes placement blueprints not beginning placement when using touch input while the cursor was previously outside compose area, due to the placement blueprint not existing (removed from the scene by `ComposeBlueprintContainer`).
They will not only contract if the user chooses to have them contract
(new setting in the `View` menu) or if the game isn't wide enough to
allow full interaction with the playfield while they are expanded.
Addressess https://github.com/ppy/osu/discussions/28970.
This is in addition to Shift + Right-click.
I thik middle mouse feels more natural and is a good permanent solution
to this issue.
Note that this also *allows triggering the context menu from placement
mode*. Until now it's done nothing. This may be annoying to users with
muscle memory but I want to make the change and harvest feedback. I
think showing the context menu is more correct behaviour (although
arguably it should return to placement mode on dismiss?).
