-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update UserGridPanel
layout
#22184
base: master
Are you sure you want to change the base?
Update UserGridPanel
layout
#22184
Conversation
Test failures appear to be relevant. |
From going through card usages I've found that some API calls that populate user data seem to not have information required for the cards:
Should I create an issue on osu-web or just hide the parts that are not being populated (as I already do with the playmode)? |
osu.Game/Users/UserPanel.cs
Outdated
@@ -61,27 +61,31 @@ protected UserPanel(APIUser user) | |||
[Resolved] | |||
protected OsuColour Colours { get; private set; } = null!; | |||
|
|||
protected virtual bool ShouldCreateUserCoverBackground { get; set; } = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a real strained relationship with these sorts of properties. Half the time these work ok, half the time they turn out to be a horrible mistake N months later down the lane when another design comes that doesn't fit the overfitted abstraction that these provide.
It's probably fine to have it for now, but it's written weird/wrong right now. It should be either a get
-only virtual property, or a get; init
non-virtual one - having it settable at any point is kind of a lie since it only has an effect when read once in BDL.
If I were to change this any further, I'd probably go for something like a IEnumerable<Drawable> CreateBackground()
method, that in this implementation creates the box and the cover, and only the box in the one that doesn't want the cover. That's slightly less specific than this current setup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll go with the CreateBackground()
osu.Game/Users/UserListPanel.cs
Outdated
@@ -28,7 +28,7 @@ public UserListPanel(APIUser user) | |||
[BackgroundDependencyLoader] | |||
private void load() | |||
{ | |||
Background.Width = 0.5f; | |||
Background!.Width = 0.5f; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah no please don't do this. Debug.Assert()
is much preferred.
That said if you go with my other CreateBackground()
suggestion then this all can be refactored out to not require any of these gymnastics. It will result in some code duplication but I think it's fine.
osu.Game/Users/UserGridPanel.cs
Outdated
|
||
protected override bool OnHover(HoverEvent e) | ||
{ | ||
hoverDim?.FadeTo(0.2f, 200); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might wanna put an easing on these, it looks pretty bad right now. OutQuint
is what most of everything uses.
I think web is well within its right to not return these. They are both ruleset-sensitive pieces of data and it is unclear for which ruleset data should be returned in both cases. |
|
I suppose it is, although I don't know if that makes sense either. Like even bots seem to have ruleset set, while I'd probably accept null as the most viable alternative there. Dunno. Maybe worth asking the web team, but I feel like the endpoints in question are likely to be returning |
Co-authored-by: Bartłomiej Dach <[email protected]>
I don't quite get this design. Feels like a regression from what we currently have. Here's some initial feedback: The level badge looks wrong proportionally. There's too much empty space or the font weight is too low or somethingDimming on hover feels back-to-front. No border makes it feels like the cards are hardly even responding to the mouse.2023-01-15.02.46.27.mp4Also the bottom status part of the card not changing on hover feels bad. Corner radius mismatches feel badColour lines feel unbalanced and hard to readOverlap galoreI dunno. The balance is just off |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not looking at code, but design-wise this needs some further thought.
For whatever that's worth I suggested that (out of thin air) because as usual there are no hover states on design. The thought process was that the beatmap listing is also doing a similar thing by dropping colours a shade darker on hover. |
I have a feeling I made the same comment for the beatmap cards too. I guess as long as they match let's go with it, but it definitely doesn't feel good here. Maybe the dim needs to be increased. The transition time definitely needs to be faster (match beatmap card?), and it should affect the status area too. |
A lot of overlap/balance issues might be coming from the card width - designs keep them at 375, which most of the card usages in game have them way smaller (as well as incosistent). I can try updating widths to the design, at least to see if that helps. I will update the hover state to be the same as beatmap cards |
Hmm, probably this needs to go back to the drawing board (without changing too much). |
@arflyte for the corner radius issue, adding a small amount of padding around the avatar will likely fix it. for the level badge, making the edge (shape) border thicker and changing the text size based on how many digits to better fit will likely work well. not sure about the colour lines. the height definitely feels weird no matter how long i look at it. |
Part of #22130
LevelBadge
to useLevelInfo
#22241CombinedGroupBadge
#22280