Several applications -Steam, Battle.net for instance- handle the WM_NCCALCSIZE message to override the non-client areas size and make the client area cover the whole window, instead of changing the styles.
In winex11.drv, in decorated mode, we adjust the window rect according to the window style to hide the unwanted decorations behind the frame, but when client and window rects are equals, there's nothing to hide and the actual window styles are irrelevant and can safely be ignored.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=40930 Signed-off-by: Rémi Bernon rbernon@codeweavers.com ---
There's still going to be some issues for applications that customize the non-client area sizes differently from their styles, but hopefully there's aren't many applications that do that.
dlls/winex11.drv/window.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c index 99e4094ebd9..903b036442b 100644 --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -286,6 +286,7 @@ static unsigned long get_mwm_decorations( struct x11drv_win_data *data,
if (!decorated_mode) return 0;
+ if (EqualRect( &data->window_rect, &data->client_rect )) return 0; if (IsRectEmpty( &data->window_rect )) return 0; if (data->shaped) return 0;
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46857 Signed-off-by: Rémi Bernon rbernon@codeweavers.com ---
This is completely untested as I don't have a Mac, but I believe it's the same change as winex11.drv.
dlls/winemac.drv/window.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/winemac.drv/window.c b/dlls/winemac.drv/window.c index 605c0c87f16..258412e0930 100644 --- a/dlls/winemac.drv/window.c +++ b/dlls/winemac.drv/window.c @@ -63,6 +63,7 @@ static void get_cocoa_window_features(struct macdrv_win_data *data,
if (disable_window_decorations) return; if (IsRectEmpty(&data->window_rect)) return; + if (EqualRect(&data->window_rect, &data->client_rect)) return;
if ((style & WS_CAPTION) == WS_CAPTION && !(ex_style & WS_EX_LAYERED)) {
Actually this is not completely correct, we need to consider the "new" window and client rects in the WindowPosChanging callbacks.
I'll resend an updated version.
-
Rémi Bernon