After the introduction of locate-pointer (commit 851b7d063 -
“keybindings: Trigger locate-pointer on key modifier”), inhibiting
shortcuts would no longer forward the overlay key to the client.
Restore the code that was inadvertently removed so that inhibiting
shortcuts works on the overlay key again.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/734
A base type shouldn't know about sub types, so let MetaDisplay make
the correct choice of what type of MetaCompositor it should create. No
other semantical changes introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/727
When double clicking to un-maximize an X11 window under Wayland, there
is a race between X11 and Wayland protocols and the X11 XConfigureWindow
may be processed by Xwayland before the button press event is forwarded
via the Wayland protocol.
As a result, the second click may reach another X11 window placed right
underneath in the X11 stack.
Make sure we do not forward the button press event to Wayland if it was
handled by the frame UI.
https://gitlab.gnome.org/GNOME/mutter/issues/88
Some meta_later operations may happen across XWayland being shutdown,
that trigger MetaStackTracker queries for X11 XIDs. This crashes as
the MetaX11Display is already NULL.
Return a NULL window in that case, as in "unknown stack ID".
https://gitlab.gnome.org/GNOME/mutter/merge_requests/728
The Xwayland manager now has 4 distinct phases:
- Init and shutdown (Happening together with the compositor itself)
- Start and stop
In these last 2 phases, handle orderly initialization and shutdown
of Xwayland. On initialization We will simply find out what is a
proper display name, and set up the envvar and socket so that clients
think there is a X server.
Whenever we detect data on this socket, we enter the start phase
that will launch Xwayland, and plunge the socket directly to it.
In this phase we now also set up the MetaX11Display.
The stop phase is pretty much the opposite, we will shutdown the
MetaX11Display and all related data, terminate the Xwayland
process, and restore the listening sockets. This phase happens
on a timeout whenever the last known X11 MetaWindow is gone. If no
new X clients come back in this timeout, the X server will be
eventually terminated.
The shutdown phase happens on compositor shutdown and is completely
uninteresting. Some bits there moved into the stop phase as might
happen over and over.
This is all controlled by META_DISPLAY_POLICY_ON_DEMAND and
the "autostart-xwayland" experimental setting.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
When rushing to unmanage X11 windows after the X11 connection is closed/ing,
this would succeed at creating a stack operation for no longer known windows.
Simply avoid to queue a stack operation if we know it's meaningless.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
What "restart" means is somewhat different between x11 and wayland
sessions. A X11 compositor may restart itself, thus having to manage
again all the client windows that were running. A wayland compositor
cannot restart itself, but might restart X11, in which case there's
possibly a number of wayland clients, plus some x11 app that is
being started.
For the latter case, the assert will break, so just make it
conditional. Also rename the function so it's more clear that it
only affects X11 windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
If the display is closed prematurely, go through all windows that
look X11-y and remove them for future calculations. This is not
strictly needed as Xwayland should shut down orderly (thus no client
windows be there), but doesn't hurt to prepare in advance for the
cases where it might not be the case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
We don't strictly need it for wayland compositors, yet there are
paths where we try to trigger those passive grabs there. Just
skip those on the high level code (where "is it x11" decisions
are taken) like we do with passive button grabs.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
Commit 09bab98b1e tried to avoid several workspace changes while in
window construction, but it missed a case:
If we have a window on a secondary monitor with no workspaces enabled
(so it implicitly gets on_all_workspaces = TRUE without requesting it)
and trigger the creation of a second window that has the first as
transient-for, it would first try to set the first workspace than the
transient-for window and then fallback to all/current workspace.
After that commit we only try to set the same workspace than the
transient-for window, but it gets none as neither is on a single workspace,
nor did really request to be on all workspaces.
Fixes crashes when opening transient X11 dialogs in the secondary monitor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/714
We first set the workspace to the transient-for parent's, and then
try to set on the current workspace. If both happen, we double the
work on adding/removing it from the workspace, and everything that
happens in result.
Should reduce some activity while typing on the Epiphany address
bar, as the animation results in a number of xdg_popup being created
and destroyed to handle the animation.
https://gitlab.gnome.org/GNOME/mutter/issues/556
On X11, mutter needs to keep a grab on the locate-pointer key to be able
to trigger the functionality time the corresponding key combo is
pressed.
However, doing so may have side effects on other X11 clients that would
want to have a grab on the same key.
Make sure we only actually grab the key combo for "locate-pointer" only
when the feature is actually enabled, so that having the locate pointer
feature turned off (the default) would not cause side effects on other
X11 clients that might want to use the same key for their own use.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/647
Some special modifiers (typically "Control_L" used for locate-pointer in
mutter/gnome-shell or "Super_L" for overlay) must be handled separately
from the rest of the key bindings.
Add a new flag `META_KEY_BINDING_NO_AUTO_GRAB` so we can tell when
dealing with that special keybinding which should not be grabbed
automatically like the rest of the keybindings, and skip those when
changing the grabs of all keybindings.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/685
Using the master device, as we did, won't yield the expected result when
looking up the device node (it comes NULL as this is a virtual device).
Use the slave device, as the g-s-d machinery essentially expects.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/678
The device ID is kind of pointless on Wayland, so it might be better to
stick to something that works for both backends. Passing the device here
allows the higher layers to pick.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/676
As per commit 040de396b, we don't try to grab when shortcuts are inhibited,
However, this uses the focus window assuming that it is always set, while this
might not be the case in some scenarios (like when unsetting the focus before
requesting take-focus-window to acquire the input).
So allow the button grab even if the focus window is not set for the display
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/663https://gitlab.gnome.org/GNOME/mutter/merge_requests/668
On Wayland, if a client issues a inhibit-shortcut request, the Wayland
compositor will disable its own shortcuts.
We should also disable the default handler for the button grab modifier
so that button events with the window grab modifiers pressed are not
caught by the compositor but are forwarded to the client surface.
That also fixes the same issue with Xwayland applications issuing grabs,
as those end up being emulated like shortcut inhibition.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/642
gnome-shell hardcodes a vertical one-column workspace layout, and
while not supporting arbitrary grids is very much by design, it
currently doesn't have a choice: We simply don't expose the workspace
layout we use.
Change that to allow gnome-shell to be a bit more flexible with the
workspace layouts it supports.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/618
When destroying a window that has a parent, we initially try to focus one of
its ancestors. However if no ancestor can be focused, then we should instead
focus the default focus window instead of trying to request focus for a window
that can't get focus anyways.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/308
When we're unfullscreening, we might be returning to a window state that
has its size either managed by constraints (tiled, maximized), or not
(floating). Lets just pass the configure size 0x0 when we're not using
constrained sizes (i.e. the window going from being fullscreen to not
maximized) and let the application decide how to size itself.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/638https://gitlab.gnome.org/GNOME/mutter/merge_requests/621
As per commit 7718e67f, destroying the compositor causes destroying window
actors and this leads to stack changes, but at this point the stack was already
disposed and cleared.
So, clear the stack when any component that could use it (compositor, and X11)
has already been destroyed.
As consequence, also the stamps should be destroyed at later point.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/623https://gitlab.gnome.org/GNOME/mutter/merge_requests/605
We're currently emitting the 'grab-op-end' signal when the grab prerequisites
are met, but when display->grab_op is still set to a not-NONE value and thus
meta_display_get_grab_op() would return that in the signal callback.
And more importantly when this is emitted, devices are still grabbed.
Instead, emit this signal as soon as we've unset all the grab properties and
released the devices.
Helps with https://gitlab.gnome.org/GNOME/gnome-shell/issues/1326https://gitlab.gnome.org/GNOME/mutter/merge_requests/596
In all places (including src/wayland) we tap into meta_x11_display* focus
API, which then calls meta_display* API. This relation is backwards, so
rework input focus management so it's the other way around.
We now have high-level meta_display_(un)set_input_focus functions, which
perform the backend-independent maintenance, and calls into the X11
functions where relevant. These functions are what callers should use.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
We use a GtkIconTheme (thus icon-theme, thus xsettings, thus x11) just to
grab a "missing icon" icon to show in place. Relax this requirement that
surfaces for icon/mini-icon will be set, and just let it have NULL here.
It seems better to have the callers (presumably UI layers) aware of this
and set a proper icon by themselves, but AFAICS there is none in sight,
not even plain mutter seems to use MetaWindow::[mini-]icon. Probably
worth a future cleanup.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
If the check happens on --nested (X11 backend) while there is no X11
display we would get a crash. Since the barriers are non-effective on
nested, just take it out into a separate condition.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
This explicit ungrab is made to ensure the other X11 display connection
is able to start an active grab immediately on the device without receiving
AlreadyGrabbed.
This is just relevant if there's two X11 display connections to transfer
grabs across, which may just happen on X11 windowing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
This object takes care of the X11 representation of the window stack,
namely the _NET_CLIENT_LIST and _NET_CLIENT_LIST_STACKING root window
properties.
This code has been lifted from src/core/stack.c into src/x11 as it's
dependent on the X11 display availability. This also leaves MetaStack
squeaky clean of x11 specifics.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
We'd break the loop for moving attached windows at the first window,
meaning we'd only ever move a single attached dialogs or popup if it was
the first window in the list. This doesn't work out well when there are
multiple popups open, so don't break out of the loop at all until all
windows are potentially moved.
This fixes an issue in gtk4 where one or more non-grabbing popups would
end up unattached if there were more than one and the parent window was
moved.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/592
In order to scale a rectangle by a double value, we can reuse a ClutterRect
to do the scale computations in floating point math and then to convert it back
using the proper strategy that will take in account the subpixel compensation.
In this way we can be sure that the resulting rectangle can fully contain the
original scaled one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/469
This function was added for historic reasons, before that we had GSlist's
free_full function.
Since this can be now easily implemented with a function call and an explicit
GDestroyFunc, while no known dependency uses it let's move to use
g_slist_free_func instead.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/57
GList's used in legacy code were free'd using a g_slist_foreach + g_slist_free,
while we can just use g_slist_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
GList's used in legacy code were free'd using a g_list_foreach + g_list_free,
while we can just use g_list_free_full as per GLib 2.28.
So replace code where we were using this legacy codepath.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/576
Depending on the type of session, one or the other might be NULL, which
is not meant to be handled by these functions. Check for both DISPLAY
envvars before setting them on the GAppLaunchContext.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/586
The check for the focus xwindow is called, but not used. Fix that by
renaming the variable to reflect better what it does and actually using
the return value of the check.
This was the original intention of the author in commit
05899596d1 and got broken in commit
8e7e1eeef5.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/535
meta_workspace_activate_with_focus is supposed to focus the passed window after
switching the workspace.
However if the passed workspace is already the active one, we just return
without activating the window.
So fix this calling meta_window_activate on the foucs_this window if that is
valid.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/562
This is a simple clipboard manager implementation on top of MetaSelection.
It will inspect the clipboard content for UTF-8 text and image data whenever
any other selection source claims ownership, and claim it for itself
whenever the clipboard goes unowned.
The stored text has a maximum size of 4MB and images 200MB, to prevent the
compositor from allocating indefinite amounts of memory.
This is not quite a X11 clipboard manager, but also works there.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
MetaSelectionSource represents a primary/clipboard/dnd selection owner,
it is an abstract type so wayland/x11/etc implementations can be provided.
These 3 selections are managed by the MetaSelection object, the current
selection owners will be set there, and signals will be emitted so the
previous selection owner can clean itself up.
The actual data transfer is done through the meta_selection_transfer_async()
call, which will take a GOutputStream and create a corresponding
GInputStream from the MetaSelectionSource in order to splice them.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/320
When an application stops responding, the shell darkens its windows.
If a window from a not-responding application gets unmanaged
then the shell will currently throw an exception trying to retrieve
the now-dissociated window actor.
That leads to a "stuck window" ghost on screen and a traceback
in the log.
This commit addresses the problem by making sure the effect is cleaned
up before the actor is disocciated from its window.
https://gitlab.gnome.org/GNOME/mutter/issues/575
When focus stealing prevention kicks in, mutter would set the demand
attention flag on the window.
Focus stealing prevention would also prevent the window from being
raised and focused, which is expected as its precisely its purpose.
Yet, when that occurs, the user expects the window which has just been
prevented from being focused to be the next one in the MRU list, so
that pressing [Alt]-[Tab] would raise and give focus to that window.
This works fine when the window is placed on the primary monitor, but
not when placed on another monitor, in which case the window which has
been denied focus is placed ahead of the MRU list and pressing
[Alt]-[Tab] would leave the focus on the current window.
This is because of a mechanism in `meta_display_get_tab_list()` which
forces the windows with the demand attention flag set to be placed first
in the MRU list when they're placed on a workspace different from the
current one.
But because workspaces apply only to the primary monitor (by default),
the windows placed on other outputs have their workspace set to `NULL`
which forces them ahead of the MRU list by mistake.
Fix this by using the appropriate `meta_window_located_on_workspace()
function to check if the window is on another workspace.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/523
The sequences may stay completed in the list (eg. pending a focus request),
it's then confusing to show the "wait" cursor icon until they are really
gone.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
Calculations were being done at places accounting on usec precision,
however those are still treated as having msec precision at places. Let's
consolidate for the latter since it requires less changes across the board
and usec precision doesn't buy us anything here.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/541
We use the combination of pressing Super and clicking+moving the mouse
to drag windows around and we also support pressing Super and using the
touchscreen to drag windows.
Since we don't want to show the overview when the Super key was used to
initiate a window drag, prevent showing the overview in case a
TOUCH_BEGIN or TOUCH_END event happened during the key was pressed.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/228https://gitlab.gnome.org/GNOME/mutter/merge_requests/495
If an intersection is empty, the (x, y) coordinates are undefined, so
just use the work area and in-progress constrained window rect when
sliding according to the SLIDE_X or SLIDE_Y custom placement rule.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
When check_only is TRUE, the constraint should not be applied, just
checked. We failed to comply here when a placed transient window was
to be moved together with its parent, updating the window position
directly even if check_only was TRUE.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
If a client maps a persistent popup with a placement rule, then resizes
the parent window so that the popup ends up outside of the parent,
unmanage the popup and log a warning about the client being buggy.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
When a parent window is moved, attached windows (attached modal dialogs
or popups) is moved with it. This is problematic when such a window
hasn't been shown yet (e.g. a popup that has been configured but not
shown), as it'll mean we try to constrain an empty window. Avoid this
issue by not trying to auto-move empty windows.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/496
Fixes condition duplicated:
/* If a contains b, just remove b */
if (meta_rectangle_contains_rect (a, b))
{
delete_me = other;
}
/* If b contains a, just remove a */
else if (meta_rectangle_contains_rect (a, b))
{
delete_me = compare;
}
Closes https://gitlab.gnome.org/GNOME/mutter/issues/480
Traditionally visual alerts were implemented by flashing the focus
window's frame. As that only works for windows that we decorate,
flashing the whole window was added as a fallback for client-decorated
windows.
However that introduces some confusing inconsistency, better to just
always flash the entire window.
https://gitlab.gnome.org/GNOME/mutter/issues/491
The app menu always was a GNOME-only thing, so after it was removed this
cycle, assuming that it is not displayed by the environment is a better
default.
https://gitlab.gnome.org/GNOME/mutter/issues/493
The function finish_cb can be called as a result of a call to ca_context_cancel
in cancelled_cb. This will result in a deadlock because, as per documentation,
g_cancellable_disconnect cannot be called inside the cancellable handler.
It is possible to detect if the call to finish_cb is caused by ca_context_cancel
checking if error_code == CA_ERROR_CANCELED. To avoid the deadlock we should
call g_signal_handler_disconnect instead g_cancellable_disconnect if this is the
case.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/474
Splitting out the X11 display initialization from display_open() broke
restoring the previously active workspace in two ways:
- when dynamic workspaces are used, the old workspaces haven't
been restored yet, so we stay on the first workspace
- when static workspaces are used, the code tries to access
the compositor that hasn't been initialized yet, resulting
in a segfault
Fix both those issues by splitting out restoring of the active workspace.
https://gitlab.gnome.org/GNOME/mutter/issues/479
Meta rectangles are integer based while clutter works in floating coordinates,
so when converting to integers we need a strategy.
Implement the shrink strategy by ceiling the coordinates and flooring the width,
and the grow strategy reusing clutter facility for this.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/3
The external grab handler is shared across all external bindings and external
bindings have now different binding flags. For this reason, when rebuilding the
binding table there could be loss of information if we assign the bindings flags
of the external handler to all external bindings. Let's store the bindings flags
in MetaKeyGrab too and use this when rebuilding the binding table to avoid the
above issue.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/169
The "force restore shortcuts" being triggered by a key-combo, there is
no guarantee that the currently focused window is actually non-NULL in
which case we would crash.
Make sure there is a window currently focused before trying to restore
the shortcuts on that window.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/464
As per commit 43633d6b, we mark an unmanaging window as not focusable, while
this is true, it might cause not resetting the current focused window when
unmanaging it causing a crash.
Also this wouldn't allow to check if a window can be focused when unmanaging it,
so let's revert the previous behavior.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/462
For various error and warning messages, mutter includes a description of
the window, and that description includes a snippet of the title of the
window. Those snippets find their way into system logs, which then means
they can potentially find their way into bug reports and similar. Remove
the window title information to eliminate this potential privacy issue.
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.
https://gitlab.gnome.org/GNOME/mutter/issues/447
Shell is using these, which was revealed by
1bbb5c8107 breaking its build when
generating its introspection due to meta_startup_notification_get_type()
not being found.
We keep the class structs private, so in practice MetaStartupSequence
and MetaBackend can't be derived from (the are semi-private).
Make meson link libmutter using -fvisibility=hidden, and introduce META_EXPORT
and META_EXPORT_TEST defines to mark a symbols as visible.
The TEST version is meant to be used to flag symbols that are only used
internally by mutter tests, but that should not be considered public API.
This allows us to be more precise in selecting what is exported and what is
not, without the need of a version-script file that would be more complicated
to maintain.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/395
This is a GAppLaunchContext subclass meant to replace usage of
GdkAppLaunchContext in gnome-shell.
Launch contexts get created from the MetaStartupNotification as
they are closely related. The messaging underneath depends on
the availability of a X11 display, if there is one we go through
it (and libsn). If there is none, we still create startup sequences
manually for wayland clients.
The "current" rect includes the frame, so in order to keep the
titlebar on screen, window movement must be restricted to at
most (height - titlebar_height) past the work area bottom.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/391
This is a simple libcanberra abstraction object, so we are able
to play file/theme sounds without poking into GTK+/X11. Play
requests are delegated to a separate thread, so we don't block
UI on cards that are slow to wake up from power saving.
Placing persistant Wayland popups (e.g. not menus etc) in the o-r layer
breaks stacking order with other window trees (e.g. other client
windows), as the menu would get stuck in the o-r layer, i.e. on top,
even if the parent of the popup got lowered.
Fix this by placing the popups in the normal layer, relying on
transient-ness to keep stacking correct.
It's a UI pattern that has been superseded by client-side decorations,
apps that used to set the hint have generally moved on to headerbars.
Given that and the limitation to server-side decorated X11 windows,
GTK4 removed the client-side API for setting the hint, it's time to
follow suite and retire the feature.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/221
Moving windows using `move-to-side-X` and `move-corner-XX` keybindings
should keep windows within the confines of current screen.
`move-to-monitor-XXX` keybindings can be used to move windows to other
monitors.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/320
Commit 8d3e05305 ("window: Force update monitor on hot plugs") added the
flag `META_WINDOW_UPDATE_MONITOR_FLAGS_FORCE` passed to
`update_monitor()` from `update_for_monitors_changed()`.
However, `update_for_monitors_changed()` may choose to call another code
path to `move_between_rects()` and `meta_window_move_resize_internal()`
eventually.
As `meta_window_move_resize_internal()` does not use the "force" flag,
we may still end up in case where the window->monitor is left unchanged.
To avoid that problem, add a new `MetaMoveResizeFlags` that
`update_for_monitors_changed()` can use to force the monitor update from
`meta_window_move_resize_internal()`.
Fixes: 8d3e05305 ("window: Force update monitor on hot plugs")
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/189
