Expose is_minimized and is_visible from Winit

[Selene-Amanita]

What problem does this solve or what need does it fill?

I think right now the only way to access those Winit APIs from Bevy is to get NonSendMut<WinitWindows>.
This is the only way to know if a window is minimized/maximized, since there is not even an event for them so it's not possible to just keep track of that, as far as I know.

What solution would you like?

One or several of those:

• Have a is_minimized, is_maximized, and is_visible methods on Window, to reflect Winit's method. (note: those are not available for all platforms)
• Have a public minimized and visible field on Window, similar to focused, for minimized it could also be mutated to request minimizing/maximizing, replacing the set_maximized/set_minimized methods. (note on this: mutating this field if the request fails might lead to confusing behavior, same for visible that is not supposed to be mutated at all, right now we have similar problems with focused actually since a Window can't be put out of focus, but the field can be set to true with no consequence)
• Have events to indicate when a Window is maximized/minimized/visible, if Winit have those (not sure), similar to WindowFocused

What alternative(s) have you considered?

Use NonSendMut<WinitWindows>, and potentially document it for set_maximized/set_minimized methods.

[IceSentry]

I exposed the visible property in this PR #9355

[ewrogers]

Window State & Visiblity

New to Bevy so I am not sure if these struct/enums already exist but I would imagine the window state and visibility status could be represented with something like:

enum WindowState {
    Normal,
    Maximized,
    Minimized,
    Fullscreen,   // macOS
}

enum WindowVisibility {
   Visible,
   Hidden,
}

I am a fan of using enums over booleans, even in the case of WindowVisiblity which allows future expansion of other states without needing to refactor.

For the case of WindowState, there are some platform specific things that should be taken into account. On Windows, you have the Maximized behavior, whereas on macOS its Fullscreen instead. Would this be captured as "maximized" or "fullscreen"?

Or would the "fullscreen" behavior be more a separate enum for the traditional video game behavior like so:

enum RenderMode {
  Windowed,
  BorderlessFullscreen,
  Fullscreen,
}

Which in this case would just assume "fullscreen" button on macOS windows to be "maximized" in the above WindowState and keep the Fullscreen variant solely for a more "gpu rendering mode" enum.

Window Events

I second the idea of exposing various window events for when these things change. Assuming the above, something like WindowStateChanged and WindowVisiblityChanged which exposes the new enum value.

You could have convenience events which are also emitted for WindowMinimized, WindowMaximized and WindowRestored (from min/max -> normal), for when you don't care about checking the enum value itself.

Request User Attention

Would also be good to expose the request_user_attention functionality.

In Windows this flashes the icon in the taskbar, in macOS the dock icon bounces until the user clicks it. I assume Linux desktop environments have a similar flash or attention getting mechanism.

This could be done with an event writer perhaps EventWriter<AppUserAttention>, or exposed directly on the Window component as a method.

[mnmaita]

I'll try to open a PR that exposes the minimized and maximized statuses of the windows as boolean (just to mimic what the winit API returns). I'll keep it simple and just forward the values exposed by winit. I'll take a look at the events and the user attention feature later.

[mnmaita]

You can take a look at #9815. I made it as concise as possible. I still have to test it properly, but I'd like some early feedback on the code as I'm not very convinced on the implementation.

[mnmaita]

I'm considering blocking or closing my PR until winit adds events for minimize and maximize actions (check the following issue). I was able to programatically expose and change these statuses in my machine (e.g. set a maximized flag in the primary Window and update the underlying winit window), but the problem is that I don't have (or know) a way to react to actual user input due to the lack of these events in the windowing backend.

A potential solution that I can think of would be to have an independent system check the winit status periodically and update fields in the Window component, but it feels suboptimal and might trigger other systems that check for Changed<Window> unnecessarily.

I've also checked the WinitWindows resource but I'm not sure if it's possible to check it for changes (and if window status changes will actually trigger them) since it's a NonSend resource. Also feels overcomplicated even if possible.

Any input on this will be welcome, but I think the implementation will be incomplete under these circumstances.