Mod customization header/panel changes

[Fabep]

Removed on click event for the mod customization header, As of #29618 .

Renamed ModCustomisationPanelState, since only mods set the "old" Expanded panel state.

Further suggestions that could be applied to this area:

• Refactor mods that use the ExpandedByMod state to set parameters directly, for example copy attributes from current map when you enable difficulty adjustments.
• Keep colourprovider.light4 on the header when the mod customization panel is expanded. (I attempted to add this, but I am too stupid to understand how to remove it when the hover is lost & the panel is collapsed). 😃

[peppy]

@Fabep any reason this is marked as a draft?

[bdach]

I have big suspicions this just straight up breaks mobile btw. Haven't confirmed yet.

[Fabep]

@peppy I have no clue 😎
But as bdach said something could break completely for mobile/touch device since the only change is the removal of the click event.

I probably should have attempted at adding some sort of expansion of the panel with the touchdown / touchend? event, but it didn't cross my mind until I read bdach's comment just now.

[peppy]

Reading it, I can't see how it would break mobile. But either way let's just undraft it for proper review.

[peppy]

Haven't tested mobile but seems fine otherwise?

[bdach]

Touch was likely working only by way of the touch-to-synthesised-click pathway, which is evidenced further by stuff like this:

osu/osu.Game/Overlays/Mods/ModCustomisationHeader.cs

Lines 117 to 121 in 363fc0d

	protected override bool OnTouchDown(TouchDownEvent e)
	{
	if (Enabled.Value)
	{
	touchedThisFrame = true;

osu/osu.Game/Overlays/Mods/ModCustomisationHeader.cs

Lines 132 to 133 in 363fc0d

	if (!touchedThisFrame && panel.ExpandedState.Value == ModCustomisationPanelState.Collapsed)
	panel.ExpandedState.Value = ModCustomisationPanelState.Expanded;

So if my hunch is correct then the panel just won't open on mobile at all.

[bdach]

As I suspected, this just broke touch completely. 5211e60 should bring the behaviour more or less to parity with desktop:

Record_2024-09-02-11-37-04_25a1a32208bbcdc1d450b7aa854bb161.mp4

tl;dr: you have to touch the dropdown to open it if it's not forced open by a mod, and touch away from it to close it. Touching the dropdown header when open does nothing which matches desktop.

@peppy requesting re-check to make sure this is the UX you are looking for.

[Fabep]

Keep colourprovider.light4 on the header when the mod customization panel is expanded. (I attempted to add this, but I am too stupid to understand how to remove it when the hover is lost & the panel is collapsed). 😃

Personally for UI purposes, I believe this to be the only thing that could be improved upon. The hover color is now redundant due to the fact that the only way to open the mod customization panel is through the hover (or force open by mod). It would be more clear and "cleaner" to bind the color to it being active or not, e.g dark when collapsed and light when expanded.

I've tried implementing it with the following code snippet inside of the ModCustomisationHeader class.

protected override void LoadComplete()
{
    ...
    panel.ExpandedState.BindValueChanged(v =>
    {
        IdleColour = v.NewValue switch
        {
            ModCustomisationPanelState.Expanded or
            ModCustomisationPanelState.ExpandedByMod => colourProvider.Light4,
            _ => colourProvider.Dark3,
        };
    }, true);
    ...
}

However when I try it functionally it works like the following:

2024-09-02.13-33-22.mp4

This could probably be it's own PR if it's not an easy implementation or just not implemented at all it's just a preference after all 😃

[peppy]

I'm reverting the colour changes. Please make them in a separate PR or something. They look weird and your code formatting is wrong.