Sizing-pass flag #4535
Assignees
Milestone
Comments
emilk
added a commit
that referenced
this issue
May 29, 2024
…enus in particular (#4557) * Part of #4535 * Closes #3974 This adds a special `sizing_pass` mode to `Ui`, in which we have no centered or justified layouts, and everything is hidden. This is used by `Area` to use the first frame to measure the size of its contents so that it can then set the perfectly correct size the subsequent frames. For menus, where buttons are justified (span the full width), this finally the problem of auto-sizing. Before you would have to pick a width manually, and all buttons would expand to that width. If it was too wide, it looked weird. If it was too narrow, text would wrap. Now all menus are exactly the width they need to be. By default menus will wrap at `Spacing::menu_width`. This affects all situations when you have something that should be as small as possible, but still span the full width/height of the parent. For instance: the `egui::Separator` widget now checks the `ui.is_sizing_pass` flag before deciding on a size. In the sizing pass a horizontal separator is always 0 wide, and only in subsequent passes will it span the full width.
emilk
added a commit
that referenced
this issue
May 29, 2024
…#4570) * Closes #4452 The `ComboBox` popup has a justified layout to make selection of items easier. Thanks to [the new sizing pass logic](#4535) we don't have to know the final width in advance: 
This was referenced Jun 5, 2024
emilk
added a commit
that referenced
this issue
Jun 5, 2024
) * Part of #4535 This should improve the auto-sizing of columns when nesting expanding widgets (e.g. `Separator`), or centered or justified layouts.
emilk
added a commit
that referenced
this issue
Jun 5, 2024
) * Closes #4535 This should improve the auto-sizing of columns when nesting expanding widgets (e.g. `Separator`), or centered or justified layouts.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
The first frame we shown an Area or a Grid we only measure the size of everything, but don't show anything to the user. This the first frame becomes a size-measuring pass. This is a poor-mans two-pass mode.
A common problem is "How wide do we need to make this area"? (e.g. a menu).
We usually want to set a max width of e.g. 400 points, at which we should start wrapping.
But if we can keep things more narrow, that's better.
Now consider a widget that expands to fill its parent, e.g. a
Separator.It will the first frame expand to the full max width, and then the min width = max width, and so we will always expand to the maximum allowed with. This is bad, causing menus to become overly wide.
For more details, see #843
Solution
We set a simple boolean flag for the sizing pass.
Widgets that expand to fill the max_width would first check this flag, and if set, they would not expand, but only allocate the minimum size they actually need.
When the sizing pass finishes, we store the final size in the
Areastate (or whatever), and then next frame we have a properly sized area.This flag would be passed down to child UIs.
Would close
Other related
The text was updated successfully, but these errors were encountered: