When compiling the example from bevy_crossterm using rustc 1.51.0-nightly (a62a76047 2021-01-13) I got the following errors:

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
  --> /home/odd/.cargo/registry/src/github.com-1ecc6299db9ec823/broccoli-0.7.5/src/tree/container/inner.rs:69:73
   |
69 |     let inner: compt::dfs_order::CompleteTreeContainer<NodePtr<T>, _> = inner.inner.inner.convert();
   |                                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior

error[E0133]: call to unsafe function is unsafe and requires unsafe function or block
  --> /home/odd/.cargo/registry/src/github.com-1ecc6299db9ec823/broccoli-0.7.5/src/tree/container/inner.rs:83:73
   |
83 |     let inner: compt::dfs_order::CompleteTreeContainer<NodePtr<T>, _> = inner.inner.inner.convert();
   |                                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
   |
   = note: consult the function's documentation for information on how to avoid undefined behavior

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0133`.
error: could not compile `broccoli`

Changing broccoli from version 0.7 to 0.20 fixed this.

Primarily updates to be compatible with bevy 0.5, but also:

• Updates for IDE file ignores
• Added a Makefile for development workflow convenience
• Added a .rustfmt file and ran rustfmt
• Bumped bevy_crossterm version to 0.5
• Migrated package uses from within the code up to the top of the code for visibility
• Used clippy suggestions
• Migrated lib.rs structures into their own files

Two logic changes that I think are relevant here.

1. The changes within bevy-0.5 for pipeline stages allows for all of the stages to be executed within a single frame. Previously, we expected only one stage to be executed within a frame. The consequence is that it's less clear how state transitions actually run and also how to handle capturing input from the user. The API appears to have the right pieces, but the execution is no longer simple/intuitive.

2. Because of the changes, we now explicitly update the keys data within the user input handler and we also initiate a cleanup within the same code space because it appears that the on_exit method is actually completely broken for state transitions.

Primarily updates to be compatible with bevy 0.5, but also:

• Updates for IDE file ignores
• Added a Makefile for development workflow convenience
• Added a .rustfmt file and ran rustfmt
• Bumped bevy_crossterm version to 0.5
• Migrated package uses from within the code up to the top of the code for visibility
• Used clippy suggestions
• Migrated lib.rs structures into their own files

Two logic changes that I think are relevant here.

1. The changes within bevy-0.5 for pipeline stages allows for all of the stages to be executed within a single frame. Previously, we expected only one stage to be executed within a frame. The consequence is that it's less clear how state transitions actually run and also how to handle capturing input from the user. The API appears to have the right pieces, but the execution is no longer simple/intuitive.

2. Because of the changes, we now explicitly update the keys data within the user input handler and we also initiate a cleanup within the same code space because it appears that the on_exit method is actually completely broken for state transitions. I have let the on_exit methods in there mostly because I think they should work. However, I've commented them out because they do not actually appear to run as expected.

Fixes #7

Wanted to use this with bevy 0.5, so i updated it into a state that at least allows compiling. Gonna need help fixing the examples and cleaning up my code.

It would be nice to allow parent entities to have a Postition that is then propagated to the children (and so on recursively). One could then easily group and move entities together, instead of separately.

The asset change detection is rough. We have to loop through all asset added/changed events, then loop through ALL entities to see which ones have assets that need to be changed. Not very graceful. There are a few improvements to be made here:

• [ ] Cache which assets are assigned to which entities in a multimap (handleid -> Vec) to avoid needing to loop through all entities to find which ones have assets that changed that frame.
• [ ] After that multimap exists, add an early out if we see 1) no assets we care about changed, 2) no entities changed, and 3) no new entities were added. This will do less work each frame where nothing changes, which will be nice