-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Merged by Bors] - Hierarchy commandization #4197
Conversation
We should probably merge #4168 before merging this, but I can do more rebasing if needed... |
The intention is that this won't be merged until we have bevyengine/rfcs#53 is merged. Still quite some hefty few TODOs here too. |
e7ef4a5
to
82febea
Compare
The associated RFC has been merged. I'll update the PR to match the design there. |
This is normal behaviour with NLL: |
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.
Generally looks good to me!
} | ||
let mut parent = world.entity_mut(self.parent); | ||
if let Some(mut children) = parent.get_mut::<Children>() { | ||
if !children.contains(&self.child) { |
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.
Is this check necessary? Given that this is now transactional, won't children
only contain child
if child
already has the Parent
component pointing to self.parent
? In that case, the update_parent
call would have returned Some(self.parent)
and AddChild
would early return on line 101.
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 doing this check could result in duplicate children if the hierarchy is altered directly via World
. It's highly unlikely given that there's no easy way to make those edits, but it is doable.
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.
Reasonable. O(n)
behavior (especially in the context of something that will likely happen regularly at runtime) is nasty enough that I think its worth considering omitting this check. But thats a controversial enough conversation that its probably worth having separately and biasing toward correctness here.
bors r+ |
## Objective Implement absolute minimum viable product for the changes proposed in bevyengine/rfcs#53. ## Solution - Remove public mutative access to `Parent` (Children is already publicly read-only). This includes public construction methods like `Copy`, `Clone`, and `Default`. - Remove `PreviousParent` - Remove `parent_update_system` - Update all hierarchy related commands to immediately update both `Parent` and `Children` references. ## Remaining TODOs - [ ] Update documentation for both `Parent` and `Children`. Discourage using `EntityCommands::remove` - [x] Add `HierarchyEvent` to notify listeners of hierarchy updates. This is meant to replace listening on `PreviousParent` ## Followup - These changes should be best moved to the hooks mentioned in #3742. - Backing storage for both might be best moved to indexes mentioned in the same relations.
#4197 intended to remove all `pub` constructors of `Children` and `Parent` and it seems like this one was missed. Co-authored-by: devil-ira <justthecooldude@gmail.com>
## Objective Implement absolute minimum viable product for the changes proposed in bevyengine/rfcs#53. ## Solution - Remove public mutative access to `Parent` (Children is already publicly read-only). This includes public construction methods like `Copy`, `Clone`, and `Default`. - Remove `PreviousParent` - Remove `parent_update_system` - Update all hierarchy related commands to immediately update both `Parent` and `Children` references. ## Remaining TODOs - [ ] Update documentation for both `Parent` and `Children`. Discourage using `EntityCommands::remove` - [x] Add `HierarchyEvent` to notify listeners of hierarchy updates. This is meant to replace listening on `PreviousParent` ## Followup - These changes should be best moved to the hooks mentioned in bevyengine#3742. - Backing storage for both might be best moved to indexes mentioned in the same relations.
bevyengine#4197 intended to remove all `pub` constructors of `Children` and `Parent` and it seems like this one was missed. Co-authored-by: devil-ira <justthecooldude@gmail.com>
## Objective Implement absolute minimum viable product for the changes proposed in bevyengine/rfcs#53. ## Solution - Remove public mutative access to `Parent` (Children is already publicly read-only). This includes public construction methods like `Copy`, `Clone`, and `Default`. - Remove `PreviousParent` - Remove `parent_update_system` - Update all hierarchy related commands to immediately update both `Parent` and `Children` references. ## Remaining TODOs - [ ] Update documentation for both `Parent` and `Children`. Discourage using `EntityCommands::remove` - [x] Add `HierarchyEvent` to notify listeners of hierarchy updates. This is meant to replace listening on `PreviousParent` ## Followup - These changes should be best moved to the hooks mentioned in bevyengine#3742. - Backing storage for both might be best moved to indexes mentioned in the same relations.
bevyengine#4197 intended to remove all `pub` constructors of `Children` and `Parent` and it seems like this one was missed. Co-authored-by: devil-ira <justthecooldude@gmail.com>
## Objective Implement absolute minimum viable product for the changes proposed in bevyengine/rfcs#53. ## Solution - Remove public mutative access to `Parent` (Children is already publicly read-only). This includes public construction methods like `Copy`, `Clone`, and `Default`. - Remove `PreviousParent` - Remove `parent_update_system` - Update all hierarchy related commands to immediately update both `Parent` and `Children` references. ## Remaining TODOs - [ ] Update documentation for both `Parent` and `Children`. Discourage using `EntityCommands::remove` - [x] Add `HierarchyEvent` to notify listeners of hierarchy updates. This is meant to replace listening on `PreviousParent` ## Followup - These changes should be best moved to the hooks mentioned in bevyengine#3742. - Backing storage for both might be best moved to indexes mentioned in the same relations.
bevyengine#4197 intended to remove all `pub` constructors of `Children` and `Parent` and it seems like this one was missed. Co-authored-by: devil-ira <justthecooldude@gmail.com>
# Objective - For many UI use cases (e.g. tree views, lists), it is important to be able to imperatively sort child nodes. - This also enables us to eventually support something like the [`order`](https://developer.mozilla.org/en-US/docs/Web/CSS/order) CSS property, that declaratively re-orders flex box items by a numeric value, similar to z-index, but in space. ## Solution We removed the ability to directly construct `Children` from `&[Entity]` some time ago (#4197 #5532) to enforce consistent hierarchies ([RFC 53](https://github.com/bevyengine/rfcs/blob/main/rfcs/53-consistent-hierarchy.md)). If I understand it correctly, it's currently possible to re-order children by using `Children::swap()` or `commands.entity(id).replace_children(...)`, however these are either too cumbersome, needlessly inefficient, and/or don't take effect immediately. This PR exposes the in-place sorting methods from the `slice` primitive in `Children`, enabling imperatively sorting children in place via `&mut Children`, while still preserving consistent hierarchies. --- ## Changelog ### Added - The sorting methods from the `slice` primitive are now exposed by the `Children` component, allowing imperatively sorting children in place (Useful for UI scenarios such as lists)
Objective
Implement absolute minimum viable product for the changes proposed in bevyengine/rfcs#53.
Solution
Parent
(Children is already publicly read-only). This includes public construction methods likeCopy
,Clone
, andDefault
.PreviousParent
parent_update_system
Parent
andChildren
references.Remaining TODOs
Parent
andChildren
. Discourage usingEntityCommands::remove
HierarchyEvent
to notify listeners of hierarchy updates. This is meant to replace listening onPreviousParent
Followup