[Merged by Bors] - Hierarchy commandization#4197
[Merged by Bors] - Hierarchy commandization#4197james7132 wants to merge 24 commits intobevyengine:mainfrom
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: |
| } | ||
| 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.
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.
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.
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.PreviousParentparent_update_systemParentandChildrenreferences.Remaining TODOs
ParentandChildren. Discourage usingEntityCommands::removeHierarchyEventto notify listeners of hierarchy updates. This is meant to replace listening onPreviousParentFollowup