went over the test failures, despite every single one managing to fail all of them seem to be the usual suspects unrelated to my changes

went over the test failures, despite every single one managing to fail all of them seem to be the usual suspects unrelated to my changes

Clearly not. TestDifficultyIconSelecting et al. are exercising the behaviour of being able to select a difficulty clicking on the old difficulty icons (and this also includes switching ruleset). You've removed it by migrating to DifficultySpectrumDisplay which does not support this.

Now we may want to get rid of that behaviour (it was a point of frequent confusion for users), but that should have had preceding discussion, and if accepted, should be handled by removing the broken tests.

right my bad didnt make the connection will go over that, and well about preceeding dicussion i thought the design having the difficulty spectrum served as implicit acceptance that this is the way forward, but i guess not

@ppy/area-client in your view, should the behaviour of clicking on difficulty icons on the carousel panels navigating to said difficulty be retained with this design?

Personally leaning no, since the functionality was confusing and the new design has hit targets too small for that to ever work well.

@ppy/area-client in your view, should the behaviour of clicking on difficulty icons on the carousel panels navigating to said difficulty be retained with this design?

I think to some degree. I still want to change rulesets there easily if a beatmap had multiple. If it was just changing difficulty, I would just click the panels as they are easier to click.

as an aside https://discord.com/channels/188630481301012481/188630652340404224/1063846141260746843 it seems my little attempt at circumventing colour bleeding around the main colour of the carousel header doesn't work when opacity is involved, given this is the case shall i just let the colour bleed a little or attempt to use buffered containers and incur the performance hit, not sure how big it is so im asking just incase

in your view, should the behaviour of clicking on difficulty icons on the carousel panels navigating to said difficulty be retained with this design?

My opinion has unchanged - I don't like having auxiliary methods to do things as it increases cognitive load and UX-wise smaller elements are hard to aim at. Plus, click-object-inside-click-object and scroll-field-inside-scroll-field feels shocking to use.

It doesn't make any sense with the new design. Removing is fine for now.

1: What's going on here? In the design, there's a shadow layer under each panel, but visually it seems like there's a misalignment only for the selected panel. is this intentional? Is the shadow layer intentionally missing? What is this even @arflyte are you misaligning elements or is it intentional? @arflyte can you please document your designs better so we don't have to go through this every time?

2: Will require attention. The previous implementation used buffering for the background layer, something similar may need to be applied here.

Glow and gradient border colours don't match new design and feel off.

Unrelated but ConstrainedIconContainer cuts off edge pixels of icons and makes them look very shoddy. Noticed in another recent PR, but now that it's being used in every carousel panel it's a lot more obvious.

The design is intentional and not misalignment; it's to highlight the selected item better. Also I wanted the selected item to glow, hence the shadow is removed (coz glow and shadow at the same time is kinda weird).

Unrelated but ConstrainedIconContainer cuts off edge pixels of icons and makes them look very shoddy. Noticed in another recent PR, but now that it's being used in every carousel panel it's a lot more obvious.

is this implying i should remove it or just that it needs to be fixed elsewhere?

1: What's going on here? In the design, there's a shadow layer under each panel, but visually it seems like there's a misalignment only for the selected panel. is this intentional? Is the shadow layer intentionally missing? What is this even @arflyte are you misaligning elements or is it intentional? @arflyte can you please document your designs better so we don't have to go through this every time?

2: Will require attention. The previous implementation used buffering for the background layer, something similar may need to be applied here.

Glow and gradient border colours don't match new design and feel off.

will go over these in detail

Have updated the design (and experimented with an animation):

Not really confident about my right arrow animation, but that's what I would do.

The code quality has taken a hit as existing components are not flexible and would need a refactor. Let me know if it's worth it (i.e. abstracting CarouselHeader).

something is wrong with this (the gray weird on the edge)

I'd probably except the caret arrow to move with the animation rather than just fade in static.

But I mean this whole design is missing any motion and life. I guess I'll have to put on my motion design hat since it's impossible to get any kind of motion from flyte.

Will try to update this with single diff display throughout the weekend.

Pushing with whatever progress I made in the past.

Haven't addressed the dynamic shearing as commented in https://discord.com/channels/188630481301012481/188630652340404224/1182168002741948426, as it may be involved (i.e. to get the fancy dynamic shear fill flow, you would need to negate the dynamic shear on every child). I would just go with no shear for now, and do a follow-up when adding customisation options.

This probably needs to be rewritten as new V2 components, but I don't know where to start (i.e. continue this PR or make a fresh PR?). I would prefer a fresh PR, but just asking before I do it. Also, can reconsider unassigning myself to someone with more time/competence based on this discord message, so I can focus more on the wedge.