gnome-shell has this hack where it sets the environment variable
"NO_AT_BRIDGE" to "1" before calling meta_init() and then unsets it
after meta_init() returns.
This variable being set to "1" will then cause the ATK bridge in
at-spi2-gtk to fail to load, which GTK then ignores. This is on purpose,
since accessibility is supposed to be done done by GNOME Shell via
Clutter, not via GTK.
The problem is that, now, by default, setting "NO_AT_BRIDGE" to
"1" during meta_init() only has the desired effect on an X11 session,
where we always connect to the X11 server on startup (i.e. during
meta_init()). With Xwayland on-demand, we do not attempt to create the
GDK display during meta_init(), thus this hack falls apart.
Since there are no real altenatives to this hack, just move it to
mutter, which have a better idea when GDK displays are created or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1744>
X11 clients can use different models of input handling, of which some
may not result focus being set synchronously.
For such clients, meta_focus_window() will not change the focus itself
but rely on the client itself to set the input focus on the desired
window.
Add a new MetaWindow API to check when dealing with such a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
This seems to have been the default in the past, but was (accidentally?) modified
by 8adab0275.
For GNOME 40, we'll be returning to our root with horizontal workspaces, so instead
of overriding it in GNOME Shell side, change the default back to what it once was.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1684>
One for the public channel, and one for the private maintainance
channel. Use the public one for test clients, otherwise tests become
flaky, and the private one for MetaX11Display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1681>
To find XWayland output that should be the primary one, iterate through all
XWayland outputs, and compare their geometry to the geometry of the primary
logical monitor.
To avoid possible race conditions (Mutter's monitor configuration already
updated, but Xrandr not yet), set the output both after Randr notifications and
after 'monitors-changed' signal.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1407
Signed-off-by: Aleksandr Mezin <mezin.alexander@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1558>
Commit e28c1ab4 added a hints_have_changed() function to only
recalculate windows features when the WM_NORMAL_HINTS change.
That function hints_have_changed() however was merely checking whether
the various XSizeHints flags where flipped, which is not sufficient
because the hints may remain the same while the actual values are
changed.
Not checking for the actual value differences would prevent some windows
from being able to switch fullscreen.
Improve the helper function hints_have_changed() to check not only for
flags being flipped, but also for the values being changed for each
relevant XSizeHints flags being set currently.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1534
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1566>
The XSizeHints set by X11 clients give a hint to the window manager
about size increment, aspect ratio, base, minimum and maximum size, etc.
When an X11 client changes those values, there is a good chance that it
will affect the actual window size in some way, and mutter rightfully
queue a window resize in that case.
However, mutter does not check if any of the hints have actually changed
and unconditionally queue a window resize whenever a client changes its
WM_NORMAL_HINTS property.
That can be a problem when a zealous client such as xterm decides to
update its WM_NORMAL_HINTS property on resize, because in return mutter
will queue a non-user driven resize in the middle of user-driven events,
hence defeating the purpose of the META_MOVE_RESIZE_USER_ACTION flag.
To avoid that issue, make mutter a bit smarter and avoid queuing a
window resize if the XSizeHints haven't actually changed.
https://gitlab.gnome.org/GNOME/mutter/-/issues/543
A GAppInfo is not guaranteed to have a filename or an application (or
rather a desktop ID). Add a check for application_id to be non-NULL
before trying to call sn_launcher_set_application_id, which would crash
otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1392
The memory selection source was only providing the "text/plain" or the
"text/plain;charset=utf-8" mimetype, but not "STRING" or "UTF8_STRING",
which some X11 clients, like wine, are looking for. This was breaking
pasting from the clipboard in wine applications.
Fix this by adding those targets when they are missing and the selection
source provides the corresponding mimetypes.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1369
Wine destroys its old selection window immediately before creating a new
selection. This would trigger restoring the clipboard, which would
overwrite the new selection with the old one. The selection window
however can also be destroyed as part of the shutdown process of
applications, such as Chromium for example. In those cases we want the
clipboard to be restored after the selection window has been destroyed.
Solve this by not immediately restoring the clipboard but instead using
a timeout which can be canceled by any new selection owner, such as in
the Wine case.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1338https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1369
When trying to find a default focus window, the code iterates through a
queue of candidates with a timeout between each candidate. If the window
the current timeout is waiting for gets destroyed, this process just
stops instead of trying the next window in the queue.
This issue was made more likely to be triggered with the previous change
to the closed-transient-no-input-parents-queued-default-focus-destroyed
test due to the introduction of a wait, which can introduce a
delay between the two destroy commands.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1325
According to the XSetSelectionOwner libX11 documentation:
[...] If the owner window it has specified in the request is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
This is indeed visible through the selection_timestamp field in
XFixesSelectionNotify events.
Use this to check whether the selection time is recent-ish (thus
likely coming from an explicit XSetSelectionOwner request) and honor
the client intent by setting a "NULL" owner. If the selection time
is too old, it's definitely an indication of the owner client being
closed, the scenario where we do want the clipboard manager to take
over.
This fixes two usecases:
- X11 LibreOffice / WPS clear the selection each time before copying
its own content. Mutter's clipboard manager would see each of those
as a hint to take over, competing with the client over selection
ownership. This would simply no longer happen
- Password managers may want to clear the selection, which would be
frustrated by our clipboard manager.
There's a slight window of opportunity for the heuristics to fail
though, if a X11 client sets the selection and closes within 50ms, we
would miss the clipboard manager taking over.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
The X11 selection source was being preserved after unsetting its
ownership. This is no leak as it would be eventually replaced by
another source, or destroyed on finalize. But it's pointless to
keep it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
Flushing the X11 selection output stream may happen synchronously or
implicitly, in which case there is not a task to complete. Check there
is actually a task before returning errors. We additionally set the
pipe_error flag, so future operations will fail with an error, albeit
with a more generic message.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If a write_async() comes up while we are flushing on the background,
the task will be queued, but not deemed a reason on itself to keep
flushing (and finish the task) after a property delete event.
To fix this, do not ever queue up write_async tasks (this leaves
priv->pending_task only used for flush(), so the "flush to end"
behavior in the background is consistent). We only start a
background flush if there's reasons to do it, but the tasks are
immediately finished.
All data will still be ensured to be transfered on flush/close,
this makes the caller in this situation still able to reach to it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
It does not make sense to check for the stream not being closed,
this might happen multiple times during the lifetime of the stream
for a single transfer. We want to notify the INCR transfer just
once.
Check for the explicit conditions that we want, that the remaining
data is bigger than we can transfer at once, and that we are not
yet within the INCR transfer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
The stream automatically flushes after data size exceeds the
size we deem for INCR chunks, but we still try to copy it all.
Actually limit the data we copy, and leave the rest for future
INCR chunks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
INCR transfers are mandated to finish with a final 0-size XChangeProperty
roundtrip after the final data chunk. Actually honor this and ensure we
iterate just once more for this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
This seemed to work under the assumption that a flush() call can
only result in one INCR roundtrip. This is evidently not true, so
we should hold things off until all pending data is actually flushed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If say we want 32bit data, but have 2 bytes stored, we would simply
ignore flush requests. Allow (and don't clear) the needs_flush flag
if we have less than the element size accumulated.
Instead handle this in can_flush(), so it's triggered whenever we
have enough data to fill 1 element, or if the stream is closing
(seems a broken situation, but triggered by the caller).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
XMaxRequestSize/XMaxExtendedRequestSize are documented to return
the maximum size in 4-byte units, whereas we are comparing this
to byte lenghts. We can afford 4x the data here.
Since I don't know the payload size of the XChangeProperty request,
be generous and allot 400 bytes for it, we have some to spare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
Better to have the relevant object figure out whether it is a good
position to be unredirectable other than the actor, which should be
responsible for being composited.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This removes the MetaWindowX11::priv pointer. It is replaced with a
meta_window_x11_get_private() helper function, and another method to get
the client rect without going through MetaWindowX11Private.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Most visible with xwayland-on-demand, at the time of setting things up
for X11 selections, we don't forward the current state. This makes the
first started X11 app oblivious to eg. the current clipboard.
Syncing selections up at the time of initializing the X11 selection
stuff ensures that doesn't happen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1186
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
This error was just logged but not raised. Do as the code comment said
and raise a pipe error at that moment, and for subsequent operations
on the output stream (although none besides close() should be expected
after propagating the error properly).
Related: https://gitlab.gnome.org/GNOME/mutter/issues/1065
To keep consistent and avoid confusion, rename the function:
`meta_window_x11_buffer_rect_to_frame_rect()`
to:
`meta_window_x11_surface_rect_to_frame_rect()`
As this function doesn't deal with the `window->buffer_rect` at all.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1091
This commits adds support on the MetaWindow and constraints engine side
for asynchronously repositioning a window with a placement rule, either
due to environmental changes (e.g. parent moved) or explicitly done so
via `meta_window_update_placement_rule()`.
This is so far unused, as placement rules where this functionality is
triggered are not yet constructed by the xdg-shell implementation, and
no users of `meta_window_update_placement_rule()` exists yet.
To summarize, it works by making it possible to produce placement rules
with the parent rectangle a window should be placed against, while
creating a pending configuration that is not applied until acknowledged
by the client using the xdg-shell configure/ack_configure mechanisms.
An "temporary" constrain result is added to deal with situations
where the client window *must* move immediately even though it has not yet
acknowledged a new configuration that was sent. This happens for example
when the parent window is moved, causing the popup window to change its
relative position e.g. because it ended up partially off-screen. In this
situation, the temporary position corresponds to the result of the
movement of the parent, while the pending (asynchronously configured)
position is the relative one given the new constraining result.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
MetaGravity is an enum, where the values match the X11 macros used for
gravity, with the exception that `ForgetGravity` was renamed
`META_GRAVITY_NONE` to have less of a obscure name.
The motivation for this is to rely less on libX11 data types and macros
in generic code.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
A placement rule placed window positions itself relative to its parent,
thus converting between relative coordinates to absolute coordinates,
then back to relative coordinates implies unwanted restrictions for
example when the absolute coordinate should not be calculated againts
the current parent window position.
Deal with this by keeping track of the relative position all the way
from the constraining engine to the move-resize window implementation.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
MetaX11SelectionOutputStream was storing copies of strings only to use
them in init and then free them in finalize. This was also causing a
small leak, because one of these strings was not freed. Instead of doing
that just don't create these unnecessary copies in the first place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1001
To address the black shadows that sometimes show during resize with
Xwayland, we need to update the window shape regardless of the frozen
status of the window actor.
However, plain Xorg does not need this, as resized windows do not clear
to black, so add a new vfunc to window/x11 to indicate whether or not
the backing windowing system (either plain X11 or Xwayland) would
require the shape to be always updated.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Make sure we freeze commits before resizing the window as this will
clear the frame to black.
Set the "thaw on paint" flag so that the post paint for window actor X11
can then thaw the freeze initiated prior to the resize and keep the
freeze/thaw balanced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
To be able to thaw commits following a resize that might have frozen
commits, to keep freezes and thaws even, we need a way to tell whether
a repaint should also thaw commits.
Add a flag to `MetaWindowX11` and the appropriate functions to set and
query it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
Xwayland may post damages for an X11 window as soon as the frame
callback is triggered, while the X11 window manager/compositor has not
yet finished updating the windows.
If Xwayland becomes compliant enough to not permit updates after the
buffer has been committed (see [1]), then the partial redraw of the X11
window at the time it was posted will show on screen.
To avoid that issue, the X11 window manager can use the X11 property
`_XWAYLAND_ALLOW_COMMITS` to control when Xwayland should be allowed to
post the pending damages.
Add `freeze_commits()` and `thaw_commits()` methods to `MetaWindowX11`
which are a no-op on plain X11, but sets `_XWAYLAND_ALLOW_COMMITS` on
the toplevel X11 windows running on Xwayland.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
See-also: https://gitlab.gnome.org/GNOME/mutter/merge_requests/855https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
At the moment we only disarm the watchdog timer set up for SYNC counter
requests if we're in the middle of a resize operation.
It's possible that the resize operation finished prematurely by the user
letting go of the mouse before the client responded. If that happens, when the
client finally updates mutter will erroneously still have the watchdog timer
engaged from before until it times out, leading to resizes for the next second
or so to not get processed, and the client to get blacklisted from future sync
requests.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
While most of the code to compute a window's layer isn't explicitly
windowing backend specific, it is in practice: On wayland there are
no DESKTOP windows(*), docks(*) or groups.
Reflect that by introducing a calculate_layer() vfunc that computes
(and sets) a window's layer.
(*) they shall burn in hell, amen!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
Java applications might use override-redirect windows as parent windows for
top-level windows, although this is not following the standard [1].
In such case, the first non-override-redirect child window that is created
was marked as being on_all_workspaces since the call to
should_be_on_all_workspaces() returns TRUE for its parent, and this even
though the on_all_workspaces_requested bit is unset.
When a further child of this window was added, it was set as not having a
workspace and not being on_all_workspaces, since the call to
should_be_on_all_workspaces() for its parent would return FALSE (unless if
it is in a different monitor, and the multiple-monitors workspaces are
disabled).
Since per commit 09bab98b we don't recompute the workspace if the
on_all_workspaces bit is unset, we could end up in a case where a window can
be nor in all the workspaces or in a specific workspace.
So let's just ignore the transient_for bit for a window if that points to an
override-redirect, using the x11 root window instead.
Add a stacking test to verify this scenario (was failing before of this
commit).
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/885https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
[1] https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472512128
Once we set the transient_for, we look for parent MetaWindow, so instead
of overwriting this value for loops check, just use another function
and avoid to look for the xwindow again when setting the MetaWindow parent.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
We ask XLib the next request serial number before performing other actions
triggered by meta_x11_display_set_input_focus_internal() that doesn't use
the request serial anyways. So, just request it before updating the focus
window as that's the operation that needs it.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
When using DesktopIcons extension and clicking in an icon, gnome-shell
starts an infinite loop caused by the first focus change that may trigger
on X11 a focus in/out event that leads to stage activation/deactivation
which never ends.
This happens because as part of meta_x11_display_set_input_focus_xwindow()
to focus the X11 stage window, we unset the display focus, but this also
causes to request the X11 display to unset the focus since we convolute by
calling meta_x11_display_set_input_focus() with no window, that leads to
focusing the no_focus_window and then a focus-in / focus-out dance that the
shell amplifies in order to give back the focus to the stage.
In order to fix this, mimic what meta_display_set_input_focus() does, but
without updating the X11 display, and so without implicitly calling
meta_x11_display_set_input_focus(), stopping the said convolution and
properly focusing the requested xwindow.
Also ensure that we're not doing this when using an older timestamp, since
this check isn't performed anymore.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/896
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/899https://gitlab.gnome.org/GNOME/mutter/merge_requests/909
This is a workaround for X11 games which use randr to change the resolution
in combination with NET_WM_STATE_FULLSCREEN when going fullscreen.
Newer versions of Xwayland support the randr part of this by supporting randr
resolution change emulation in combination with using WPviewport to scale the
app's window (at the emulated resolution) to fill the entire monitor.
Apps using randr in combination with NET_WM_STATE_FULLSCREEN expect the
fullscreen window to have the size of the emulated randr resolution since
when running on regular Xorg the resolution will actually be changed and
after that going fullscreen through NET_WM_STATE_FULLSCREEN will size
the window to be equal to the new resolution.
We need to emulate this behavior for these games to work correctly.
Xwayland's emulated resolution is a per X11 client setting and Xwayland
will set a special _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on the
toplevel windows of a client (and only those of that client), which has
changed the (emulated) resolution through a randr call.
This commit checks for that property and if it is set adjusts the fullscreen
monitor rect for this window to match the emulated resolution.
Here is a step-by-step of such an app going fullscreen:
1. App changes monitor resolution with randr.
2. Xwayland sets the _XWAYLAND_RANDR_EMU_MONITOR_RECTS property on all the
apps current and future windows. This property contains the origin of the
monitor for which the emulated resolution is set and the emulated
resolution.
3. App sets _NET_WM_FULLSCREEN.
4. We check the property and adjust the app's fullscreen size to match
the emulated resolution.
5. Xwayland sees a Window at monitor origin fully covering the emulated
monitor resolution. Xwayland sets a viewport making the emulated
resolution sized window cover the full actual monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
In a similar vein to commit 8fd55fef85. This notably failed when setting
the focus on the stage (eg. to redirect key events to Clutter actors).
Deeper in MetaDisplay focus updating machinery, it would check
meta_stage_is_focused() which would still return FALSE at the time it's
called.
This would not typically have side effects, but our "App does not respond"
dialogs see the focus change under their feet, so they try to bring
themselves to focus again. This results in a feedback loop.
Changing the order results in later checks on the X11 POV of the focus
being correct, so focus is not mistakenly stolen from the close dialog,
and it actually succeeds in keeping the key focus.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1607https://gitlab.gnome.org/GNOME/mutter/merge_requests/876
It might be the case that handling an event induces the stream to
trigger completion, hence removing itself from the list. In that
case we would operate on the no longer valid list element to fetch
the next one.
Keep a pointer to the next element beforehand, so we can tiptoe
over streams that did remove themselves.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
The streams were only detached from MetaX11Display (and its event handling)
on completion. This is too much to expect, and those might be in some
circumstances replaced while operating.
Make those streams detach themselves on dispose(), so we don't trip into
freed memory later on when trying to dispatch unrelated X11 selection events.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/869
Instead of passing around an X11 Display pointer that is retrieved from
the default Gdk backend, then finding the MetaX11Display from said X11
Display, pass the MetaX11Display directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
The functionality core/core.c and core/core.h provides are helpers for
the window decorations. This was not possible to derive from the name
itself, thus rename it and put it in the right place.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
Instead of storing the result of meta_prop_get_latin1_string() into
a temporary string value, g_strdup-ing that temp value storing the
g_strdup result into window->sm_client_id and then g_free-ing the
temporary string, we can pass window->sm_client_id as the place where
meta_prop_get_latin1_string() stores its result, since the result
from meta_prop_get_latin1_string() is itself a g_strdup-ed string,
so there is no need to g_strdup it again.
Note this drops the check to only issue the
"Window %s sets SM_CLIENT_ID on itself ..." warning once. This check is
not necessary as update_sm_hints() is only called once at window
creation time and is never called again.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_strdup instead of malloc + strcpy, this also gets rid of a bunch
of error checking which is no longer necessary, also adjust the free
path accordingly.
Note that there was a malloc + XFree mismatch in the removed error-handling.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
latin1_string_from_results and utf8_string_from_results use g_strndup,
so the returned string should be freed with g_free, rather then with
free or XFree. This fixes all free-s of buffers returned by these 2
functions to properly use g_free.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
Use g_new0 instead of calloc for motif_hints_from_results and adjust
its callers to use g_free.
Note that in the process_request_frame_extents function this replaces
the wrong original mismatch of calloc + XFree with a matching g_malloc +
g_free pair.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
The meta_display_update_focus_window() call has indirect dependencies
on the X11 focus window, in order to determine the correct focus window
on the Wayland side (i.e. may turn out NULL with certain X windows).
In order to have the right x11_display->focus_xwindow there, we should
perform first the focus update on the X11 display.
Fixes focusing of Java applications, as those don't seem to go through
_NET_ACTIVE_WINDOW.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/819
Instead of open coding the X11 focus management in display.c, expose
it as a single function with similar arguments to its MetaDisplay
counterpart. This just means less X11 specifics in display.c.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
MetaDisplay and MetaX11Display focus windows are slightly decoupled,
we cannot rely here on the MetaDisplay focus to be updated yet. We
however know the X Window that got focused, so lookup the corresponding
MetaWindow (and client X window) from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/751
If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.
This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
If an application provides its window icon via wmhints, then mutter
loads the pixmap specified by the application into a cairo xlib surface. When
creating the surface it specifies the visual, indirectly, via an XRender
picture format.
This is suboptimal, since XRender picture formats don't have a way to specify
16bpp depth, which an application may be using.
In particular, applications are likely to use 16bpp depth pixmaps for their
icons, if the video card offers a 16bpp framebuffer/root window.
This commit drops the XRender middleman, and just tells cairo a visual to use
directly.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/715
