[Git][wine/wine][master] 7 commits: winex11: Introduce a new get_window_state_updates helper.

[Alexandre Julliard (＠julliard)]

Alexandre Julliard pushed to branch master at wine / wine


Commits:
a5d68b60 by Rémi Bernon at 2024-11-22T16:55:04+01:00
winex11: Introduce a new get_window_state_updates helper.

- - - - -
7abbcd16 by Rémi Bernon at 2024-11-22T16:55:04+01:00
winex11: Generate GravityNotify events instead of ConfigureNotify.

In order to better distinguish them from the ConfigureNotify events
sent by the WM.

Some window managers (openbox) send a sequence of ConfigureNotify to
top-level window frames when restoring them from minimized state, for
animation purposes, and they shouldn't be reflected on the Win32 side.

We do not need to update the Win32 state when top-level windows frame is
being moved, as the WM will send us a ConfigureNotify later and we only
need to keep track of its position for mouse event coordinates.

Handle the generated GravityNotify events for embedded windows only, to
match their Win32 state/config with their X state/config.

- - - - -
4b27077f by Rémi Bernon at 2024-11-22T16:55:06+01:00
winex11: Avoid sending WM_WINDOWPOSCHANGING when applying window manager config.

It sometimes create a feedback loop, trying to override the window
manager config changes.

- - - - -
b84f533a by Rémi Bernon at 2024-11-22T16:55:08+01:00
winex11: Delay window config request when restoring from fullscreen/maximized.

- - - - -
e6a1d6bf by Rémi Bernon at 2024-11-22T16:55:08+01:00
user32/tests: Workaround a FVWM maximized window state bug.

This adds a todo_wine because it exhibits a FVWM bug: the window manager
doesn't keep the _NET_WM_STATE maximized bits, and instead simply resize
the windows.

The missing events don't matter too much, although they would prevent us
from serializing the updates with other changes, but it also makes it
impossible to figure whether the windows are actually maximized or not.

For visible windows, the message we send to the window manager simply
doesn't trigger any PropertyNotify event. The update is considered as
pending until the maximized style is cleared, and we never try to remove
the maximized state from the Win32 state.

For hidden windows, the _NET_WM_STATE property is changed directly, this
sticks and we receive a corresponding PropertyNotify event. However, as
soon as the window is mapped, FVWM removes the bits and we receive
another PropertyNotify event accordingly. This can only be considered as
a genuine state update, and we clear the maximized state from the Win32
side accordingly.

Previously, as the state updates were not re-entrant, the update didn't
trigger another window manager state/config update and the window stayed
in an inconsistent state, which somehow passed the tests.

As the updates are now re-entrant, the window manager is notified of the
maximized state removal, and resizes the window to its normal size, then
fails the tests.

- - - - -
0f1d999b by Rémi Bernon at 2024-11-22T16:55:11+01:00
winex11: Update the Win32 window state outside of event handlers.

- - - - -
26f3edd4 by Rémi Bernon at 2024-11-22T16:55:11+01:00
winex11: Remove now unnecessary WindowPosChanged re-entry guards.

- - - - -


10 changed files:

- dlls/user32/tests/win.c
- dlls/win32u/driver.c
- dlls/win32u/message.c
- dlls/win32u/spy.c
- dlls/winex11.drv/event.c
- dlls/winex11.drv/init.c
- dlls/winex11.drv/window.c
- dlls/winex11.drv/x11drv.h
- include/ntuser.h
- include/wine/gdi_driver.h


View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/ca7a246e209c690c3061ad4e4a5f1b...

-- 
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/ca7a246e209c690c3061ad4e4a5f1b...
You're receiving this email because of your account on gitlab.winehq.org.