Expose the current monitor a window is on

[benfrankel]

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

I want to add a VideoMode selector to my settings menu. However, there is no way to get a list of supported video modes, because that information lives in Monitor::video_modes, but there's no link from a window to the monitor it's currently on.

What solution would you like?

Expose a window's current monitor index or entity via a Window::monitor or current_monitor field or getter method, or a separate component / relationship. I believe winit has this information.

What alternative(s) have you considered?

1. Include a Monitor selector in the settings menu as well, and populate video modes based on the selected monitor. This works, but is not the UX we want. Also the selected monitor shown in the settings menu may confusingly become out of sync with the actual monitor if the user moves the window, because there's no way to check if it's still correct.
2. Iterate over monitors to find one that contains the window's position within its extents. This probably works, but is hacky so it may not work on every platform, and it's not a suitable solution for bevy_new_2d.

Additional context

This came up while working on bevy_new_2d.

[alice-i-cecile]

IIRC there was a "monitors as entities" idea floating around that this would dovetail nicely with.

[jf908]

IIRC there was a "monitors as entities" idea floating around that this would dovetail nicely with.

Monitors already are entities now :)

Include a Monitor selector in the settings menu as well, and populate video modes based on the selected monitor.

In my opinion, a monitor selector is necessary for good UX because you can't move the window in fullscreen and I also think you can't really get away with not updating the UI according to state because there's nothing stopping the user plugging in/out monitors or adding additional resolutions (eg. Nvidia DSR). Maybe its worth me writing something up about this because I recently implemented a video options menu so I have a lot of strong opinions about it and I don't think Bevy's current API lends itself to it very easily. Regardless, I also agree that knowing the window's current monitor is also necessary for good UX and I ended up having to workaround it with NonSend<WinitWindows> which allows you to access the underlying winit window of a window entity.

there's no link from a window to the monitor it's currently on

I was going to implement this after my VideoModeSelection contribution but I stun locked myself because I couldn't figure out what the best ergonomic API would be. Currently leaning towards Relationship, if someone else agrees or has a stronger opinion I can make the PR.

[janhohenheim]

@Sapein implemented the relationship variant in bevy_link_window_to_monitor, which could be upstreamed

[benfrankel]

I assume you mean the API specifically, since the upstream implementation should probably get the info from winit.

[Sapein]

If it were to be upstreamed you would only want to upstream the API.

The detection code is a bit of a hack that only exists because I can't really access the underlying winit window to ask it about which monitor it's on, and has a few edge cases, due as I have to use whatever information Bevy exposes to try and determine the window.

[jf908]

I can't really access the underlying winit window to ask it

You can actually access all of winit's functionality using the NonSend<WinitWindows> system parameter the same way bevy internally accesses it. Obviously not the recommended way for a game to do it but it's there!

[Sapein]

You can actually access all of winit's functionality using the NonSend<WinitWindows> system parameter the same way bevy internally accesses it. Obviously not the recommended way for a game to do it but it's there!

Interesting, I wasn't sure there was a way to get access to WinitWindows, and didn't see one when I was trying to find a way to do that, however that would basically make it always possible to have the appropriate monitor -- as opposed to the current detection approach in my crate which is just heuristics which can fail.