On Thu Jan 9 19:52:35 2025 +0000, Rémi Bernon wrote:
`desired_state` is the X window state that would match the current Win32 state, `pending_state` which is the state that was last requested to the X server, `current_state` is the state that corresponds to the last window config/state notify event we've received. Obviously `current_state` differs from `pending_state` as soon as we're requesting a change, until we've received the corresponding notify. `pending_state` and `desired_state` may differ when we decide to delay some requests, if there's some requested changes already pending, as requesting changes while other are still pending is often confusing window managers, or is simply invalid (for window map/unmap requests). When the notify event is received, we'll either continue by requesting any delayed `desired_state` change, if the notify matches our expectations, or, if it does not, we will temporarily ignore the `desired_state` and notify the Win32 side of an unexpected window config/state change.
Thank you, that clears it up. One last question: why do we have to request the `desired_state` again after receiving a notify and it matches? Isn't it a no-op?