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
