Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Generic geometric types #8540

Open
ickshonpe opened this issue May 4, 2023 · 1 comment
Open

Generic geometric types #8540

ickshonpe opened this issue May 4, 2023 · 1 comment
Labels
A-Math Fundamental domain-agnostic mathematical operations C-Enhancement A new feature

Comments

@ickshonpe
Copy link
Contributor

ickshonpe commented May 4, 2023 •
edited
Loading

What problem does this solve or what need does it fill?

We used to have generic Size and Rect types, but they were specialized (for good reasons IMO).

But it's left some ergonomic friction, especially with measures which take separate width and height Option<f32> and AvailableSpace values which be much cleaner with a generic size type that has map and zip methods like Taffy's Size type .

Also, it would be nice to have some sort of GenericSize<Physical> and GenericSize<Logical> for dealing with window resolutions and scalings.

What solution would you like?

Size could be renamed to UiSize and then name the new generic type Size. UiSize is a bit ugly though.

Otherwise, none of the alternative names I came up with like Dimensions, Extent, Measurements, etc seem super intuitive.

Maybe just Size2 would be okay?
@ickshonpe ickshonpe added C-Enhancement A new feature S-Needs-Triage This issue needs to be labelled labels May 4, 2023
@alice-i-cecile alice-i-cecile added A-Math Fundamental domain-agnostic mathematical operations and removed S-Needs-Triage This issue needs to be labelled labels May 4, 2023
@nicoburns
Copy link
Contributor

nicoburns commented May 5, 2023 •
edited
Loading

I think we could probably get rid of the existing Size type entirely, and just flatten the properties using into directly into Style. So instead of:

  • size, min_size, max_size, and gap properties

We'd have:

  • width, height, min_width, min_height, max_width, max_height, row_gap, and column_gap properties

IMO that would be an ergonomic improvement from an end-user perspective.

UPDATE: Implemented in #8548

This was referenced May 5, 2023
Merged
Merged
alice-i-cecile pushed a commit that referenced this issue May 16, 2023
@nicoburns @ickshonpe
Flatten UI Style properties that use Size + remove Size (#8548)
08bf1a6 
# Objective

- Simplify API and make authoring styles easier

See:
#8540 (comment)

## Solution

- The `size`, `min_size`, `max_size`, and `gap` properties have been
replaced by `width`, `height`, `min_width`, `min_height`, `max_width`,
`max_height`, `row_gap`, and `column_gap` properties

---

## Changelog

- Flattened `Style` properties that have a `Size` value directly into
`Style`

## Migration Guide

- The `size`, `min_size`, `max_size`, and `gap` properties have been
replaced by the `width`, `height`, `min_width`, `min_height`,
`max_width`, `max_height`, `row_gap`, and `column_gap` properties. Use
the new properties instead.

---------

Co-authored-by: ickshonpe <david.curthoys@googlemail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-Math Fundamental domain-agnostic mathematical operations C-Enhancement A new feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@nicoburns @alice-i-cecile @ickshonpe