Skip to content

Styles/Scale: style values#829

Merged
danirabbit merged 3 commits intomainfrom
danirabbit/styles-scale-value
Apr 15, 2025
Merged

Styles/Scale: style values#829
danirabbit merged 3 commits intomainfrom
danirabbit/styles-scale-value

Conversation

@danirabbit
Copy link
Member

Fixes #800

Screenshot from 2025-04-08 13 23 16

@danirabbit
Copy link
Member Author

@wpkelso One issue here is only TOP and BOTTOM positions follow the slider, so I don't want to style LEFT and RIGHT as osd, but when I add the extends inside &.bottom, &.top the margins break. Any ideas?

@wpkelso
Copy link
Member

wpkelso commented Apr 9, 2025

One issue here is only TOP and BOTTOM positions follow the slider, so I don’t want to style LEFT and RIGHT as osd, but when I add the extends inside &.bottom, &.top the margins break. Any ideas?

@danirabbit I don't see much of a visual difference, but there seems to be an error thrown with it in its current location, while that error goes away when it is moved to be inside &.bottom, &.top. E.g.

Screenshot from 2025-04-09 14 39 05
versus
Screenshot from 2025-04-09 14 38 03

@danirabbit
Copy link
Member Author

@wpkelso look at the vertical alignment of the horizontal scale in your second screenshot. It's way off center compared to the top screenshot

@wpkelso
Copy link
Member

wpkelso commented Apr 14, 2025

@danirabbit It looks like when the extends is placed inside the &.bottom, &.top the overrides for top-margin and bottom-margin aren't cascading correctly (which was probably already clear to you 😅 ). Within Gtk.css they're calculated out to the exact same rem values in the exact same place. There isn't anything further down the file that touches those values.

I haven't been able to figure out why they then get calculated to different pixel values, so maybe it's some weird edge case in rem conversion?

The following are the margins and padding for the value elements in either case. I used 1.25 text scaling on the top image, but that shouldn't create the specific behaviours here.

image

image

@wpkelso
Copy link
Member

wpkelso commented Apr 14, 2025

Thinking about it, rem calculation error is probably the wrong conclusion. It looks like the overrides just aren't getting applied for some reason.

@danirabbit
Copy link
Member Author

@wpkelso I think it was fixed in #840

@danirabbit danirabbit marked this pull request as ready for review April 14, 2025 21:19
@wpkelso
Copy link
Member

wpkelso commented Apr 15, 2025

I think it was fixed in #840

Ah, yup, looks like it. Do we know specifically which change fixed it? Was it the thing where osds couldn't be modified?

@danirabbit
Copy link
Member Author

@wpkelso yeah exactly. Setting the provider priority so that it wasn't always overriding the gtk styles

Copy link
Member

@wpkelso wpkelso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks all tidy to me 🚀

@danirabbit danirabbit enabled auto-merge (squash) April 15, 2025 16:08
@danirabbit danirabbit merged commit 7e3e7c5 into main Apr 15, 2025
5 checks passed
@danirabbit danirabbit deleted the danirabbit/styles-scale-value branch April 15, 2025 16:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Style scale value

2 participants