This should be functionally no-op as the new state tracker has no side effect other than printing traces. It introduces a new pending/current states on the win data to track the requested changes, as well as the associated request serial for each of the property being changed.
Later, this tracker will help making the requests more asynchronous (removing the need for wait_for_withdrawn_state), avoid duplicate requests, and better decide whether the received updates are expected or should be applied back to the win32 window state:
- any update that is older than our last request, expected and matching our request, or unexpected but no-op can be ignored,
- any update that wasn't requested or doesn't match the request (because the WM decided so) will need to be applied on the win32 state.
Tracking the current X11 window state separately will also allow us to later delay these updates on the win32 state, possibly by posting an internal message for win32u to call us back to get the necessary changes, when every other message has been processed and avoid calling SetWindowPos / syscommand directly from within the driver event handlers.
--
v2: winex11: Track window config requests and updates.
winex11: Introduce a new window_set_config helper.
winex11: Track _NET_WM_STATE window property requests and updates.
winex11: Introduce a new window_set_net_wm_state helper.
winex11: Introduce a new window_set_wm_state helper.
winex11: Track _XEMBED_INFO window property changes.
winex11: Track WM_STATE window property requests and updates.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6729
This should be functionally no-op as the new state tracker has no side effect other than printing traces. It introduces a new pending/current states on the win data to track the requested changes, as well as the associated request serial for each of the property being changed.
Later, this tracker will help making the requests more asynchronous (removing the need for wait_for_withdrawn_state), avoid duplicate requests, and better decide whether the received updates are expected or should be applied back to the win32 window state:
- any update that is older than our last request, expected and matching our request, or unexpected but no-op can be ignored,
- any update that wasn't requested or doesn't match the request (because the WM decided so) will need to be applied on the win32 state.
Tracking the current X11 window state separately will also allow us to later delay these updates on the win32 state, possibly by posting an internal message for win32u to call us back to get the necessary changes, when every other message has been processed and avoid calling SetWindowPos / syscommand directly from within the driver event handlers.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6729