Just like we do for buttons, with a few twists. These have 2 directions
mappable to different keycombos, and are affected by the current mode
in their group.
https://bugzilla.gnome.org/show_bug.cgi?id=782033
Moved from g-s-d's media keys plugin, where it was called
"video-rotate", since it requires changing the current monitor
configuration and we want to remove the old DBus API.
https://bugzilla.gnome.org/show_bug.cgi?id=781906
Since commit 6b5cf2e, we keep override redirect windows on a layer
above regular windows in the clutter actor scene graph. In the X
server, and thus for input purposes, these windows might end up being
stacked below regular windows though, e.g. because a new regular
window is mapped after an OR window.
Fix this disconnect by re-stacking OR windows on top when syncing the
window stack with the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=780485
To be able to render the pointer cursor sprite at sub-(logical)-pixel
positions, track the pointer position using floats instead of ints.
This also requires users of the cursor sprite rect to deal with
floating points, when e.g. finding the logical monitor etc.
https://bugzilla.gnome.org/show_bug.cgi?id=765011
When moving a window between two non-adjecent logical monitors, don't
try to tile a window when the window position is outside of any logical
monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=783630
When the number of (static) workspaces decreases, we relocate windows
from extra workspaces before removing them. As removing a non-empty
workspace is not allowed, we assert that it doesn't contain any windows
before removing it.
However that assert is
- pointless, because meta_workspace_remove() already asserts that
the workspace is empty
- wrong, because even empty workspaces contain windows that are set
to show on all workspaces
Simply drop the assert to avoid a crash when trying to remove a workspace
while on-all-workspaces windows are present.
https://bugzilla.gnome.org/show_bug.cgi?id=784223
While it doesn't make sense to set a window as transient to
itself, our existing check whether making a window transient
doesn't cover it, so it's still possible to create an infinite
loop.
https://bugzilla.gnome.org/show_bug.cgi?id=783502
For size change animations, plugins rely on the size change effect being
followed by size changed signal (or effects being kill altogether).
However unless the move_resize operation included the STATE_CHANGED flag,
the size changed event emitted when the compositor syncs the window
geometry only happens when the operation resulted in an actual change.
To avoid animations getting stuck in that case, make sure to include the
flag when tiling a window.
https://bugzilla.gnome.org/show_bug.cgi?id=783293
A single keysym can resolve to multiple keycodes. Instead of only using
the first one and ignoring the others, we store all codes in
MetaResolvedKeyCombo and then handle all of them in keybinding
resolution. If we already have bound a keycode for a keybinding with a
specific keysym then this can get overwritten by a new keybinding with a
different keysym that resolves to the same keycode. Now that we resolve
and bind all keycodes for a keysym this might happen more often; in that
case warn but still overwrite, but only for the first keycode for each
keysym. If a secondary (i.e. all non-first keycodes) is already indexed
we just ignore that; this should resemble the old behavior where we
only took the first keycode for any keysym as close as possible.
https://bugzilla.gnome.org/show_bug.cgi?id=781223
Call meta_compositor_size_change_window while tiling in order
to emit the size-change signal. Since the untiling action is
considered a unmaximize size change, treat tiling as a maximize
size change for consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=782968
When terminating mutter running as a display server, don't try to resize
maximized windows when unmanaging, as at this point, they will have no
MetaWaylandSurface. Originally this was done instead of setting the
net_wm_state to not mess with future window managers, but when we're a
Wayland compositor, this does not matter.
https://bugzilla.gnome.org/show_bug.cgi?id=782156
This is an interface that can be used to implement the "application
is not responding" dialog. One instance is created per window, which
is initially hidden, and can be shown/hidden on demand.
https://bugzilla.gnome.org/show_bug.cgi?id=711619
The UI scaling depends on whether the framebuffers are scaled. Enable
the caller to determine the what scale its UI should be drawn in, in
relation to the stage coordinate space by calling this function. A new
singal "ui-scaling-factor-changed" is added in order to liston for for
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
This commit adds support for rendering onto enlarged per logical
monitor framebuffers, using the scaled clutter stage views, for HiDPI
enabled logical monitors.
This works by scaling the mode of the monitors in a logical monitors by
the scale, no longer relying on scaling the window actors and window
geometry for making windows have the correct size on HiDPI monitors.
It is disabled by default, as in automatically created configurations
will still use the old mode. This is partly because Xwayland clients
will not yet work good enough to make it feasible.
To enable, add the 'scale-monitor-framebuffer' keyword to the
org.gnome.mutter.experimental-features gsettings array.
It is still possible to specify the mode via the new D-Bus API, which
has been adapted.
The adaptations to the D-Bus API means the caller need to be aware of
how to position logical monitors on the stage grid. This depends on the
'layout-mode' property that is used (see the DisplayConfig D-Bus
documentation).
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Logical monitors in a configuration must be adjecent to each other,
meaning there will be at least one pixel long side touching some other
logical monitor.
The exception to this is when there is only one logical monitor, which
cannot be adjecent to any other.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
When a state changed, e.g. a window went from unfullscreen to
fullscreen, always sync the window geometry, otherwise a compositor
application (e.g. gnome-shell) might end up with an unfinished window
state transition effect.
Without always syncing, the compositor plugin will see a 'size-change'
event, as a result of the state change, but if the size didn't change,
it would never see the 'size-changed' event. If an effect, for example
gnome-shell's fullscreen effect, is triggered on 'size-change' it might
rely on the actual size change to not get stuck. This commit allows it
to have this dependency.
This fixes a bug where a fullscreen effect gets "stuck" when a window
goes fullscreen without changing the window geometry.
https://bugzilla.gnome.org/show_bug.cgi?id=780292
Wayland windows can be zero sized until clients attach a buffer, but
our rectangle code doesn't deal with this case well, in particular,
meta_screen_get_monitor_for_rect() might end up choosing the wrong
monitor for a zero sized rectangle since
meta_rectangle_contains_rect() considers a zero sized rectangle at the
right or bottom edges of another rectangle (the monitor's) to be
contained there.
Since out size limits constraint will enforce a minimum size of 1x1,
we might as well enforce that when setting up the constraint info so
that the correct monitor gets chosen and the single monitor constraint
doesn't move these windows to the wrong one.
https://bugzilla.gnome.org/show_bug.cgi?id=772525
Wayland windows are initially zero sized until clients commit the
first buffer. Despite being invisible, clients are allowed to request
such windows to be fullscreened on a specific output before they
attach the first buffer which means we need to be able to move them.
meta_window_move_to_monitor() doesn't handle this case because these
windows' initial monitor is a placeholder since their initial
coordinates are 0,0+0+0, which results in us using a rectangle as
old_area for meta_window_move_between_rects() that might be to the "right"
of the window causing the move to go further out of the visible
screen's coordinates. This is later "corrected" by the constraints
system but the window might end up in the wrong monitor.
To fix this, we can make meta_window_move_between_rects() accept a
NULL old_area, meaning that we move the window to the new_area without
trying to keep a relative position.
https://bugzilla.gnome.org/show_bug.cgi?id=772525
The reason for the display to be closed may be meta_screen_new()
returning NULL, in which case we don't have a screen to free.
Avoid a segfault on exit by adding a proper check.
https://bugzilla.gnome.org/show_bug.cgi?id=778831
Split up the X11 backend into two parts, one for running as a
Compositing Manager, and one for running as a nested Wayland
compositor.
This commit also cleans up the compositor configuration calculation,
attempting to make it more approachable.
https://bugzilla.gnome.org/show_bug.cgi?id=777800
This signal provides the necessary information to let gnome-shell trigger
updates of pad leds/oleds whenever a pad group switches mode, and the
actions associated to buttons do too.
https://bugzilla.gnome.org/show_bug.cgi?id=776543
And add specific private methods to notify about tablet mapping and mode
switches. The signal allows the mutter side to trigger OSDs in a generic
way.
https://bugzilla.gnome.org/show_bug.cgi?id=771098
As all the relevant backends are expected to provide
ClutterPadButtonEvents, it makes no sense to split the information,
plus all other event fields are now available and might be needed
in the future.
https://bugzilla.gnome.org/show_bug.cgi?id=771098
Function "handle_raise_or_lower (src/core/keybindings.c)" is called
when running 'raise-or-lower' on a window. This function iterates
through all the windows in the stack to determine if our window is
already on top or obscured. The problem is that the window stack
includes windows in another workspaces and also windows that are
minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=705200
Add private API for overriding the compositor configuration, i.e. the
compositor type (X11 WM or Wayland compositor) and backend type. This
will make it possible to add a special test backend used by src/tests/.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Put the monitor xinerama index in a separate struct that is attached to
the logical monitor using g_object_set/get_qdata(). Eventually this
should be moved to some "X11 window manager" object, but lets keep it
in MetaScreen until we have such a thing.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Don't store logical monitor specific state in an array where the index
from the monitor manager is used as index locally. Instead just use
table associating a logical monitor with a monitor specific state
holder, and store the state in there. This way we don't have the
workspace implementation relying on implementation details of other
units.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of storing the logical monitors in an array and having users
either look up them in the array given an index or iterate using
indices, put it in a GList, and use GList iterators when iterating and
alternative API where array indices were previously used.
This allows for more liberty regarding the type of the logical monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Rewrite check_fullscreen_func to not use indexes (and
offset-index-as-pointer) tricks. This also removes the usage of an API
constructing temporary logical monitor arrays carrying indices.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Move the last piece of monitor grid getter API to the monitor manager
away from MetaScreen. The public facing API are still there, but are
thin wrappers around the MetaMonitorManager API.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The method used for getting the current logical monitor (the monitor
where the pointer cursor is currently at) depends on the backend type,
so move that logic to the corresponding backends.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Turning a rectangle into a logical monitor also has nothing to do with
the screen (MetaScreen) so move it to MetaMonitorManager which has that
information.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Let the backend initialize the cursor tracker, and change all call
sites to get the cursor tracker from the backend instead of from the
screen. It wasn't associated with the screen anyway, so the API was
missleading.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
Instead of keeping around array indexes, keep track of them by storing
a pointer instead. This also changes from using an array (imitating the
X11 behaviour) to more explicit storing.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
To complement the current API which takes an index referencing a
logical monitor in the logical monitor array, add API that takes a
direct reference to the logical monitor itself. The intention is to
replace the usage of the index based API with one that doesn't rely on
internal implementation details.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
It was just pointer to the actual list; having to synchronize a list of
logical monitors with the actual monitors managed by the backend is
unnecessary.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
The fullscreen monitors state is set given a set of xinerama monitor
identification numbers. When the monitor configuration changes (e.g. by
a hotplug event) these are no longer valid, and may point to
uninitialized or unallocated data. Avoid accessing
uninitialized/unallocated memory by clearing the fullscreen monitor
state when the monitor configuration changes.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
In preparation for further refactorizations, rename the MetaMonitorInfo
struct to MetaLogicalMonitor. Eventually, part of MetaLogicalMonitor
will be split into a MetaMonitor type.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We currently only focus unfocused windows on button press if no
modifiers (or just ignored modifiers) are in effect. This behavior
seems surprising and counter-intuitive so let's do it for any modifier
combination instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746642
There's no reason to keep this ~15 year old piece of code around as
well as the preference handling that would only make sense if this
hunk was actually enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=746642
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
