meta_window_(un)queue() was implemented with global arrays in window.c
that managed MetaLater handle IDs and lists of window queues. In order
to rely less on scattered static variables and making it clearer that
we're dealing with per display window management and not something
specific to a single window, move the window resize/calc-showing queue
management to MetaDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
Passing a NULL workspace does not make sense, since it silently
returns no windows. Mandate that a workspace is explicitly requested,
and while at it check the other arguments as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2124>
Used to log multiple line entries. Just make continue prefix things, no
need to mess with maybe-prefixing; it'll just complicate using some less
custom logging functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2094>
The stack and stack tracker tend to cause missed frames from time to
time, especially when there are many open windows. Add some
instrumentation to make it this easily verifiable when profiling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
This is so that cogl-trace.h can start using things from cogl-macros.h,
and so that it doesn't leak cogl-config.h into the world, while exposing
it to e.g. gnome-shell so that it can make use of it as well. There is
no practical reason why we shouldn't just include cogl-trace.h via
cogl.h as we do with everything else.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1059
While most of the code to compute a window's layer isn't explicitly
windowing backend specific, it is in practice: On wayland there are
no DESKTOP windows(*), docks(*) or groups.
Reflect that by introducing a calculate_layer() vfunc that computes
(and sets) a window's layer.
(*) they shall burn in hell, amen!
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
Most of the layer computation that the stack does actually depends
on the windowing backend, so we will move it to a vfunc.
However before we do that, split out the bit that will be shared.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/949
When a window that should be stacked above another one is placed in a lower
layer than the other window, we currently allow promoting it to the higher
layer when it has a "transient type". We should do the same when the window
is an actual transient of the other window.
This is particularly relevant for wayland windows, where types play a
much smaller role: Transient windows like non-modal dialogs (and since
commit 666bef7a, popup windows as well) currently end up underneath their
always-on-top parent.
https://gitlab.gnome.org/GNOME/mutter/issues/587
We indirectly were relying on the MetaX11Stack for this. We strictly
need the _NET_CLIENT_LIST* property updates there, so move our own
internal synchronization to common code.
Fixes stacking changes of windows while there's no MetaX11Display.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
This object takes care of the X11 representation of the window stack,
namely the _NET_CLIENT_LIST and _NET_CLIENT_LIST_STACKING root window
properties.
This code has been lifted from src/core/stack.c into src/x11 as it's
dependent on the X11 display availability. This also leaves MetaStack
squeaky clean of x11 specifics.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
As per commit 43633d6b, we mark an unmanaging window as not focusable, while
this is true, it might cause not resetting the current focused window when
unmanaging it causing a crash.
Also this wouldn't allow to check if a window can be focused when unmanaging it,
so let's revert the previous behavior.
Fixes: https://gitlab.gnome.org/GNOME/mutter/issues/462
Placing persistant Wayland popups (e.g. not menus etc) in the o-r layer
breaks stacking order with other window trees (e.g. other client
windows), as the menu would get stuck in the o-r layer, i.e. on top,
even if the parent of the popup got lowered.
Fix this by placing the popups in the normal layer, relying on
transient-ness to keep stacking correct.
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
This moves following objects from MetaScreen to MetaDisplay
- workareas_later and in_fullscreen_later signals and functions
- startup_sequences signals and functions
- tile_preview functions
https://bugzilla.gnome.org/show_bug.cgi?id=759538
- Moved xdisplay, name and various atoms from MetaDisplay
- Moved xroot, screen_name, default_depth and default_xvisual
from MetaScreen
- Moved some X11 specific functions from screen.c and display.c
to meta-x11-display.c
https://bugzilla.gnome.org/show_bug.cgi?id=759538
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
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
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
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
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.
The main monitor of a window is maintained as 'window->monitor' and is
updated when the window is resized or moved. Lets avoid calculating it
every time it`s needed.
https://bugzilla.gnome.org/show_bug.cgi?id=744934
The only time we ever execute this code is when we're minimizing or
hiding a window, in which case we should respect stacking order.
This fixes weird "bugs" where windows from the same app magically pop up
over other windows.
A window may be hidden even if not minimized itself, for instance
when an ancestor is minimized. As meta_window_focus() will refuse
to actually focus the window in that case, don't pick it in the first
place.
https://bugzilla.gnome.org/show_bug.cgi?id=751715
With the change to how hidden windows are stacked, the position
of the guard window with respect to the hidden windows got flipped
and the guard window was at the bottom of everything; fix it to
be on top of the hidden windows.
https://bugzilla.gnome.org/show_bug.cgi?id=737233
Restacking the frame for a window while unmanaging the window is
harmless, but for undecorated (in particular, client-side-decorated)
windows, this causes problems because the window is typically
destroyed by the client immediately after withredrawing the window.
Skip windows flagged as being unmanaged when assembling the new
stack and when comparing the old order to the new stack.
Add a stacking test for this.
