Changes in window decoration result in the window being reparented
in and out its frame. This in turn causes unmap/map events, and
XI_FocusOut if the window happened to be focused.
In order to preserve the focused window across the decoration change,
add a flag so that the focus may be restored on MapNotify.
Closes: #273
A window placed using a placement rule should keep that relative
position even if the parent window moves, as the position tied to the
parent window, not to the stage. Thus, if the parent window moves, the
child window should move with it.
In the implementation in this commit, the constraints engine is not
used when repositioning the children; the window is simply positioned
according to the effective placement rule that was derived from the
initial constraining, as the a xdg_popup at the moment cannot move
(relative its parent) after being mapped.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/274
Commit a3da4b8d5b changed updating of
window monitors to always use take affect when it was done from a
non-user operation. This could cause feed back loops when a non-user
driven operation would trigger the changing of a monitor, which itself
would trigger changing of the monitor again due to a window scale
change.
The reason for the change, was that when the window monitor changed due
to a hot plug, if it didn't actually change, eventually the window
monitor pointer would be pointing to freed memory.
Instead of force updating the monitor on all non-user operations, just
do it on hot plugs. This allows for the feedback loop preventing logic
to still do what its supposed to do, without risking dangling pointers
on hot plugs.
Related: https://gitlab.gnome.org/GNOME/mutter/issues/189
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/192
The bool determines whether the call was directly from a user operation
or not. To add more state into the call without having to add more
boolenas, change the boolean to a flag (so far with 'none' and 'user-op'
as possible values). No functional changes were made.
https://gitlab.gnome.org/GNOME/mutter/issues/192
In the old, synchronous X.org world, we could assume that
a state change always meant a synchronizing the window
geometry right after. After firing an operation that
would change the window state, such as maximizing or
tiling the window,
With Wayland, however, this is not valid anymore, since
Wayland is asynchronous. In this scenario, we call
meta_window_move_resize_internal() twice: when the user
executes an state-changing operation, and when the server
ACKs this operation. This breaks the previous assumptions,
and as a consequence, it breaks the GNOME Shell animations
in Wayland.
The solution is giving the MetaWindow control over the time
when the window geometry is synchronized with the compositor.
That is done by introducing a new result flag. Wayland asks
for a compositor sync after receiving an ACK from the server,
while X11 asks for it right away.
Fixes#78
When maximizing a window, the previous location is saved so that
un-maximize would restore the same original window location.
However, if a Wayland client starts with a window maximized, the
previous location will be 0x0, so if we have to force placement in
xdg_toplevel_set_maximized(), we should update the location as well so
that the window is placed on the right monitor when un-maximizing.
For that purpose, add a new flag to force the update of the window
location, and use that flag from xdg_toplevel_set_maximized().
https://bugzilla.gnome.org/show_bug.cgi?id=783901
Wayland clients know their size better, so for Wayland we'd rather not
try to resize the client on un-maximize, but for this to work we need a
new MetaMoveResizeFlags.
https://bugzilla.gnome.org/show_bug.cgi?id=783901
When closing a window and showing a new one, the new one may not be
granted input focus until it gets a buffer on Wayland.
If another window is chosen to receive focus and raised on top of stack,
the newly mapped window is focused but placed underneath that other
window.
Meaning that for Wayland surfaces, we need to defer adding the window to
the stack until we actually get to show it, once we have a buffer
attached.
Rather that checking the windowing backend prior to decide if a window
is stackable or not, introduce a new vfunc is_stackable() which tells
if a window should be added to the stack regardless of the underlying
windowing system.
Also add meta_window_is_in_stack() API rather than checking the stack
position directly (replacing the define WINDOW_IN_STACK only available
in stack.c) and remove a window from the stack only if it is present
in the stack, so that the test in meta_stack_remote() becomes
irrelevant.
https://bugzilla.gnome.org/show_bug.cgi?id=780820
GTK has the ability to handle client-decorated windows
in such a way that the behavior of these windows must
match the behavior of the current window manager.
In Mutter, windows can be tiled horizontally (and, in
the future, vertically as well), which comes with a few
requirements that the toolkit must supply. Tiled windows
have their borders' behavior changed depending on the
tiled position, and the toolkit must be aware of this
information in order to properly match the window manager
behavior.
In order to provide toolkits with more precise and general
data regarding resizable and constrained edges, this patch
makes MetaWindow track its own edge constraints.
This will later be used by the backends to send information
to the toolkit.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
Currently tiled windows are not resizable and their size is fixed
to half the screen width. Adjust the code to work with fractions
other than half, and allow users to adjust the split by dragging
the window edge that is not constrained by a monitor edge.
Follow-up patches will improve on that by resizing neighboring
tiled windows by a shared edge, and making the functionality
available to client-side decorated windows implementing the
new edge constraints protocol.
Now that the preview tile mode has been split from the window's
tile_mode property, it is much more natural to pass the requested
tile_mode to the tile() function instead of setting it externally
and calling the function to apply the state.
The existing semantics of the tile_mode property are terribly confusing,
as it depends on some other property whether it represents the requested
or current mode. Clear this up by just using separate variables for the
two. As it is unlikely that we will ever support more than one tile
preview, we can track the requested mode globally instead of adding
another per-window variable.
https://bugzilla.gnome.org/show_bug.cgi?id=645153
For now we abuse of meta_window_get_flatpak_id not to break the APIs,
so that it's working seamlessly in gnone shell too.
Rename flatpak_id to sandboxed_app_id internally to get prepared to the future
API.
https://bugzilla.gnome.org/show_bug.cgi?id=788217
Add a mechanism to MetaWaylandSurface that inhibits compositor's own
shortcuts when the surface has input focus, so that clients can receive
all key events regardless of the compositor own shortcuts.
This will help with implementing "fake" active grabs in Wayland and
XWayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=783342
When updating the main monitor, make sure to update the toplevel main
monitor before trying to use that as the main monitor for non-toplevel
windows (such as popups). Without this, when the main monitor is
updated as a side effect to monitors being changed (for example due to
a hot plug event, or coming back from being suspended) the
main monitor pointer may, after 'monitors-changed' has completed, point to
freed memory resulting in undefined behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=784867
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
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
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
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
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
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
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
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
The new tiling code, instead of based around "tiling states", is instead
based around constrained edges. This allows us to have windows that have
three constrained edges, but keep one free-floating, e.g. a window tiled
to the left has the left, top, and bottom edges constrained, but the
right edge can be left resizable.
This system also is easily extended to support corner tiling. We also,
using the new "size state" system, also keep normal, tiled, and
maximized sizes independently, allowing the maximize button to bounce
between maximized and tiled states without reverting to normal in
between. Dragging from the top will always restore the normal state,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
This was introduced in commit c6793d477a
to prevent window self-maximisation. It turns out that that bug seems
to have been fixed meanwhile in a different way since the reproducer
in https://bugzilla.gnome.org/show_bug.cgi?id=461927#c37 now works
fine with this special handling removed.
In fact, failing to set window->fullscreen immediately when loading
the initial set of X properties causes us to create a UI frame for a
window that sets _NET_WM_STATE_FULLSCREEN.
This, in turn, might cause the fullscreen constrain code to fail if
the window also sets min_width/min_height size hints to be the monitor
size since the UI frame size added to those makes the rectangle too
big to fit the monitor. If the window doesn't set these hints, we
fullscreen it but the window will get sized such that the UI frame is
taken into account while it really shouldn't (see the reproducer
above).
https://bugzilla.gnome.org/show_bug.cgi?id=753020
Since we scale surface actors given what main output their toplevel
window is on, also scale the window geometry coordinates and sizes
(window->rect size and window->custom_frame_extents.top/left) in order
to make the window geometry represent what is being rendered on the
stage.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
A much less hacky version of maximize / unmaximize is reimplemented
in terms of this, but it could also eventually be used for fullscreen /
unfullscreen, and tile / untile.
window->is_alive isn't initialized explicitly so it defaults to FALSE
meaning that if the first ping fails we'd short circuit and not show
the delete dialog as we should.
We could initialize the variable to TRUE but in fact we don't even
need the variable at all since our dialog management is enough to
manage all the state we need, i.e. we're only interested in knowing
whether we're already displaying a delete dialog.
This does change our behavior here since previously we wouldn't
display the dialog again if the next ping failed after the dialog is
dismissed but this was arguably a bug too since in that case there
wouldn't be a way to kill the window after waiting for a while and the
window kept being unresponsive.
https://bugzilla.gnome.org/show_bug.cgi?id=749711
In order to switch to the correct surface actor scale given the monitor
the surface is on, without relying on the client committing a new state
given some other side effect, sync the surface actor state when the main
monitor associated with the corresponding window changed.
https://bugzilla.gnome.org/show_bug.cgi?id=744933
Putting X windows and pointers to MetaWindows into a union had a number of
problems:
- It caused awkward initialization and conditionalization
- There was no way to refer to Wayland windows (represented by
MetaWindow *) in the past, which is necessary for the MetaStackTracker
algorithms
- We never even cleaned up old MetaStackWindow so there could be
records in MetaStackWindow pointing to freed MetaWindow.
Replace MetaStackWindow with a 64-bit "stack ID" which is:
- The XID for X Windows
- a "window stamp" for Wayland windows - window stamps are assigned
for all MetaWindow and are unique across the life of the process.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
