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
It relied on indices in arrays determining tile direction and
non-obvious bitmask logic to translate to _GTK_EDGE_CONSTRAINTS. Change
this to explicitly named edge constraints, and clear translation methods
that converts between mutters and GTK+s edge constraint formats.
An unnecessary memory optimization, storing the tile mode as a 2 bit
unsigned integer, was used. While saving a few bytes, it made debugging
harder. Remove the useless byte packing.
This is the filename convention you get when you define a shared module
in meson, and since there is no particular reason to not include the
"lib" prefix, lets make it easier to port it over. While at it,
de-duplicate the retrieval of the plugin name.
While leaving the runtime checks in place, requiring xrandr 1.5 at build
time allows us to remove some seemingly unnecessary conditional
inclusion of functionality.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
testboxes was a binary that did unit testing, but it wasn't integrated
to the test system, so in effect, it was never run. Instead integrate it
into the other mutter unit tests. This includes changing a few of
meta_warning()s into g_warning()s so that the GTest framework can handle
them.
meta_workspace_manager_override_workspace_layout is implemented by
calling meta_workspace_manager_update_workspace_layout which
respects the workspace_layout_overridden flag. After the first call
to meta_workspace_manager_override_workspace_layout all subsequent
calls fail silently.
Reset workspace_layout_overridden to FALSE before calling
meta_workspace_manager_update_workspace_layout.
https://gitlab.gnome.org/GNOME/mutter/issues/270
In order to allow a window with a custom rule placement to be moved
together with its parent, the final rule used derived from the
constraining were used for subsequent constraints. This was not enough
as some constraining cannot be translated into a rule, such as sliding
across some axis.
Instead, make it a bit simpler and just remember the position relative
to the parent window, and use that the next time.
This is a rework of 5376c31a33 which
caused the unwanted side effects.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/332
With Wayland, a window is not showing until it's shown. Until this
patch, the initial state of MetaWindow, on the other hand, was that a
window is initialized as showing. This means that for a window to
actually be classified as shown (MetaWindow::hidden set to FALSE),
something would first have to hide it.
Normally, this wasn't an issue, as normally we'd first create a window,
determine it shouldn't be visible (due to missing buffer), hide it
before the next paint, then eventually show it. This doesn't work if
mutter isn't drawing any frames at the moment (e.g. the user switched
VT), as we'd miss the hiding before showing as e result of a buffer
being attached. The most visible side effect is that a window can't be
moved as the window actor remains frozen.
This commit fixes this issue by correctly classifying a newly created
Wayland window as "hidden".
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/331
Changes in window decoration result in the window being reparented
in and out its frame. This in turn causes unmap/map events, and
XI_FocusOut if the window happened to be focused.
In order to preserve the focused window across the decoration change,
add a flag so that the focus may be restored on MapNotify.
Closes: #273
On Wayland, xdg-foreign would leave a modal dialog managed even after
the imported surface is destroyed.
This is sub-optimal and this breaks the atomic relationship one would
expect between the parent and its modal dialog.
Make sure we unmanage the dialog if transient_for is unset even for
Wayland native windows.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/174
Related: https://gitlab.gnome.org/GNOME/mutter/issues/221
A window placed using a placement rule should keep that relative
position even if the parent window moves, as the position tied to the
parent window, not to the stage. Thus, if the parent window moves, the
child window should move with it.
In the implementation in this commit, the constraints engine is not
used when repositioning the children; the window is simply positioned
according to the effective placement rule that was derived from the
initial constraining, as the a xdg_popup at the moment cannot move
(relative its parent) after being mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/274
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.
The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.
Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
Since commit b3b9d9e16 we no longer have to pass the unmanaging window
to make sure we don't try to focus it again, however the parameter also
influences the focus policy by giving ancestors preference over the normal
stack order.
https://gitlab.gnome.org/GNOME/mutter/issues/15
We refuse to move focus while a grab operation is in place. While this
generally makes sense, there's no reason why the window that owns the
grab shouldn't be given the regular input focus as well - we pretty
much assume that the grab window is also the focus window anyway.
In fact there's a strong reason for allowing the focus change here:
If the grab window isn't the focus window, it probably has a modal
transient that is focused instead, and a likely reason for the focus
request is that the transient is being unmanaged and we must move
the focus elsewhere.
https://gitlab.gnome.org/GNOME/mutter/issues/15
Previously we relied on the test-client to make sure that a window was
shown. For X11, we did not need to do anything, but for Wayland we had
to make sure we had drawn the first frame, otherwise mutter wouldn't
have a buffer making the window not showable.
Doing it this way doesn't work anymore however, since the 'after-paint'
event will be emitted even if we didn't actually paint anything. This is
the case with current Gtk under Wayland, where we won't draw until the
compositor has configured the surface. In effect, this mean we'll get a
dummy after-paint emission before the first frame is actually painted.
Instead, move the verification that a "show" command has completed by
having the test-runner wait for a "shown" signal on the window, which is
emitted in the end of meta_window_show(). This requires an additional
call to gdk_display_sync() in the test-client after creating the window,
to make sure that the window creation vents has been received in the
compositor.
As of "stack-tracker: Keep override redirect windows on top"
(e3d5bc077d), we always sorted all
override redirect on top of regular windows, as so is expected by
regular override redirect windows. This had an unwanted consequence,
however, which is that we should still not sort such override redirect
windows on top if they are behind the guard window, as that'd result in
windows hidden behind it now getting restacked anyway.
Fix this by only sorting the override redirect windows that are found
above the guard window on top. This fixes the override-redirect stacking
test.
xdg-foreign clears the `transient_for` of a modal dialog when its
imported parent is destroyed, which would later cause a crash in
`constrain_modal_dialog()` because the transient `NULL`.
So in case a modal dialog has no parent, do not try to constrain it
against its parent.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/174
MetaDisplay still had workspace signals, but nothing emitted them,
meaning we wouldn't get warnings if handlers were added there instead
of to MetaWorkspaceManager.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
If we wait with opening the X11 window decoration GDK connection, we
might end up with a terminated X11 server before we finish
initializing, depending on the things happening after spawning Xwayland
and before opening the MetaX11Dispaly. In gnome-shell, this involves
e.g. creating a couple of temporary X11 connections, and on disconnect,
if they happen to be the last client, the X server will terminate
itself.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Under Xorg the cursor size preference was pre-scaled originating from
gtk, while with Wayland it came directly from GSettings remaining
unscaled. Under Xwayland this caused the X11 display code to set the
wrong size with HiDPI configurations, which was often later overridden
by the equivalent code in gtk, but not always.
Fix this by always having the cursor size preference unscaled, scaling
the size correctly where it's used, depending on how it's used.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
GTK+ won't be initialized if X11 is not available
Instead, when setting gtk-shell-shows-app-menu,
meta_prefs_set_show_fallback_app_menu should be
called as well.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Allow removing a prefs handler that was already removed. This allows us
to remove prefs from the dispose function without having to keep track
of it in every place.
- Stop using CurrentTime, introduce META_CURRENT_TIME
- Use g_get_monotonic_time () instead of relying on an
X server running and making roundtrip to it
https://bugzilla.gnome.org/show_bug.cgi?id=759538
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
Introduce a new type MetaCursorSpriteXcursor that is a MetaCursorSprite
implementation backed by Xcursor images. A plain MetaCursorSprite can
still be created "bare bone", but must be manually provided with a
texture. These usages will eventually be wrapped into new
MetaCursorSprite types while turning MetaCursorSprite into an abstract
type.
https://gitlab.gnome.org/GNOME/mutter/issues/77
It was prefixed with meta_cursor_, but it took a X11 Display, so update
the naming. Eventually it should be duplicated depending if it's a
frontend X11 connection call or a backend X11 connection call and moved
to the corresponding layers, but let's just do this minor cleanup for
now.
https://gitlab.gnome.org/GNOME/mutter/issues/77
The MetaCloseDialog implementation object may stay artifically alive
for a longer period. This was usually fine till gnome-shell commit
b03bcc85aad, as the check_alive() timeout will keep running even
though the window went unmanaged/destroyed, leading to crashes.
In order to fix this, forcibly hide the dialog if it is visible and
the window is being unmanaged, so the timeout is stopped in time.
While MetaStage, MetaWindowGroup and MetaDBusDisplayConfigSkeleton don't
appear explicitly in the public API, their gtypes are still exposed via
meta_get_stage_for_screen(), meta_get_*window_group_for_screen() and
MetaMonitorManager's parent type. Newer versions of gjs will warn about
undefined properties if it encounters a gtype without introspection
information, so expose those types to shut up the warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=781471
In the old, synchronous X.org world, we could assume that
a state change always meant a synchronizing the window
geometry right after. After firing an operation that
would change the window state, such as maximizing or
tiling the window,
With Wayland, however, this is not valid anymore, since
Wayland is asynchronous. In this scenario, we call
meta_window_move_resize_internal() twice: when the user
executes an state-changing operation, and when the server
ACKs this operation. This breaks the previous assumptions,
and as a consequence, it breaks the GNOME Shell animations
in Wayland.
The solution is giving the MetaWindow control over the time
when the window geometry is synchronized with the compositor.
That is done by introducing a new result flag. Wayland asks
for a compositor sync after receiving an ACK from the server,
while X11 asks for it right away.
Fixes#78
And use the old "native" backend for both X11 and Wayland. This will
allow us to share fixes between implementations without having to delve
into the XSync X11 extension code.
https://bugzilla.gnome.org/show_bug.cgi?id=705942
Raising and lowering windows in tandem without a proper grouping
mechanism ended up being more annoying than functional.
This reverts commit e76a0f564c.
When painting the titlebar, button icons that aren't available in the
desired size need to be scaled. However the current code inverses the
scale factor, with the result that the adjusted icons are much worse
than the original icons, whoops.
This went unnoticed for a long time given that most icons are availa-
ble in the desired 16x16 size, and the most likely exceptions - window
icons - are not shown by default.
https://gitlab.gnome.org/GNOME/mutter/issues/23
This is in order to force running as a X11 window manager/compositing
manager. Useful for debugging and other cases where the automatic
detection does not work as expected.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/15
When maximizing a window, the previous location is saved so that
un-maximize would restore the same original window location.
However, if a Wayland client starts with a window maximized, the
previous location will be 0x0, so if we have to force placement in
xdg_toplevel_set_maximized(), we should update the location as well so
that the window is placed on the right monitor when un-maximizing.
For that purpose, add a new flag to force the update of the window
location, and use that flag from xdg_toplevel_set_maximized().
https://bugzilla.gnome.org/show_bug.cgi?id=783901
Wayland clients know their size better, so for Wayland we'd rather not
try to resize the client on un-maximize, but for this to work we need a
new MetaMoveResizeFlags.
https://bugzilla.gnome.org/show_bug.cgi?id=783901
When closing a window and showing a new one, the new one may not be
granted input focus until it gets a buffer on Wayland.
If another window is chosen to receive focus and raised on top of stack,
the newly mapped window is focused but placed underneath that other
window.
Meaning that for Wayland surfaces, we need to defer adding the window to
the stack until we actually get to show it, once we have a buffer
attached.
Rather that checking the windowing backend prior to decide if a window
is stackable or not, introduce a new vfunc is_stackable() which tells
if a window should be added to the stack regardless of the underlying
windowing system.
Also add meta_window_is_in_stack() API rather than checking the stack
position directly (replacing the define WINDOW_IN_STACK only available
in stack.c) and remove a window from the stack only if it is present
in the stack, so that the test in meta_stack_remote() becomes
irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=780820
When a Wayland client issues a shortcut inhibit request which is granted
by the user, the Super key should be passed to the surface instead of
being handled by the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=790627
The reason why multiple keycodes could be mapped to a single keysym was
to support having both KEY_FAVORITES and KEY_BOOKMARK map to
XF86Favorites. However, iterating through all layout levels adding all
key codes has severe consequences on layouts with levels that map
things like numbers and arrow. The result is that keybindings that
should only have been added for keycodes from the first level, are
replaced by some unexpected keycode where the same keysym was found on
another level.
An example of this is the up-arrow key and l symbol. Normally you'd find
both the up-arrow symbol and the l symbol on the first level and be done
with it. However, on the German Neo-2 layout, layout level 4 maps the
KEY_E to the l symbol, while layout level 4 maps KEY_E to up-arrow.
Which ever gets to take priority is arbitrary, but for this particular
case KEY_E incorrectly mapped to up-arrow instead of the l symbol,
causing the keyboard shortcut Super+l, which would normally lock the
screen, to trigger the workspace-up (Super+up-arrow) key binding.
https://bugzilla.gnome.org/show_bug.cgi?id=789300
MetaWindowXwayland derives from MetaWindowX11 to allow for some Xwayland
specific vfunc that wouldn't apply to plain X11 windows, such as
shortcut inhibit routines.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
Adding an internal signal and use it to update the internal state before
emitting "monitors-changed" which will be repeated by the screen to the world.
https://bugzilla.gnome.org/show_bug.cgi?id=788860
When we received two hot plug events that both resulted in headless
configuration, we tried to find a new window monitor given the old.
That resulted in a null pointer dereference; avoid that by only trying
to find the same monitor if there was an old one.
https://bugzilla.gnome.org/show_bug.cgi?id=788607
To keep feature parity with the Wayland backend, and
to improve the overall tiling experience with GTK apps,
add the _GTK_EDGE_CONSTRAINTS X11 atom and update it
when necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
GTK has the ability to handle client-decorated windows
in such a way that the behavior of these windows must
match the behavior of the current window manager.
In Mutter, windows can be tiled horizontally (and, in
the future, vertically as well), which comes with a few
requirements that the toolkit must supply. Tiled windows
have their borders' behavior changed depending on the
tiled position, and the toolkit must be aware of this
information in order to properly match the window manager
behavior.
In order to provide toolkits with more precise and general
data regarding resizable and constrained edges, this patch
makes MetaWindow track its own edge constraints.
This will later be used by the backends to send information
to the toolkit.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
When computing a potential match for a tiled window, there is a
chance we face the case where 2 windows really complement each
other's tile mode (i.e. left and right) but they have different
sizes, and their borders don't really touch each other.
In that case, the current code would mistakenly assume they're
tile matches, and would resize them with either a hole or an
overlapping area between windows. This is clearly a misbehavior
that is a consequence of the previous assumptions pre-resizable
tiles.
This patch adapts the tile match algorithm to also consider the
touching edges when computing the matching tile, unless:
* the window is not currently tiled (for example when computing
the tile preview)
* the window is currently resized in tandem with an existing
tile match
https://bugzilla.gnome.org/show_bug.cgi?id=645153
bar
When a pair of tiled windows are grouped together, they
are treated as parts of a whole and interacting with one
affects the other.
Following the idea that sibling tiled windows are treated
as part of the same group, they should also be raised and
lowered together.
It is still possible to break tiled windows grouping by
simply untiling the window with the keyboard or by grabbing
and resizing or moving the window with the cursor.
This patch makes sibling tiled windows be lowered and raised
in tandem. For future reference, this behavior is documented
in [1].
[1] https://wiki.gnome.org/GeorgesNeto/MinutesOfFeaneron/Tilinghttps://bugzilla.gnome.org/show_bug.cgi?id=645153
There is a variable in meta_window_edge_resistance_for_resize
that isn't really helpful: it just assumes TRUE, and is passed
to apply_edge_resistance_to_each_side.
This patch removes that useless variable and simply pass TRUE
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
When windows are tiled, it improves the interaction with
them when they have a set of snapping edges relative to
the monitor. For example, when there's a document editor
and a PDF file opened, I might want to rescale the former
to 2/3 of the screen and the latter to 1/3.
These snapping sections are not really tied to any other
window, and only depend on the current work area of the
window. Thus, it is not necessary to adapt the current
snapping edge detection algorithm.
This patch adds the necessary code in edge-resistance.c
to special-case tiled windows and allow them to cover
1/4, 1/3 and 1/2 (horizontally) of the screen. These
values are hardcoded.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
After the introduction of the possibility to resize tiled windows,
it is a sensible decision to make windows aware of their tiling
match. A tiling match is another window that is tiled in such a
way that is the complement of the current window.
The newly introduced behavior attepts to make tiling as smooth as
possible, with the following rules:
* Windows now compute their tile match when tiling and, if there's
a match, they automatically complement the sibling's width.
* Resizing a window with a sibling automatically resizes the sibling
too to be the complement of the window's width.
* It is not possible to resize below windows' minimum widths.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
Now that tiled windows are resizable, the user may grow a tiled
windows until it covers the entire work area. As this makes the
window state mostly indistinguishable from maximization, avoid
subtle differences by properly maximizing the window in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
Currently tiled windows are not resizable and their size is fixed
to half the screen width. Adjust the code to work with fractions
other than half, and allow users to adjust the split by dragging
the window edge that is not constrained by a monitor edge.
Follow-up patches will improve on that by resizing neighboring
tiled windows by a shared edge, and making the functionality
available to client-side decorated windows implementing the
new edge constraints protocol.
Now that the preview tile mode has been split from the window's
tile_mode property, it is much more natural to pass the requested
tile_mode to the tile() function instead of setting it externally
and calling the function to apply the state.
The existing semantics of the tile_mode property are terribly confusing,
as it depends on some other property whether it represents the requested
or current mode. Clear this up by just using separate variables for the
two. As it is unlikely that we will ever support more than one tile
preview, we can track the requested mode globally instead of adding
another per-window variable.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
update_num_workspaces() is a no-op when the number of workspaces
did not actually change. That is fine, except that we still want
to initialize the _NET_NUMBER_OF_DESKTOPS hint on startup to not
break components like nautilus-desktop that rely on it.
https://bugzilla.gnome.org/show_bug.cgi?id=760651
Automatic maximization is done when a window is almost the size of the
work area of a monitor. This makes no sense to try when there is no
monitor available, so skip trying to do this when headless.
https://bugzilla.gnome.org/show_bug.cgi?id=787637
When we are headless, treat this as if the window is always not monitor
sized. This might cause windows to temporarly become redirected while
being headless, but this is harmless as when a new monitor is
connected, we'll recalculate weather it should be redirected or not.
https://bugzilla.gnome.org/show_bug.cgi?id=787637
When dynamic workspaces are used, we pick up an existing NUMBER_OF_DESKTOP
hint in meta_screen_init_workspaces() to properly restore workspaces
on restart. Unconditionally setting that hint to 1 *before* reading it
breaks that, and we end up shifting all windows to the first workspace.
This reverts commit 8532b10290.
https://bugzilla.gnome.org/show_bug.cgi?id=760651
Also adds a soft assert to meta_window_is_on_primary_monitor() to make
it easier to spot when callers might want to handle headless
in a certain way.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
For now we abuse of meta_window_get_flatpak_id not to break the APIs,
so that it's working seamlessly in gnone shell too.
Rename flatpak_id to sandboxed_app_id internally to get prepared to the future
API.
https://bugzilla.gnome.org/show_bug.cgi?id=788217
If a non-latin based keyboard layout is active, for example Cyrillic,
keybindings won't work unless we resolve the bound keysyms on a
secondary latin based layout. So, to make keybindings work on non-latin
based layouts, detect if a keymap doesn't have all of the basic latin
letters (a-z) and resolve from an additional US layout as well.
https://bugzilla.gnome.org/show_bug.cgi?id=787016
Add the infrastructure to resolve keybinding symbols from multiple
layouts. It is still unused, but will be, when the primary layout does
not have the required latin keysyms in it.
https://bugzilla.gnome.org/show_bug.cgi?id=787016
Make sure to call set_number_of_spaces_hint in meta_screen_new.
_NET_NUMBER_OF_DESKTOPS is required by nautilus-desktop to correctly
get the desktop workarea.
https://bugzilla.gnome.org/show_bug.cgi?id=760651
This avoids updating state (such as position, size etc) when going
headless. Eventually, when non-headless, things will be updated again,
and not until then will we be able to update to a valid state.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
