Improve area positioning behaviour, and add new options for the auto positioning of moveable areas. #6754
Conversation
…sts and im to tired to update snapshots this late
mkalte666
changed the title
|
Preview available at https://egui-pr-preview.github.io/pr/6754-areapositioning |
| } | ||
| } | ||
|
|
||
| /// A moveable position that starts centered |
There was a problem hiding this comment.
| /// A moveable position that starts centered | |
| /// A moveable position that starts with a automatic position |
| if !movable && self.is_movable() { | ||
| self.position = AreaPosition::anchored(Align2::CENTER_CENTER, [0.0, 0.0]); | ||
| } | ||
|
|
||
| self |
There was a problem hiding this comment.
What about the interactable flag?
There was a problem hiding this comment.
... Oops , forgot that
There was a problem hiding this comment.
Logic wise, The "movable" window can still be positioned via override_pos (or current_pos). So i think a note saying "you can set this to movable, and disable interactions, so the window will never actually be movable in the end.
I don't know when you'd want this, though.
I'll think about this more.
| AreaPosition::Fixed(pos) => *pos = current_pos.into(), | ||
| AreaPosition::Anchored { .. } => {} | ||
| AreaPosition::Moveable { |
There was a problem hiding this comment.
Maybe we should add a debug_assert or at least a log warning when with the current position type something isn't supported?
| Centered, | ||
|
|
||
| /// Put the area at a position. This will take [`Area::pivot`] into consideration. | ||
| Position(Pos2), |
There was a problem hiding this comment.
Would it make sense to move pivot into here?
There was a problem hiding this comment.
That would make pivot only affect the initial position, instead of any current position. (i.g what is set via Area::current_position for overriding). That said, it might make sense to make it a property only of movable windows and fixed positioned windows - as far as i can see it anchoring always anchors corners to coners / center to center + offset. I'll try to incorporate this and the above points once i have time, though it might be a week or three until i find some again. sorry x.x
When i did the quick implementation for movable modals for #6749 @lucasmerlin pointed out that that just forcibly recentering a modal if it is movable is a bit odd.
It would be nicer if this was an inherent property of Areas.
This is a surprisingly small change set, considering the wide impact it has, so i went with a pr directly, instead of an issue.
Investigating this, i figured that some area is quite Stateful in its positioning.
Instead of keeping default_pos, new_pos, anchor as seperate entities, i have implemented its internal position using a new enum,
AreaPosition, that now encodes the different types of position an area can have.I have also quickly thrown together a demo, that i will expand on with test cases.
The way it is done now is that all the old builder methods still exist and behave the same, though the colliding states (setting area movable while an anchor is set, for example) now overwrite each other. In practice this should not change anything, i think?
Things that are still to-do before this can be merged in the first place:
Area::get_pivotpreviously only reported TOP_LEFT; or if set, the anchor. Was that correct? - im now reporting the pivot instead. Needs trying out.