A window's unconstrained_rect is essentially just the target rectangle
we hand to meta_window_move_resize_internal() except it's not updated
until the window actually moves or resizes.
As such, for wayland client resizes, since they're async, using
window->unconstrained_rect right after calling move_resize_internal()
to update the grab anchor position on unmaximize doesn't work as it
does for X clients.
To fix this, we can just use the target rectangle for the grab
anchor. Note that comment here was already wrong since it says we
should be taking constraints into account and yet the code used the
unconstrained rect anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=770345
In order for the compositor plugin to be able to animate window size
changes properly we need to let it know of the starting and final
window sizes.
For X clients this can be done synchronously and thus with a single
call into the compositor plugin since it's us (the window manager)
who's in charge of the final window size.
Wayland clients though, have the final say over their window size
since it's determined from the client allocated buffer.
This patch moves the meta_compositor_size_change_window() calls before
move_resize_internal() which lets the compositor plugin know the old
window size and freezes the MetaWindowActor.
Then we get rid of the META_MOVE_RESIZE_DONT_SYNC_COMPOSITOR flag
since it's not needed anymore as the window actor is frozen and that
means we can use meta_compositor_sync_window_geometry() as the point
where we inform the compositor plugin of the final window size.
https://bugzilla.gnome.org/show_bug.cgi?id=770345
And remove the wayland-specific handling. This works for both Wayland and
X11 (provided the compositor receives pad events through a passive grab
there).
https://bugzilla.gnome.org/show_bug.cgi?id=773779
We kind of rely on the ::show-pad-osd handler to destroy the
previous actor. Just prevent the emission of multiple signals
till the actor has been destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=771067
Commit fcc7501eb8 had the side-effect of
stacking fullscreen windows below docks which went unnoticed since we
don't use docks in GNOME anymore.
Instead of re-introducing the fullscreen layer, which we don't need
otherwise, we can fix this issue by ensuring we stack docks below all
other windows when the monitor they're on is marked fullscreen. This
has the added benefit that the visibility rule for 3rd party docks
becomes the same as gnome-shell's chrome.
https://bugzilla.gnome.org/show_bug.cgi?id=772937
mutter would remove focus from a toplevel when showing one of its
transient window which is not on top and not focused.
When using xdg_popup without grab as allowed in xdg_shell v6, the popup
wouldn't be focused, and if an intermediate event occurs before the
popup is shown, it's not placed on top either, which could randomly
trigger a loss of focus in the corresponding toplevel window.
Remove that special case, it doesn't make much sense to globally unset
focus when mapping a new window.
https://bugzilla.gnome.org/show_bug.cgi?id=773210
The frame rect will at this point not be set for Wayland popups, since
the popup is placed and constrained before the actual buffer will be
attached. To still be able to calculate a proper monitor to be used for
constraining, use the ConstraintInfo::current dimensions instead, since
they will have the expected size. This should not cause any issues with
present paths since when a window is otherwise placed, it usually
doesn't change monitor calculation result.
This fixes opening a popup menu that would be positioned on the left
edge of a not-left-most monitor, for example a 'File' menu on a window
maximized on a second monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=773141
The order doesn't only affect the visual layout, but also which action
cancels the dialog (and therefore responds to Escape). It is completely
surprising that this triggers a destructive action like force-quit, so
swap the actions to wait when the dialog is cancelled.
https://bugzilla.gnome.org/show_bug.cgi?id=737109
GNOME Shell's window matching currently fails frequently with Flatpak
applications, as one of the primary hints used to link windows with
.desktop files - the WM_CLASS - no longer matches when flatpak renames
the exported .desktop file. Luckily, Flatpak provides us with a fail-safe
way to map from the PID to the corresponding application ID, so expose an
appropriate method that allows GNOME Shell to reliably match windows to
the corresponding Flatpak app.
https://bugzilla.gnome.org/show_bug.cgi?id=772614
In order to kill a window, on both X11 and wayland we first try to
kill(3) the corresponding process, so we can add the newly added
get_client_pid() method to share that code.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
It is often useful to identify the client process that created
a particular window, however the existing meta_window_get_pid()
method relies on _NET_WM_PID, which is only available on X11 and
depends on applications to set it correctly (which may not even
be possible when the app runs in its own PID namespace as Flatpak
apps do). So add a get_client_pid() method that uses windowing
system facilities to resolve the PID associated with a particular
window.
https://bugzilla.gnome.org/show_bug.cgi?id=772613
When a modal transient is unmanaging, most likely the parent of the
modal transient should be focused.
In Wayland, a MetaWindow is created when a shell surface role (like
xdg_toplevel) is created, but a window cannot be shown until a buffer
is attached. If a client would create two modal transients and make
them both have the same parent, but only one get a buffer attached
(i.e. shown), when unmanaging the modal transient that was showing,
when finding a new focus candidate, the stacking code will ignore the
not-to-be-shown buffer-less modal transient when finding a good
candidate for focusing. In the case described here, this means it will
find the parent of the unmanaging modal transient.
This newly chosen candidate will then be passed to meta_window_focus();
meta_window_focus() will then try to find any modal transient to focus
instead, will find the one without any buffer, then fail to focus it
because it cannot be mapped, thus making meta_window_focus() not focus
anything. Since meta_window_focus() didn't change any focus state, the
assert in meta_window_unmanage() checking that the unmanaging window
isn't focused anymore will be hit, causing mutter to abort.
For now, fix this by checking whether the modal transient can actually
be focused in meta_window_focus(). For X11 client windows, a window
will be defined to be focusable always, but for Wayland client windows,
a window will be determined focusable only if it has a buffer attached.
In the future, we should probably do a more thorough refactorization of
focus handling to get rid of any X11 - Wayland differences.
https://bugzilla.gnome.org/show_bug.cgi?id=757568
Even without a compositor grab, key events may still be expected to
be processed by the compositor and not applications, for instance
when using ctrl-alt-tab to keynav in the top bar. On X11, focus is
moved to the stage window in that case, so that events are processed
before they are dispatched by the window manager. On wayland, we need
to handle this case ourselves, so make sure to not pass key events to
wayland in that case, and move the key focus back to the stage when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=758167
For some reason, when a modal dialog was made an attaching
transient-for, if the window wasn't "constructing", it would be
unmanaged and rely on some side effect to be recreated. This side
effect is not triggered for Wayland clients, thus if one happen to set
a surface as "modal" via gtk_surface.set_modal before
xdg_toplevel.set_parent, it'd be unmanaged and never show up.
Instead, simply just set the tranciency anyway for Wayland clients.
This makes GTK+ clients that set_modal() before set_transient_for()
work.
https://bugzilla.gnome.org/show_bug.cgi?id=770324
Windows from Xwayland still needs to use the Wayland path, but is
represented an MetaWindowX11, thus the abstraction introduced in
"window: Make meta_window_has_pointer() per protocol implemented"
is wrong. Lets turn back time, and reconsider how this can be
abstracted more correctly in the future.
This reverts commit 9fb891d216.
Add support for assigning a window a custom window placement rule used
for calculating the initial window position as well as defining how a
window is constrained.
The custom rule is a declarative rule which defines a set of parameters
which the placing algorithm and constrain algorithm uses for
calculating the position of a window. It is meant to be used to
implement positioning of menus and other popup windows created via
Wayland.
A custom placement rule replaces any other placement or constraint
rule.
https://bugzilla.gnome.org/show_bug.cgi?id=769936
There may be external/compositor-specific reasons to trigger the
pad OSD. Expose this call so the pad OSD can be triggered looking
up the right settings, monitor, etc...
This API will be used from the gnome-shell pad OSD implementation, in order
to show the actions that currently apply to every button/ring/strip in the
tablet.
When launching a GNOME session from a text-mode VT, the logind session
type is unlikely to be set to either "wayland" or "x11". We search for a
supported session type first with logind and then with
$XDG_SESSION_TYPE. As a fallback, we also test $DISPLAY in case of a
"tty" logind session to support starting through xinit. Ideally, such
setups should set XDG_SESSION_TYPE=x11.
If no supported session type is found, we throw an error.
https://bugzilla.gnome.org/show_bug.cgi?id=759388
They are already effectively interchangeable so this should reduce
pointless casts.
Just like in GDK though, we need to keep the old definition for
instrospection to be able to include the struct's fields.
Add support for drawing a stage using multiple framebuffers each making
up one part of the stage. This works by the stage backend
(ClutterStageWindow) providing a list of views which will be for
splitting up the stage in different regions.
A view layout, for now, is a set of rectangles. The stage window (i.e.
stage "backend" will use this information when drawing a frame, using
one framebuffer for each view. The scene graph is adapted to explictly
take a view when painting the stage. It will use this view, its
assigned framebuffer and layout to offset and clip the drawing
accordingly.
This effectively removes any notion of "stage framebuffer", since each
stage now may consist of multiple framebuffers. Therefore, API
involving this has been deprecated and made no-ops; namely
clutter_stage_ensure_context(). Callers are now assumed to either
always use a framebuffer reference explicitly, or push/pop the
framebuffer of a given view where the code has not yet changed to use
the explicit-buffer-using cogl API.
Currently only the nested X11 backend supports this mode fully, and the
per view framebuffers are all offscreen. Upon frame completion, it'll
blit each view's framebuffer onto the onscreen framebuffer before
swapping.
Other backends (X11 CM and native/KMS) are adapted to manage a
full-stage view. The X11 CM backend will continue to use this method,
while the native/KMS backend will be adopted to use multiple view
drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Make it possible to force mutter to start as a X11 compositing/window
manager. This is needed when intending to start mutter as an X11 window
manager while running inside a Wayland session, for example when
intending to debug it in Xephyr.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
Introduce two new clutter backends: MetaClutterBackendX11 and
MetaClutterBackendNative. They are so far only wrap ClutterBackendX11
and ClutterBackendEglNative respectively, but the aim is to move things
from the original clutter backends when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=768976
This layer isn't really being used and in fact, it causes
meta_stack_get_default_focus_window() to return a fullscreen window
even if the naturally topmost window in the stack isn't a fullscreen
one.
Note that commit a3bf9b01aa changed how
we choose the default focus window from the MRU to the topmost in the
stack.
https://bugzilla.gnome.org/show_bug.cgi?id=768221
When restarting (X compositor only, obviously), we want to keep
the same window focused. There is code that tries to do this by
calling XGetInputFocus() but the previously focused window will
almost certainly not still be focused by the time we get to the
point where we call XGetInputFocus(), and in fact, probably was
no longer correct after the previous window manager exited, so
the net result is that we tend to focus no window on restart.
A better approach is to leave the _NET_ACTIVE_WINDOW property
set on the root window during exit, and if we find it set when
starting, use that to initialize focus.
https://bugzilla.gnome.org/show_bug.cgi?id=766243
Emit a signal so that interested parties can recreate their FBOs and
queue a full scene graph redraw to ensure we don't end up showing
graphical artifacts.
This relies on the GL driver supporting the
NV_robustness_video_memory_purge extension and cogl creating a
suitable GL context. For now we only make use of it with the X backend
since the only driver with which this is useful is NVIDIA.
https://bugzilla.gnome.org/show_bug.cgi?id=739178
printf string precision counts bytes so we may end up creating invalid
UTF-8 strings here. Instead, use glib's unicode aware methods to clip
the title.
https://bugzilla.gnome.org/show_bug.cgi?id=765535
Stacking hidden X windows below the guard window is a necessity to
ensure input events aren't delivered to them. Wayland windows don't
need this because the decision to send them input events is done by us
looking at the clutter scene graph.
But, since we don't stack hidden wayland windows along with their X
siblings we lose their relative stack positions while hidden. As
there's no ill side effect to re-stacking hidden wayland windows below
the X guard window we can fix this by just doing it regardless of
window type.
https://bugzilla.gnome.org/show_bug.cgi?id=764844
If we try to send notify event (either from surface_state_changed()
or from meta_window_wayland_move_resize_internal()),
we will crash, because we don't have a sufrace anymore.
There's no reason why to resize the window that is being
unmanaged anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=751847
meta_parse_accelerator() considers 0 length accelerator strings as
valid, meaning that the keybinding should be disabled. Unfortunately,
it doesn't initialize the MetaKeyCombo so if the caller doesn't
initialize it either, we end up using random values and possibly
grabbing random keys.
https://bugzilla.gnome.org/show_bug.cgi?id=766270
Before this commit, on Wayland, the buffer rect would have the size of
the attached Wayland buffer, no matter the scale. The scale would then
be applied ad-hoc by callers when a sane rectangle was needed. This
commit changes buffer_rect to rather represent the surface rect (i.e.
what is drawn on the stage, including client side shadow). The users of
buffer_rect will no longer need to scale the buffer_rect themself to
get a usable rectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=763431
