Change version of bevy_egui to 0.19

[ZeeQyu]

This is to match the version of bevy_egui that bevy-inspector-egui uses

I tested with cargo +nightly test and cargo +nightly run --example example2d --features="vpeol_2d bevy/png" and both seem to work well. It also works in my project. Don't know what other testing to do, but at a first approximation it seems like none of the features yoleck uses have changed between bevy_egui 0.17 and 0.19.

[ZeeQyu]

The reason I wanted to have a matching version of bevy_egui is that when you use the yoleck and inspector-egui at the same time, then .add_plugin(bevy_yoleck::bevy_egui::EguiPlugin) will add a version of EguiContext that's different than what .add_plugin(inspector_egui::WorldInspectorPlugin) adds.

If you try to add both EguiPlugin's at the same time, you get an error saying you have plugins. If you add just one EguiPlugin and try to use both libraries, one of them will fail saying EguiPlugin is missing.

I found the most elegant way of solving this to be just to make sure there was only one version of of bevy_egui in my project. With this patch, I can get the Yoleck editor at the same time as the World Inspector and an instance of the Resource Inspector.

[idanarye]

Thanks! I kind of neglected this, figuring one could always just have one version for the editor and another for the game UI, not realizing that some people want to use one of the scene inspection/editing plugins in the editor.

[ZeeQyu]

Neat! Happy to help.

[ZeeQyu]

Though a thought I had was whether you would want to specify a range of egui-versions. I expect cargo would prefer finding a matching version of two indirect dependencies if one has a range and the other has a fixed version. If so, you could use this library with several versions of, say, inspector_egui.

You'd just need to test this lib against every intermediate egui version in the range, doing a proof by induction so to say.

Is this something you'd be interested in? If so I might do it some lazy evening.

[idanarye]

How will it look from the user's side? I'll just pick the latest version unless some other crate needs a lower version? Or does the user need to explicitly specify which version of bevy_egui they want to use?

And is there a way to make the CI test all the versions? (test = just build the examples)

[ZeeQyu]

What I'm imagining is that you add bevy-yoleck to your Cargo.toml, and then you add one of any inspector-egui versions, and then they just happen to work such that both can be added to the same scene at the same time, since Cargo found a matching version.

I have no clue if this is something cargo does, that would be part of the work. If we're unlucky, maybe the user would need to specify the bevy_egui version somehow.

But if this works as I think it does, the main gain would be if we have a third and fourth library that also depends on egui, cause if enough of them have ranges, you are likely to be able to find a version that matches all of them either automatically or by downgrading one of the packages or something.

I will not promise looking at CI. I might, but I won't promise to, because historically it hasn't made sense to me.

Basically - I don't know if this would work, but if this is not at all interesting to you, then there's no point in me finding out, so that's why I'm asking. Would you be interested in something like this at all? If you are interested in the general idea, then you can find out if you're interested in the specific implementation when I submit a pull request.

[idanarye]

I'm game.

CIs are a pain if you are not used to them. Actually, they are usually a pain even if you are used to them. I'm already familiar with it, so I'll do it myself. I did a quick google and it I think the best way is to update the lock file with

cargo update --package bevy_egui --precise 0.17.0

and I think it'll build with the chosen version, without trying to update it.

Now I just need to figure out a way to automatically resolve the supported versions against crates.io...

[ZeeQyu]

Be my guest!

Though I did some tests, and it seems like Cargo isn't as smart as I want it to be. Even if you run cargo update after adding the dependency, or if you add both primary dependencies at the same time, it will still always use the latest version available within the range. And if you don't cargo update, then it'll just use the locked version.

I get that this also can be correct behaviour, since the expectation is that the newest library has the best code, but it prevents my vision entirely.

So the simple way of dealing with this is just staying on top of updating the dependencies to yoleck and all other packages I guess.

But the best way would probably be finding a way of adding two EguiContexts at the same time, by investigating how bevy checks uniqueness.

[ZeeQyu]

"Now I just need to figure out a way to automatically resolve the supported versions against crates.io..." I don't entirely know which part of the process this refers to, but I stumbled upon a way of getting all the versions of a crate from the command line, in case you need it:

cargo install cargo-info
cargo info bevy_egui -VV

[idanarye]

@ZeeQyu heads up - version 0.6 has some breaking changes (see changelog)

[ZeeQyu]

@idanarye Haha, I noticed the hard way when I updated everything to support bevy 0.10, but thanks for the heads up!

[idanarye]

I think you are my only user so far, so I need to cater for you :wink:. I'm planning some bigger changes (#14), but they'll take some more time to design and implement.

[ZeeQyu]

Haha, I don't know if that's true, you seem to have hundreds of downloads

https://crates.io/crates/bevy-yoleck

But if that's your mentality, then I might be a little bolder in suggesting contributions. I've done some changes in a fork, specifically to 1. allow more content in the editor by just adding a vertical scroll (because as is, that just goes off the screen and becomes inaccessible, and 2. to let a gui element for one entity create another entity, which I've used to create clones of my variable length fences in my game.

I'll contribute this in pull requests soon enough, but if you get curious to see how I use your library, you can check out https://github.com/ZeeQyu/sylt

[ZeeQyu]

Hm, actually, I have no clue how to make 2. elegant, so I'll just make a pull request for 1, and create an issue for 2. where I show you what I did, and you can see if you can find a way to fulfill that need in a general way. If this looks like something you want to support, of course.

[idanarye]

I don't know how many of the downloads on crates.io are my own, so I go by this: https://github.com/search?q=bevy-yoleck&type=code

PRs are always welcome.