bevy_vello icon indicating copy to clipboard operation
bevy_vello copied to clipboard

Make text `render` function public

Open ramelen opened this issue 3 months ago • 7 comments

A VelloTextSection must currently be added to an entity and spawned in the world to be rendered, unlike impl Shape which can be encoded to a scene at any time. This has made it difficult to use text in my immediate mode application.

This PR changes the visibility of the render function on a VelloFont from pub(crate) to pub. As far as I am aware this change doesn't cause any problems, and should work as part of the API without any modifications.

PS: This is my first ever pull request, so if anything here is a faux pas I would appreciate the feedback.

ramelen avatar Aug 31 '25 20:08 ramelen

I don't see any problem making it pub.

Now if you could figure out the pipeline errors that would be superb! :thinking:

Edit: ~~An alternative would just be to copy-paste the function, the only reference to self is the font family name :)~~ Actually the font context is not public :(

PS: Need to update the CHANGELOG.md as well. DS: Do not change any versions, we do that in a separate PR.

RobertBrewitz avatar Sep 01 '25 06:09 RobertBrewitz

I notice that the lint still fails even when I revert my changes... I can get the tests to pass on my own fork, but since the errors don't seem to be caused by my change I'm wondering if that's an issue for a separate PR. Let me know what I should do.

ramelen avatar Sep 02 '25 01:09 ramelen

Unfortunately, the lints pass now, but when I use my fork as a dependency in my project, it fails to compile with the error "let expressions in this position are unstable". I don't know why this doesn't come up in the GitHub checks but a build error is definitely worse than an unfixed clippy lint.

ramelen avatar Sep 11 '25 20:09 ramelen

Unfortunately, the lints pass now, but when I use my fork as a dependency in my project, it fails to compile with the error "let expressions in this position are unstable". I don't know why this doesn't come up in the GitHub checks but a build error is definitely worse than an unfixed clippy lint.

I don't have any issues when using Rust 1.89 stable nor 1.91 nightly here running cargo check using this as a dependency. Shouldn't be any problem bumping the MSRV.

RobertBrewitz avatar Sep 12 '25 07:09 RobertBrewitz

It turns out my rustc version was 1.86 stable and updating to 1.89 fixed the issue for me. Should be all good now.

ramelen avatar Sep 13 '25 05:09 ramelen

@simbleau should the MSRV be bumped in this PR?

RobertBrewitz avatar Sep 13 '25 10:09 RobertBrewitz

Yeah I'd be fine with that

nuzzles avatar Sep 13 '25 18:09 nuzzles