We only update the last device from actual input interaction here,
avoid this pair of events. This is specially nasty with
CLUTTER_DEVICE_REMOVED, since the device we're notifying upon will be
disposed soon after emission.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1460
This is already taken care of in meta_backend_monitors_changed(), called
from the same code paths that emit ::monitors-changed-internal. It is
better to leave this up to backend internals.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1448
Analogous to `ClutterDrawDebugFlag` but intended for concepts that
are not present in Clutter, such as Wayland/X11 opaque regions.
Also add the first flag for the later.
To set the flag, run:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
meta_run() is still left intact and does the same as before; the new
functions are only intended to be used by tests, as they may need to set
things up after starting up. Doing so linearly in the test case is much
easier than adding callbacks, so meta_run() is split up to make this
possible.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
The delete event was used for signalling the close button was clicked on
clutter windows. Being a compositor we should never see these, unless
we're running nested. Remove the plumbing of the DELETE event and just
directly call meta_quit() when we see it, if we're running nested.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
Allowing code from inside mutter to create a child process and
delegate on it some of its tasks is something very useful. This can
be done easily with the g_subprocess and g_subprocess_launcher classes
already available in GLib and GObject.
Unfortunately, although the child process can be a graphical program,
currently it is not possible for the inner code to identify the
windows created by the child in a secure manner (this is: being able
to ensure that a malicious program won't be able to trick the inner
code into thinking it is a child process launched by it).
Under X11 this is not a problem because any program has full control
over their windows, but under Wayland it is a different story: a
program can't neither force their window to be kept at the top (like a
docker program does) or at the bottom (like a program for desktop icons
does), nor hide it from the list of windows. This means that it is not
possible for a "classic", non-priviledged program, to fulfill these
tasks, and it can be done only from code inside mutter (like a
gnome-shell extension).
This is a non desirable situation, because an extension runs in the
same main loop than the whole desktop itself, which means that a
complex extension can need to do too much work inside the main loop,
and freeze the whole desktop for too much time. Also, it is important
to note that javascript doesn't have access to fork(), or threads,
which means that, at most, all the parallel computing that can do is
those available in the _async calls in GLib/GObject.
Also, having to create an extension for any priviledged graphical
element is an stopper for a lot of programmers who already know
GTK+ but doesn't know Clutter.
This patch wants to offer a solution to this problem, by offering a
new class that allows to launch a trusted child process from inside
mutter, and make it to use an specific UNIX socket to communicate
with the compositor. It also allows to check whether an specific
MetaWindow was created by one of this trusted child processes or not.
This allows to create extensions that launch a child process, and
when that process creates a window, the extension can confirm in a
secure way that the window really belongs to that process
launched by it, so it can give to that window "superpowers" like
being kept at the bottom of the desktop, not being listed in the
list of windows or shown in the Activities panel... Also, in future
versions, it could easily implement protocol extensions that only
could be used by these trusted child processes.
Several examples of the usefulness of this are that, with it, it
is possible to write programs that implements:
- desktop icons
- a dock
- a top or bottom bar
...
all in a secure manner, avoiding insecure programs to do the same.
In fact, even if the same code is launched manually, it won't have
those privileges, only the specific process launched from inside
mutter.
Since this is only needed under Wayland, it won't work under X11.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/741
There are a couple of places in gnome-shell where we aren't interested
in which workspace is active, but whether a given workspace is active.
Of course it's easy to use the former to determine the latter, but we
can offer a convenience property on the workspace itself almost for
free, so let's do that.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1336
Make the clutter_input_device_get_actor() API public and remove
clutter_input_device_get_pointer_actor() in favour of the new function.
This allows also getting the "pointer" actor for a given touch sequence,
not only for real pointer input devices like mice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
X11 window stacking operations are by nature prone to race conditions.
For example, we might queue a "raise above" operation, but before it
actually takes place, the sibling the window was to be rased above, is
withdrawn.
In these cases we'd log warnings even though they are expected to
happen. Downgrade these warnings to debug messages, only printed when
MUTTER_VERBOSE is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
When an app disappears after some data from it has been copied to the
clipboard, the owner of the clipboard selection becomes a new memory
selection source. The initial reference this new selection source is
never unref'ed, which leads to this being leaked on the next clipboard
selection owner change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1293
Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
We would get the MetaDisplay from the backend singleton before creating
the MetaCompositor, then in MetaCompositor, get the backend singleton
again to get the stage. To get rid of the extra singleton fetching, just
pass the backend the MetaCompositor constructors, and fetch the stage
directly from the backend everytime it's needed.
This also makes it available earlier than before, as we didn't set our
instance private stage pointer until the manage() call.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Move Wayland support (i.e. the MetaWaylandCompositor object) made to be
part of the backend. This is due to the fact that it is needed by the
backend initialization, e.g. the Wayland EGLDisplay server support.
The backend is changed to be more involved in Wayland and clutter
initialization, so that the parts needed for clutter initialization
happens before clutter itself initialization happens, and the rest
happens after. This simplifies the setup a bit, as clutter and Wayland
init now happens as part of the backend initialization.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
Since PIDs are inherently insecure because they are reused after a
certain amount of processes was started, it's possible the client PID
was spoofed by the client.
So make sure users of the meta_window_get_pid() API are aware of those
issues and add a note to the documentation that the PID can not be
totally trusted.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
Since the PID of a window can't change as long as the window exists, we
can safely cache it after we got a valid PID once, so do that by adding
a new `window->client_pid` private property.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
The shell uses the PID of windows to map them to apps or to find out
which window/app triggered a dialog. It currently fails to do that in
some situations on Wayland, because meta_window_get_pid() only returns a
valid PID for x11 clients.
So use the client PID instead of the X11-exclusive _NET_WM_PID property
to find out the PID of the process that started the window. We can do
that by simply renaming the already existing
meta_window_get_client_pid() API to meta_window_get_pid() and moving
the old API providing the _NET_WM_PID to meta_window_get_netwm_pid().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
When tiling, we want to set the tile monitor. To not have to do this
from the call site, make meta_window_tile() fall back to the current
monitor if nothing set it prior to the call.
This will make it more convenient for test cases to test tiling
behavior.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The 'assert_size' command checks that the size of the window, both
client side and compositor side, corresponds to an expected size set by
the test case.
The size comparison can only be done when the window is using 'csd', in
order for both the client and server to have the same amount of
understanding of the title bar. For ssd, the client cannot know how
large the title bar, thus cannot verify the full window size.
Sizes can be specified to mean the size of the monitor divided by a
number. This is that one can make sure a window is maximized or
fullscreened correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
Move to center uses all monitors for calculating work area.
This can lead to an unexpected behaviour on some monitor
configurations resulting in current window being split between
monitors. We should move window to the center of the active display.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1073
Add MetaAnonymousFile, an abstraction around anonymous read-only files.
Files can be created by calling meta_anonymous_file_new(), passing the
data of the file. Subsequent calls to meta_anonymous_file_open_fd()
return a fd that's ready to be sent over the socket.
When mapmode is META_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only
guaranteed to be mmap-able readonly with MAP_PRIVATE but does not
require duplicating the file for each resource when memfd_create is
available. META_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the
client must be able to map the file with MAP_SHARED but it also means
that the file has to be duplicated even when memfd_create is available.
Pretty much all of this code was written for weston by Sebastian Wick,
see https://gitlab.freedesktop.org/wayland/weston/merge_requests/240.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
For the cases where we read a fixed size from the selection (eg. imposing
limits for the clipboard manager), g_input_stream_read_bytes_async() might
not read up to this given size if the other side is spoonfeeding it content.
Cater for multiple read/write cycles here, until (maximum) transfer size is
reached.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:
1) Instantiate the object - only construct the instance, making it
possible for users to start listening to signals etc
2) Manage - this e.g. establishes the compositor as the X11 compositing
manager and similar things.
This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.
For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While at it, fix some style inconsistencies, for now use a single
singleton struct instead of multiple static variables, and
other non-functional cleanups. Semantically, there is no changes
introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
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
Currently we check whether a window is alive everytime it's focused.
This means that an application that doesn't respond to the check-alive
event during startup always showing the "application froze" dialog,
without the user ever trying to interact with it.
An example where this tends to to happen is with games, and for this
particular scenario, it's purely an annoyance, as I never tried to
interact with the game window in the first place, so I don't care that
it's not responding - it's loading.
To avoid these unnecessary particular "app-is-frozen" popups, remove the
alive check from the focus function, and instead move it back to the
"meta_window_activate_full()" call. To also trigger it slightly more
often, also add it to the path that triggers the window focus when a
user actively clicks on the window.
This means that we currently check whether a window is alive on:
* Any time the window is activated. This means e.g. alt-tab or
selecting the window in the overview.
* The user clicks on the window.
Note that the second only works for an already focused window on
Wayland, as on X11, we don't refocus it. This particular case isn't
changed with this commit, as we didn't call meta_window_focus() to begin
with here.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1182
Support for them appears to be way less common than e.g. png, which is
currently the preferred format from Firefox, Chromium, Libreoffice and others.
Adopt to that fact.
As a side effect, this works around a bug observed when copying images in
Firefox on Wayland.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1141
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
We used to inhibit all pad actions while the OSD is shown, but one we
would actually want to handle are mode switches while the OSD is open.
So it has an opportunity to catch up to the mode switch.
This lets MetaInputSettings reflect the mode switch (eg. when querying
action labels), so the OSD has an opportunity to update the current
actions.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/975
Commit cda9579034 fixed a corner case when setting the initial workspace
state of transient windows, but it still missed a case:
should_be_on_all_workspaces() returns whether the window should be on all
workspaces according to its properties/placement, but it doesn't take
transient relations into account.
That means in case of nested transients, we can still fail the assert:
1. on-all-workspaces toplevel
2. should_be_on_all_workspaces() is TRUE for the first transient's parent,
as the window from (1) has on_all_workspaces_requested == TRUE
3. should_be_on_all_workspaces() is FALSE for the second transient's
parent, as the window from (2) is only on-all-workspace because
of its parent
We can fix this by either using the state from the root ancestor
instead of the direct transient parent, or by using the parent's
on_all_workspaces_state.
The latter is simpler, so go with that.
https://gitlab.gnome.org/GNOME/mutter/issues/1083
Make sure it is only the special modifier (hardcoded to 1 currently)
which is being pressed (not counting locked modifiers) before notifying
that the special modifier is pressed, as we are interested in it being
pressed alone and not in combination with other modifier keys.
This helps in two ways:
- Pressing alt, then ctrl, then releasing both won't trigger the locate
pointer action.
- Pressing alt, then ctrl, then down/up to switch workspace won't interpret
the last up/down keypress as an additional key on top of the special ctrl
modifier, thus won't be forwarded down to the focused client in the last
second.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/812https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
If you first press a key that triggers the "special modifier key" paths
(ctrl, super), and then press another key that doesn't match (yet?) any
keybindings (eg. ctrl+alt, super+x), the second key press goes twice
through process_event(), once in the processing of this so far special
combination and another while we let the event through.
In order to keep things consistent, handle it differently depending on
whether we are a wayland compositor or not. For X11, consider the event
handled after the call to process_event() in process_special_modifier_key().
For Wayland, as XIAllowEvents is not the mechanism that allows clients see
the key event, we can just fall through the regular paths, without this
special handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1014
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
To organize things a bit better, put the fields related to the placement
rule state in its own anonymous struct inside MetaWindow. While at it,
rename the somewhat oddly named variable that in practice means the
current relative window position.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
A placement rule is always about placing a window relative to its
parent. In order to eventually place it against predicted future parent
positions, make the placement rule processing output relative
coordinates, having the caller deal with turning them into absolute.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/705
This is made a signal, so the upper layers (read: gnome-shell) may
decide what services to spawn. The signal argument contains a task
that will resume MetaX11Display startup after it is returned upon.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/945
We artificially made Xwayland initialization synchronous, as we used
to rely on MetaX11Display and other bits during meta_display_open().
With support for Xwayland on demand and --no-x11, this is certainly
not the case.
So drop the main loop surrounding Xwayland initialization, and turn
it into an async operation called from meta_display_init_x11(). This
function is turned then into the high-level entry point that will
get you from no X server to having a MetaX11Display.
The role of meta_init() in Xwayland initialization is thus reduced
to setting up the sockets. Notably no processes are spawned from here,
deferring that till there is a MetaDisplay to poke.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
This ATM completes the task right away, but we will want to do
further things here that are asynchronous in nature, so prepare
for this operation being async.
Since the X11 backend doesn't really need this, make it go on
the fast lane and open the MetaX11Display right away, the case
of mandatory Xwayland on a wayland session is now handled
separately.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
This used to be set on meta_compositor_manage(), but only if there is a
MetaX11Display. Given meta_display_init_x11() is Wayland only, and we can
always assume compositing to be enabled, just have it invariably set after
the X server is up.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/944
The check-alive feature is there for the user to be able to terminate
frozen applications more easily. However, sometimes applications are
implemented in a way where they fail to be reply to ping requests in a
timely manner, resulting in that, to the compositor, they are
indistinguishable from clients that have frozen indefinitely.
When using an application that has these issues, the GUI showed in
response to the failure to respond to ping requests can become annoying,
as it disrupts the visual presentation of the application.
To allow users to work-around these issues, add a setting allowing them
to configure the timeout waited until an application is considered
frozen, or disabling the check completely.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1080
The cancellable of a request might already be cancelled by the time
the cancelled_cb is connected resulting in finish_cb being called via
ca_context_cancel before g_cancellable_connect returns. In this case
the request that is written to has already been freed.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/1060
There are two surface roles owning a MetaWindow: MetaWaylandShellSurface
(basis of MetaWaylandXdgToplevel, MetaWaylandXdgPopup,
MetaWaylandWlShellSurface, etc), and MetaXwaylandSurface.
With these two role types, the MetaWindow has two different types of
life times. With MetaWaylandShellSurface, the window is owned and
managed by the role itself, while with MetaXwaylandSurface, the
MetaWindow is tied to the X11 window, while the Wayland surface and its
role plays more the role of the backing rendering surface.
Before, for historical reasons, MetaWindow was part of
MetaWaylandSurface, even though just some roles used it, and before
'wayland: Untie MetaWindowXwayland lifetime from the wl_surface' had
equivalent life times as well. But since that commit, the management
changed. To not have the same fied in MetaWaylandSurface being managed
in such drastically different ways, rearrange it so that the roles that
has a MetaWindow themself manages it in the way it is meant to; meaning
MetaWaylandShellSurface practically owns it, while with Xwayland, the
existance of a MetaWindow is tracked via X11.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/835
If a window already is being pinged, it doesn't make sense to send more
pings to the window, instead we should just wait for that answer or
timeout until we send a new one.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Using a timestamp twice in a row (e.g. when activating two windows in
response to the same event or due to other bugs) will break the window
detection and show a close dialog on the wrong window. This is a grave
error that should never happen, so check every timestamp before sending
the ping for uniqueness and if the timestamp was already used and its
ping is still pending, log a warning message and don't send the ping.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
Increase the number of checks whether a window is still responsive and
ping windows on every call to `meta_window_focus()` instead of
`meta_window_activate_full()`. This ensures the window is also pinged in
case normal interaction like clicks on the window happen and a close
dialog will eventually get shown.
Related https://gitlab.gnome.org/GNOME/mutter/issues/395https://gitlab.gnome.org/GNOME/mutter/merge_requests/891
When an X11 window requests an initial workspace, we currently trust
it that the workspace actually exists. However dynamic workspaces
make this easy to get wrong for applications: They make it likely
for the number of workspaces to change between application starts,
and if the app blindly applies its saved state on startup, it will
trigger an assertion.
Make sure that we pass valid parameters to set_workspace_state(),
and simply let the workspace assignment fall through to the default
handling otherwise.
https://gitlab.gnome.org/GNOME/mutter/issues/1029
Most usually, applications either expose clipboard content either as text
or as images, so the prioritization here is pointless. However there's some
outliers like LibreOffice Calc which exports content as both image and text
formats (besides other internal ones).
In that mixed case, we probably prefer to keep text formats, rather than
image based ones.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/919
As we now call `meta_wayland_compositor_repick()` when the effects are
complete for Wayland surfaces, we can safely remove the Wayland specific
code to do the same from `meta_window_show()`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
Currently, `meta_frame_get_mask()` and `meta_ui_frame_get_mask()` will
return the frame mask applied to the current frame size, by querying the
frame themselves.
To be able to get the frame mask at an arbitrary size, change the API to
take a rectangle representing the size at which the frame mask should be
rendered.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1009
In Wayland, window configuration is asynchronous. Window geometry is
constrained, the constrained geometry is sent to the client, and the
client will adapt its surface and acknowledge the configuration. When
acknowledged, we shouldn't reconstrain again, as that may invalidate the
constraint calculated for the configured size.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
The intention of meta_window_wayland_move_resize() is to finish a
move-resize requested previously, e.g. by a state change, or a
interactive resize. Make the function name carry this intention, by
renaming it to meta_window_wayland_finish_move_resize().
https://gitlab.gnome.org/GNOME/mutter/merge_requests/907
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
Most of the layer computation that the stack does actually depends
on the windowing backend, so we will move it to a vfunc.
However before we do that, split out the bit that will be shared.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
When a window that should be stacked above another one is placed in a lower
layer than the other window, we currently allow promoting it to the higher
layer when it has a "transient type". We should do the same when the window
is an actual transient of the other window.
This is particularly relevant for wayland windows, where types play a
much smaller role: Transient windows like non-modal dialogs (and since
commit 666bef7a, popup windows as well) currently end up underneath their
always-on-top parent.
https://gitlab.gnome.org/GNOME/mutter/issues/587
Add an assert that we don't have a MetaWindow::monitor pointer that
points to an old MetaLogicalMonitor. After this, and the other
monitors-changed callbacks have been called, the old MetaLogicalMonitor
will be destoryed, thus if we didn't update the pointer here, we'll
point to freed memory, and will eventually crash later on.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/929
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
Override-redirect windows have no workspace by default, and can't be parent
of a top-level window, so we must check that the parent window is not an
O-R one when setting the workspace state.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/895
Otherwise we'll end up trying to access the out of date state later.
Fixes the following test failure backtrace:
#0 _g_log_abort ()
#1 g_logv ()
#2 g_log ()
#3 meta_monitor_manager_get_logical_monitor_from_number ()
#4 meta_window_get_work_area_for_monitor ()
#5 meta_window_get_tile_area ()
#6 constrain_maximization ()
#7 do_all_constraints ()
#8 meta_window_constrain ()
#9 meta_window_move_resize_internal ()
#10 meta_window_tile ()
https://gitlab.gnome.org/GNOME/mutter/merge_requests/912
Add an adjust_fullscreen_monitor_rect virtual method to MetaWindowClass
and call this from setup_constraint_info() if the window is fullscreen.
This allows MetaWindowClass to adjust the monitor-rectangle used to size
the window when going fullscreen, which will be used in further commits
for a workaround related to fullscreen games under Xwayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/739
This way, we can simply pop up the Looking Glass and run:
>>> Meta.add_clutter_debug_flags(Clutter.DebugFlag.PICK, 0, 0)
And measure specific actions or events on GNOME Shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/862
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
Requesting a selection with a NULL data source means "unset the clipboard",
but internally we use an unset clipboard as the indication that the
clipboard manager should take over.
Moreover, this unset request may go unheard if the current owner is someone
else than the MetaWaylandDataDevice.
Instead, set a dummy data source with no mimetypes nor data, this both
prevents the clipboard manager from taking over and ensures the selection
is replaced with it.
The MetaSelectionSourceMemory was also added some checks to allow for this
dummy mode.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/793
Otherwise we'll get the warning
../src/core/main.c: In function 'meta_test_init':
../src/core/main.c:755:1: error: function might be candidate for attribute 'noreturn' [-Werror=suggest-attribute=noreturn]
755 | meta_test_init (void)
| ^~~~~~~~~~~~~~
when building without Wayland.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/837
Mutter issues a synchronous grab on the pointer for unfocused client
windows to be able to catch the button events first and raise/focus
client windows accordingly.
When there is a synchronous grab in effect, all events are queued until
the grabbing client releases the event queue as it processes the events.
Mutter does release the events in its event handler function but does so
only if it is able to find the window matching the event. If the window
is a shell widget, that matching may fail and therefore Mutter will not
release the events, hence causing a freeze in pointer events delivery.
To avoid the issue, make sure we sync the pointer events in case we
can't find a matching window.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/821
With the addition of the locate-pointer special keybinding (defaults to
the [Control] key), we have now two separate special modifier keys which
can be triggered separately, one for the locate-pointer action and
another one for overlay.
When processing those special modifier keys, mutter must ensure that the
key was pressed alone, being a modifier, the key could otherwise be part
of another key combo.
As result, if both special modifiers keys are pressed simultaneously,
mutter will try to trigger the function for the second key being
pressed, and since those special modifier keys have no default handler
function set, that will crash mutter.
Check if the handler has a function associated and treat the keybinding
as not found if no handler function is set, as with the special modifier
keys.
https://gitlab.gnome.org/GNOME/mutter/issues/823
The `process_event()` would check for a existing keybinding handler and
abort if there is none, however the test is done after the handler had
been accessed, hence defeating the purpose of the check.
Move the check to verify there is an existing keybinding handler before
actually using it.
https://gitlab.gnome.org/GNOME/mutter/issues/823
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
We have a "setup" phase, used internally to initialize early the x11
side of things like the stack tracker, and an "opened" phase where
other upper parts may hook up to. This latter phase is delayed during
initialization so the upper parts have a change to connect to on
plugin creation.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
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
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
Since Clutter's backend relies on MetaBackend now, initialzation has
to go through meta_init(), both in mutter and in gnome-shell.
However the compositor enum and backend gtype used to enforce the
environment used for tests are private, so instead expose a test
initialization function that can be used from both mutter and
gnome-shell.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/750
This object can be generally triggered without a X11 display, so make sure
this is alright. For guard window checks, use our internal
meta_stack_tracker_is_guard_window() call, which is already no-x11 aware.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
We indirectly were relying on the MetaX11Stack for this. We strictly
need the _NET_CLIENT_LIST* property updates there, so move our own
internal synchronization to common code.
Fixes stacking changes of windows while there's no MetaX11Display.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendX11, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
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
