add FontRef and DefaultFont

[IceSentry]

Objective

Creating a TextStyle requires an Handle<Font> which means you either need to pass the text_style around or pass an asset_server everywhere. This makes declaring reusable ui components harder than necessary.

It should be possible to not need to pass around anything and create it where we want it and let bevy take care of loading the font.

Solution

• Introduce a new FontRef inspired by the ShaderRef from the new Material
  • A default font that can be configured globally with the new DefaultFont resource
  • A string path to a font can be automatically converted to a FontRef and the new bevy_text::load_font() system will take care of loading the font asset and converting the path to an Handle<Font>.
  • Keep support for manually loading fonts and convert the Handle to a FontRef::Handle

---

Changelog

• Added FontRef
• Added DefaultFont
• TextStyle now uses FontRef instead of Handle<Font>

Migration Guide

Instead of requiring an asset_server to load a font you can now use a string path to a font asset and bevy will take care of loading it properly. This makes declaring TextStyle components much easier. If you want to keep the asset_server you can easily convert a Handle<Font> to a FontRed using .into().

// 0.8
commands.spawn_bundle(TextBundle::from_section(
    "hello bevy!",
    TextStyle {
        font: asset_server.load("fonts/FiraSans-Bold.ttf"),
		..default()
    },
));

// 0.9
commands.spawn_bundle(TextBundle::from_section(
    "hello bevy!",
    TextStyle {
        font: "fonts/FiraSans-Bold.ttf".into(),
		..default()
    },
));

Notes

I updated all the examples using fonts, but I only used the new DefaultFont on the game_menu example.
If anyone is scared of the amount of files changed, the vast majority of the changes in most files are just converting existing asset_server.load() to the new FontRef.

Closes #5515

[mockersf]

If the DefaultFont resource has not been set, would it make sense to pick the first font available in Assets<Font> and only fail if there isn't one?

[IceSentry]

That could work, but this new api encourages people to just use "path/to/font.ttf".into() everywhere which would mean it's very possible a font won't be loaded by the time it reaches a FontRef::Default.

Even if it did, it would be a bit weird how order dependent it would become. Like you change the order of a ui widget and now suddenly all the text in your app looks different.

[IceSentry]

I don't mind doing it as a fallback, but personally I'd rather get an error if it's not set. Eventually, once we ship an editor we'll be able to ship a font and initialize the resource with a default value, but right now it feels less error prone to not do that. Eventually we could also load the system font, but that should be done in a separate PR.

[IceSentry]

Alright, I implemented the fallback to the first font on default, but as I expected if the fonts are added in the same system it doesn't work because the font isn't added to the assets store yet.

I also fixed a bug where text wouldn't load on startup in desktop_app mode.

[Weibye]

I really like this small but useful ux improvement, thanks!

[Weibye]

Changes look really good but we should add a note in the changelog explaining the change and addition of the DefaultFont resource

[IceSentry]

I added a short description to the migration guide. I'm not sure what would be needed in the changelog section.

[Weibye]

This looks good to me now, for some reason I had the recollection that we usually add things to the CHANGELOG.md but it seems we only do that when we do releases. In that case what is currently in the PR description should be enough.

[Weibye]

Are there any system-ordering issues we should be careful about here?

[IceSentry]

Not really, I guess it could make sense to run it in PostUpdate so it can run in the same frame as when the Text was added but it will work either way

[cart]

Not a huge fan of this dataflow. A style type should be "declarative". The user sets a value and the underlying system makes it happen under the hood, without changing the users' declared style.

Setting style.font = FontRef::Default should hold that default indefinitely, not serve as a placeholder/queued action that gets overwritten in place. Same goes for FontRef::Path.

I understand why you're doing this (we need to hold a strong handle somewhere to keep the font alive). But this weird dataflow isn't worth it from my perspective.

[IceSentry]

I agree, I'm just honestly not sure how else I could do that. I'll try to think of something better.

[cart]

This will only run for added text. FontRef should would consistently, even if changed at runtime.

[IceSentry]

Ah, right, I need to handle situations where fonts are updated, I didn't think about that one.

[IceSentry]

I closed this PR because the solution in #8445 solves this in a much nicer way.