Rename Resized to Configured and expose state

[kchibisov]

Notify clients about the window state changes, most underlying systems do change the window states.

Fixes #2334.

• Tested on all platforms changed
• Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
• Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
• Created or updated an example program if it would help users understand this functionality
• Updated feature matrix, if new features were added or implemented

[kchibisov]

@daxpedda for web, I'm not sure how much of that works.

@notgull should we maybe listen to property changes (the _NEW_WM_STATE) instead?

[kchibisov]

I'm not quite sure how to approach other states, like wayland has for example Resizing state indicating live resizes.

Should we really abuse the Resized here and change it to carry the state, maybe we should expose state as a separate event, though, the issue is that such state is usually tied with resize events, for example, fullscreen/maximized do change the window state.

[notgull]

@notgull should we maybe listen to property changes (the _NEW_WM_STATE) instead?

For the atom changes we need to listen to PropertyNotify, IIRC.

[kchibisov]

For the atom changes we need to listen to PropertyNotify, IIRC.

Yeah, I've read it, but I'm not sure whether we really need to, due to a fact that ConfigureNotify is talking about some state/scene changes and both fullscreen/maximize should involve that.

The question is whether the Minimized is also signaled there or not.

[madsmtm]

I don't think a bit flag is appropriate here, since the states are mutually exclusive, are they not?

Perhaps an enum like this is better (names up for bikeshedding):

enum WindowFrameState {
    Fullscreen, // Possibly containing `Fullscreen`?
    Maximized,
    Minimized,
    Normal,
}

And given that we now have this enum, perhaps we can unify it with setting the window (frame) state? So e.g. window set_frame_state(WindowFrameState::Maximized) instead of window.set_maximized(true)?

[kchibisov]

The state might not be mutually exclusive in the future, at least If I expose more stuff from Wayland it won't be.

I don't think we should change the functions, because fullscreen is attached to the particular monitor. At least for now I'd keep it the way it is.

[daxpedda]

The state might not be mutually exclusive in the future, at least If I expose more stuff from Wayland it won't be.

Maybe we should figure this out when we get there, even on Wayland the current states are mutually exclusive, so maybe additional states for Wayland should be dealt with in a different way while allowing states that are mutually exclusive to stay that way.

[kchibisov]

They are tiled states, saying that some edge of the window is being tiled, it's basically the same as maximized.

[daxpedda]

I don't know what tiled is, but what does "basically the same" mean? Is it mutually exclusive or not?
At least on other backends it is mutually exclusive, right?

[kchibisov]

They are not, you can have them attached to any state, you can have 4 of them at the same time, etc.

Tiled means that your window is, well, tiled to some screen edge or just generally tiled.

[daxpedda]

Wow, that's really strange.
Wouldn't this completely change the meaning of what's exposed here? Like it doesn't make the API really cross-platform because the meaning is so different.

In any case, if it's not mutually exclusive, we can leave it as is.

[daxpedda]

Web is implemented.

I noticed that the fullscreen API we use has some compatibility issues with Safari, even before this PR. I will open an issue and address this afterwards.

EDIT: #2935.

[daxpedda]

Rebased (and added some fixes to Web).

[casperstorm]

Rebased #2926 on top of this.

[daxpedda]

Rebased on a bunch of churn in Web.