Add option to toggle window control buttons

[aleksa2808]

Objective

Implements #9082 but with an option to toggle minimize and close buttons too.

Solution

• Added an enabled_buttons member to the Window struct through which users can enable or disable specific window control buttons.

---

Changelog

• Added an enabled_buttons member to the Window struct through which users can enable or disable specific window control buttons.
• Added a new system to the window_settings example which demonstrates the toggling functionality.

---

Migration guide

• Added an enabled_buttons member to the Window struct through which users can enable or disable specific window control buttons.

[github-actions]

Welcome, new contributor!

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

[aleksa2808]

I tested the change on Windows 11 and macOS Ventura, both OSes disable the buttons correctly.

However, on macOS there is still an issue where you can double click the top bar of the window to maximize it even though the button is disabled. I'm looking into whether this can be disabled.

On Windows, if the maximize button is disabled and the window is not maximized double clicking the window top bar won't do anything. However, if the window is already maximized, double clicking the top bar will un-maximize it. I will accept this behavior. 😃

Edit: The double-click-bar-to-maximize behavior on macOS is controlled by the resizable member, so it can be disabled by setting that value to false (on Windows this is not the case, the double-click functionality there is controlled by the maximize button behing enabled or not (which to me makes more sense)). Additionaly, on macOS, if resizable is set to false, the maximize button will be permanently disabled even though it is enabled in the EnabledButtons struct. This might be a bit confusing so I will add it as a note to the enabled_buttons member docstring.

[Selene-Amanita]

I just tested on Linux Mint Mate (derived from Gnome, X11), and the EnableButtons booleans do nothing. :(

But setting resizable to false does make the maximize button disappear (and greys out the option in the window menu), no matter what is in EnableButtons.

My "double click on the bar" is configured to do a kind of weird semi-minimize where only the title bar of the window remains, that is also still possible, I could try to change this behaviour to maximize but my guess is it would do the same (not maximize if resizable is false, do it if true, ignore EnableButtons.)

[aleksa2808]

I just tested on Linux Mint Mate (derived from Gnome, X11), and the EnableButtons booleans do nothing. :(

Yes, in essence this PR just exposes the winit functionality, which for some platforms is just an empty function. Here's the line for X11:
https://github.com/rust-windowing/winit/blob/master/src/platform_impl/linux/x11/window.rs#L1300

Maybe I can add a note about this discrepancy in the docstrings as well?
I'll also try to figure out why this is the case when obviously the disable button functionality is still there, at least for maximize.

Edit:

This might be the reason why on X11 the maximize button deactivates when resizable is set to false:
https://github.com/rust-windowing/winit/blob/master/src/platform_impl/linux/x11/window.rs#L1278

In general, this feature (among others) is straight up not implemented for X11 and Wayland which winit says in the docs. I haven't delved into the question whether it's actually possible or not.

[Selene-Amanita]

I think it's fine if it's not supported on every platform, we just need to be transparent about it.

Edit: beside the remarks on documentation, looks good to me!

[aleksa2808]

For posterity, I was confused as to why, in older bevy/winit versions, when setting resizable to false the maximize button would also be disabled even on Windows. I found out that this was done explicitly and was then removed when the enabled_buttons feature was added:
https://github.com/rust-windowing/winit/pull/2537/files#diff-6bbe536d32ae2b66fde18a908848021a8c511a1cc38a4c83d31b0dd6cd3eca33L249

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Could you add some context on what users should update when this change get released in a new version of Bevy?
It will be used to help writing the migration guide for the version. Putting it after a ## Migration Guide will help it get automatically picked up by our tooling.

[Selene-Amanita]

Can you put a simple migration guide to say that a new field is added to Window? ^^'

[aleksa2808]

Can you put a simple migration guide to say that a new field is added to Window? ^^'

Damn, I'm so used to using ..default() that I overlooked that this can actually be a breaking change! Will add it now!

Edit: added it now, @Selene-Amanita does it conform with other PRs?

[Selene-Amanita]

Perfect thanks!