Closed alice-i-cecile closed 1 month ago
I'm personally okay with any of these solutions, but a bevy_cursors
crate is my favorite, followed by the feature flagging approach.
I like the bevy_cursors
idea. It's a crate that solves a specific problem and it helps keep the other crates focused on solving their specific problems.
Creating a crate just for cursors feels a bit pointless and like bloat.
I would prefer to move the ANDROID_APP
declaration out of bevy_winit
. It would make sense to have it in bevy_window
for example. that would let us break the dependency between bevy_winit
and bevy_asset
, and open the possibility to change the direction of dependencies with bevy_render
I'm on board with that plan.
Seems like reversing the dependency is not really desirable either. I can see at least one more use for a bevy_window_extensions crate (something like that, instead of bevy_cursors), which is window icons. Not sure if there is more.
Problem
14284 added a direct, non-optional dependency on
bevy_winit
frombevy_render
.This is messy for our crate structure, and makes it much harder to use
bevy_render
on exotic platforms.It's also causing issues for contributors:
From @StrikeForceZero on Discord.
Proposed solution: revert the cursor icon PR.
Revert #14284 and reopen #14351.
Solves this problem very directly, at the expense of a valuable feature. Back to the drawing board, where none of the options seemed very good.
Proposed solution: make the dependency optional by feature-flagging cursor icons
Still messy, but something that can be worked around. Doesn't lose us the nice feature.
Proposed solution: bevy_cursors crate
Lift this code out into its own crate, which depends on
bevy_winit
andbevy_render
. Probably the cleanest conceptually, but now we have yet another tiny crate to maintain.