Move bevy_window, bevy_input_focus, custom_cursor features to alternate feature collections

[Seliksi]

Related: Cargo Feature Collections #21472

Context:

If default_app is meant to be

The core pieces that most apps need. This serves as a baseline feature set for other higher level feature collections (such as "2d" and "3d"). It is also useful as a baseline feature set for scenarios like headless apps that require no rendering (ex: command line tools, servers, etc).

why should bevy_window / custom_cursor be there? I would expect these to be in common_api.

- Me, https://discord.com/channels/691052431525675048/692572690833473578/1460424003486224517

Imo this is a mistake. Can you open a PR with a migration guide please?

- Alice, https://discord.com/channels/691052431525675048/692572690833473578/1460429142376845404

Solution

• Move bevy_window, bevy_input_focus, custom_cursor features from default_app collection to common_api.

Testing

• Did you test these changes? If so, how?

Confirmed that default_app collection no longer introduces the crates to the dependency tree:

$ git checkout bevy/main -q

$ cargo tree --no-default-features -Fdefault_app -e normal | grep -e bevy_window -e bevy_input_focus -e custom_cursor
    ├── bevy_input_focus v0.18.0-dev
    │   ├── bevy_window v0.18.0-dev
    ├── bevy_window v0.18.0-dev (*)
        ├── bevy_input_focus v0.18.0-dev (*)
        ├── bevy_window v0.18.0-dev (*)

$ git checkout reduced-feature-group
Previous HEAD position was f8ea30965 Add support for reflected math operations ➕➖✖️➗ (#22478)
Switched to branch 'reduced-feature-group'

$ cargo tree --no-default-features -Fdefault_app -e normal | grep -e bevy_window -e bevy_input_focus -e custom_cursor

$

• How can other people (reviewers) test your changes? Is there anything specific they need to know?

I'm not sure how cross-cutting changes to features have to be since I haven't worked with such a complicated feature set before, so it's possible I've omitted a change to some place that needs to be updated. Please point it out to me, thank you.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[alice-i-cecile]

Excellent, thanks for opening this up for review. Looking at it more closely, some thoughts:

1. bevy_input_focus and custom_cursor definitely do not belong in default_app: these are far from the "core pieces most apps need" (e.g. servers do not want this).
2. common_api does not feel like the right home for these, based on the description of it as being centered around scenes.
3. bevy_input_focus belongs under ui_api instead: this is fundamentally a UI feature, even if you can use it for other things.
4. I'm not sure where to put the windowing features (bevy_window, custom_cursor): they feel like they belong in their own collection, which is relied on by the various *_bevy_render feature collections.

I'm not immediately sure what the right organization is, but hopefully these observations are a useful starting point for others.

[Seliksi]

For custom_cursor: Since custom_cursor is a winit-specific feature, it could be put under default_platform?

For bevy_window: I interpret this crate as doing something scene-related, to the extent that I might describe a bevy scene of windows using the types defined in here. Currently the Window component is not very friendly to this idea, but if it were less desktop-specific in its api (and maybe broken apart into more granular components) this could useful to some apps. So tentatively I think common_api is an okay place for it. (I'd de-prefer it if it's on the critical path for compile times, but I can't successfully build it to check)

[alice-i-cecile]

For custom_cursor: Since custom_cursor is a winit-specific feature, it could be put under default_platform?

This is a more sensible home. Annoying that it's winit-specific, but we do what we can.

For bevy_window: I interpret this crate as doing something scene-related, to the extent that I might describe a bevy scene of windows using the types defined in here.

Hmmm... This is probably a better home for now at least; this will cause it to be enabled where we need it without the addition of another feature collection. We'll see what the other reviewers have to say.

[Seliksi]

I'm getting compilation failures testing with cargo build --no-default-features -Fcommon_api but those are on main too. I'll try to open an issue for this

[tychedelia]

bevy_window is the interface and doesn't do anything without a specific windowing backend (currently just winit) being enabled. It's not harmful to include by default but may be better suited to live alongside the other crates that define similar interfaces.