Add access to App within LogPlugin::update_subscriber

[doonv]

Objective

In my library, bevy_dev_console I need access to App within LogPlugin::update_subscriber in order to communicate with the App from my custom Layer.

Solution

Give access to App.

---

Changelog

• Added access to App within LogPlugin::update_subscriber

Migration Guide

LogPlugin::update_subscriber now has a &mut App parameter. If you don't need access to App, you can ignore the parameter with an underscore (_).

- fn update_subscriber(subscriber: BoxedSubscriber) -> BoxedSubscriber {
+ fn update_subscriber(_: &mut App, subscriber: BoxedSubscriber) -> BoxedSubscriber {
      Box::new(subscriber.with(CustomLayer))
  }

[alice-i-cecile]

Not the most elegant of communication mechanisms, but I can see the value.

Can you add a test and/or example demonstrating this?

[doonv]

Not the most elegant of communication mechanisms, but I can see the value.

Can you add a test and/or example demonstrating this?

I'm not sure if my current solution for app-layer communication is good enough to be featured in an example.

My current solution is to use a Arc<Mutex<T>> where there are 2 instances, one inside the Layer and one in a Resource, this allows information to be tranferred from the Layer to the Resource. I find this solution not that good and more of a bandaid to make it work. (I do not like Arc<Mutex<T>>)

[doonv]

I found a better solution using mpsc channels. Will create an example soon.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[alice-i-cecile]

Ah, I get the point of this feature now! Really useful, and thanks for making an example.

So, I think we can sharpen this example further, and really focus on the specific common use case you demonstrated to showcase the value to users.

Namely, you want to be able to capture all of the logging events that you send in all of your random systems. But rather than duplicating the API to do this directly in the ECS, you're sending them to the logging code first, processing them, and then reading them back in. This is helpful because it works with arbitrary logging statements, you can take advantage of the parsing, and you don't need to add boilerplate anywhere. Great for things like error popups, in additional to your terminal logging.

Okay so:

1. Swap names of example and structs to represent this specific use case (capturing logs in the ECS).
2. Demonstrate that you can log in arbitrary systems: maybe add a couple of buttons that each produce a different log level when pressed?
3. Respond to the produced log levels in the follow-up system, rather than just printing them. A pop-up would be ideal, but if that's too tricky maybe just change the text on screen to match.
4. Swap the filter to show how to only catch errors.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[github-actions]

The generated examples/README.md is out of sync with the example metadata in Cargo.toml or the example readme template. Please run cargo run -p build-templated-pages -- update examples to update it, and commit the file change.

[doonv]

2. Demonstrate that you can log in arbitrary systems: maybe add a couple of buttons that each produce a different log level when pressed?

3. Respond to the produced log levels in the follow-up system, rather than just printing them. A pop-up would be ideal, but if that's too tricky maybe just change the text on screen to match.

4. Swap the filter to show how to only catch errors.

I feel like this is a bit out of scope of the log_layers_ecs example. I only wanted to show how you can transfer logs from the tracing layer to the ECS, nothing else. Everything else can be left as an exercise left to the reader.

[alice-i-cecile]

I only wanted to show how you can transfer logs from the tracing layer to the ECS, nothing else.

In isolation, this feature doesn't seem useful, either to maintainers or to users. They'll read the example, wonder "hmm I wonder what that would be good for" and move on (or try and delete the underlying functionality because it doesn't seem useful). Focusing on a specific tangible use case gives us the freedom to redesign the API to better support that use case, rather than having to guess about how it relates to the actual thing we want to do.

It's okay to do a simplified version of this (no buttons, no pop-up), but I want to make sure the intent is preserved.

[alice-i-cecile]

Great, I'm happy with this now. The small changes went a long way to clarifying intent. Thanks!

[cBournhonesque]

The release notes are incorrect (https://bevyengine.org/learn/migration-guides/0-13-to-0-14/#add-access-to-app-within-logplugin-update-subscriber) because this change has been superseded by #13159

Cc @alice-i-cecile

[alice-i-cecile]

The correct way to fix that is to file a PR request to the bevy-website repo to update the previous migration guide. This note is helpful though.