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
Since g_array_append_val isn't smart enough to do a proper upcast, we
have to do it manually, lest we get junk.
This fixes various RAISE_ABOVE: window not in stack: 0x8100c8003
warnings that appear on 32-bit systems.
Each wl_surface.commit with a newly attached buffer should result in
one wl_buffer.release for the attached buffer. For example attaching
the same buffer to two different surfaces must always result in two
wl_buffer.release events being emitted by the server. The client is
responsible for counting the wl_buffer.release events and be sure to
have received as many release events as it has attached and committed
the buffer, before reusing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762828
On the X11 backend we don't track the pointer position in
priv->current_x/y which remain set to zero. That means we never set
the clutter stage cursor if point 0,0 isn't covered by any monitor
since we return early.
Commit 4bebc5e5fa introduced this to
avoid crashing on the prepare-at handlers when the cursor position
doesn't fall inside any monitor area but we can handle that higher up
in the stack. In that case, the sprite's scale doesn't matter since
the cursor won't be shown anyway so we can skip setting it.
https://bugzilla.gnome.org/show_bug.cgi?id=763159
CSD X11 clients and Wayland clients don't have a window frame drawn by
the compositor to flash. So instead of flashing the whole screen when
configured to just flash the window, flash just the window region.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
To support invoking the system bell on Wayland we shouldn't have paths
that fallback to X11. Let the X11 caller deal with the absence of
libcanberra, and change API to not take any X events.
https://bugzilla.gnome.org/show_bug.cgi?id=763284
The libsn API provides its timestamps in the "Time" X11 type, which is
usually is a typedef for "unsigned long". The type of the "timestamp"
parameter of StartupNotificationSequence is a signed 64 bit integer.
When building on an architecture where a "unsigned long" is not 64 bit,
we'd then pass a 32 bit unsigned integer via a va_list where a signed 64
bit integer is expected causing va_arg to read past the passed 32 bit
unsigned integer.
Fix this by ensuring that we always pass the expected type via the
va_list. Also change the internal timestamp type from time_t (which
size is undefined) to gint64, to avoid any potential overflow issues.
https://bugzilla.gnome.org/show_bug.cgi?id=762763
If a MetaLater callback queued another MetaLater with a scheduling
later than the one currently being invoked, make it so that the newly
scheduled callback will actually be invoked.
The fact that it doesn't already do this is a regression from
cd7a968093.
https://bugzilla.gnome.org/show_bug.cgi?id=755605
As of "core: start as wayland display server when
XDG_SESSION_TYPE=wayland" it is no longer possible to run a nested
mutter Wayland session on top of another Wayland session. This patch
adds a command line argument to make it possible to force mutter to
start as a nested compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=758658
This is kind of in a middle ground at the moment. Even though it
handles sequences not coming from libsn, they're added nowhere at
the moment, we'll rely on the app launch context being in the x11
side at the moment.
Also, even though we do create internal sequence objects, we keep
exposing SnStartupSequences to make gnome-shell happy, we could
consider making this object "public" (and the sequence objects with
it), things stay private at the moment.
https://bugzilla.gnome.org/show_bug.cgi?id=762268
If a broken or naughty application tries set up its windows to create
a loop in the transient relationship, mutter will hang, looping forever
in meta_window_foreach_ancestor()
To avoid looping infinitely at various point in the code, check for a
possible loop when setting the transient relationship and deny the
request to set a window transient for another if that would create a
loop.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759299
