Fixes a regression introduced by 8892b79118,
because set_window_pos is called before UpdateLayeredWindow, which calls
the driver's WindowPosChanged earlier.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51984
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Partially fix Excel 2007 and 2010 showing an extra taskbar icon when
opening multiple documents in one instance.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some window managers require MWM_FUNC_CLOSE to be present for a window to be allowed to close. For
example, on KWin, a window of style WS_POPUP | WS_VISIBLE has a close button drawn on top of its
taskbar preview. But when you press it, the window manager refuses to close it. On Mutter, windows
without MWN_FUNC_CLOSE doesn't have a close button on the window preview. On Windows 10, enabled
windows without WS_SYSMENU always has a close button on their taskbar window preview and can always
be closed with the close button. On Windows 7, enabled windows without WS_SYSMENU has no close
button on the window preview but still can be closed with the right-click menu on the taskbar.
This patch changes the behavior to match that of Windows 10.
Fix WeChat image preview window cannot be closed from KDE panels.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Which creates an off-screen window surface for top-level non-layered or
SLWA-layered windows.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A window without a minimize or maximize box can still be programmatically
minimized by the Windows API. However, some WMs will refuse to change the
state and not allow it to be maximized again, despite it being minimized,
due to lacking those functions, thus not sending WM_STATE change notifications
when clicking the minimized window on the taskbar.
Heroes of Might and Magic V does this, for example, when losing focus. It
minimizes itself. When maximizing it by clicking on the taskbar it won't
send a WM_STATE change notification (since it was never changed) and fail
to maximize properly, showing a black screen (the game will still think it
is minimized).
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If the current thread isn't the foreground thread. Otherwise we may
clip the cursor in the wrong thread, that isn't expecting mouse messages
or may not be checking its messages.
Red Faction has some race condition where this can happen for instance,
with clip_fullscreen_window called from X11DRV_DisplayDevices_Update
callback in a background thread. This thread starts clipping the cursor,
and the foreground thread isn't receiving MotionNotify events anymore.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The message was sent to two different types of windows, with a different
semantic. We can now add parameters to the request without changing the
notify parameters semantics.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A window can be maximized or full screen on non-primary monitors. In this
case we need to add _NET_WM_STATE_MAXIMIZED or _NET_WM_STATE_FULLSCREEN
hint to the window so that they can be handled correctly by window managers.
For example, a full screen window on the secondary monitor needs
_NET_WM_STATE_FULLSCREEN so that window managers prevent panels from obscuring it.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
KWin treats a window covering exactly the whole monitor as maximized
when handling its first map request and expects applications to update
maximized state later. Wine doesn't know about this added maximized
state and expect it unchanged, making the window always maximized
as far as KWin is concerned. So always send _NET_WM_STATE updates
even if Wine doesn't expect changes to hint KWin that a window should
not be maximized.
Fix test failures when running the tests introduced by
36b720357b with KWin.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
A window can be resized to a smaller size than the decoration (title +
borders), such as when it is minimized. In such cases it is necessary
to recompute the minimum bounds, as it is done in the opposite function
X11DRV_window_to_X_rect, since the real information was lost.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48490
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Move update_windows_on_desktop_resize() to be in X11DRV_DisplayDevices_Update()
and rename it to update_windows_on_display_change(), which is a more appropriate
name because the desktop is unnecessarily resized when display devices change.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise, Wine still has the old desktop size after a user changed
display resolution using host system utilities.
X11DRV_DisplayDevices_Update() is introduced so that display devices
reinitialization is separated from desktop resizing. Otherwise,
X11DRV_DisplayDevices_Init() would have to be called twice to resize
the desktop with up-to-date primary monitor dimensions, wasting resources.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=48441
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
According to the Extended Window Manager Hints (EWMH) spec 1.3 regarding
_NET_WM_STATE_FULLSCREEN, "the Window Manager is responsible for
restoring the original geometry after a switch from fullscreen back to
normal window.", which means that removing _NET_WM_STATE_FULLSCREEN from
a window may cause the window to receive a ConfigureNotify event to
restore the window size, thus causing a application resize action to be
overwritten by the window managers.
Fix a game called Mugsters becomes maximized after exiting full screen.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
GNOME implements the startup notification protocol correctly which
means it checks StartupWMClass against both WM name (res_name) and
WM class (res_class). Thus it does not need this patch.
The situation is different for desktop environments that thunk to
Wayland such as Crostini. Wayland does not have separate concepts
that WM name and WM class can be mapped to. So Crostini decided to
only use res_class resulting in it trying to match 'Wine' to the
program name stored in StartupWMClass.
While Crostini's choice is unfortunate for Wine, most other
applications (e.g. all GTK applications) already store the same value
in both WM name and class. So in the interest of compatiblity it makes
sense for Wine to do the same.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a regression from 22795243b2,
which calls thread_init_display() and eventually XOpenIM() before
X11DRV_InitXIM() is called.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47821
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If a window with an OpenGL surface attached is reparented as a child window,
and then reparented as a top-level window, so that its whole window is
destroyed and then recreated, it will be recreated with the colormap of its
child window, which more than likely has a different visual. This violates
the X11 specification, which states that a window's colormap must have the
same visual as the window itself, and causes the X server to return BadMatch
to the CreateWindow request.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the same thread repeatedly calls ClipCursor, a message window is
created for every call, then stored in x11drv_thread_data->clip_hwnd.
The WM_X11DRV_CLIP_CURSOR notification is then sent to the desktop
window, then to the previous clipping thread in order for it to destroy
its clip_hwnd. But as the clipping thread is the same, and because
x11drv_thread_data->clip_hwnd has been overwritten, it does not satisfy
the "hwnd == data->clip_hwnd" condition and the window leaked.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Frequent calls to XResetScreenSaver cause performance problems on some
GPU drivers, see https://bugs.freedesktop.org/show_bug.cgi?id=110659
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Prevent creating a gl_drawable for a window as type DC_GL_WINDOW if
there are known children of the window, since DC_GL_WINDOW does not
support clipping.
Recreate a gl_drawable that was previously create as type DC_GL_WINDOW
when a child is encountered.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=15232
Signed-off-by: Micah N Gorrell <mgorrell@codeweavers.com>
Signed-off-by: Ken Thomases <ken@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Gabriel Ivăncescu