Commit Graph

60 Commits

Author SHA1 Message Date
Barnabás Pőcze
d6b3679bd3 core: Subscribe to stack changes in the stack-tracker
This removes the implicit dependency on `display->stack_tracker`
existing and being valid in `on_stack_changed()` because
now it is the stack-tracker's responsibility to subscribe
to the "changed" signal of the stack and handle the changes.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3202>
2023-09-03 23:31:37 +02:00
Bilal Elmoussaoui
d44f02ba64 mutter: Cleanup gi-docgen annotations
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2939>
2023-05-22 15:47:37 +00:00
Jonas Ådahl
4b3cab2cca compositor: Don't make internal API public
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.

MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.

So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
2022-12-17 15:13:48 +01:00
Jonas Ådahl
dd2beae6a8 core: Setup and use ownership chains
As with other parts, make objects have the ability to walk up the
ownership chain to the context, to get things like the Wayland
compositor or backend instances.

Contains these squashed commits:

display: Don't get backend from singleton

window: Don't get backend from singleton

keybindings: Don't get backend from singleton

workspace: Don't get backend from singleton

display: Don't get Wayland compositor from singleton

selection: Add display getter

context/main: Get backend directly from the context

clipboard-manager: Don't get display from singleton

stack-tracker: Don't use singleton MetaLater API

startup-notification: Hook up sequences and activations to display

This allows using context aware API directly.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
2022-12-17 15:13:48 +01:00
Jonas Ådahl
8c8bbb8008 util: Remove push/pop no msg prefix logging
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>
2021-11-21 20:53:33 +00:00
Robert Mader
6eeeffdc68 src: Stop using GSlice
It has been inofficially deprecated for years, is known to cause issues
with valgrind and potentially hides memory corruption.
Lets stop using it.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1512>
2021-02-22 13:52:27 +01:00
Jonas Ådahl
48a90e3a86 stack: Add some trace instrumentation
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>
2020-12-01 11:41:11 +00:00
Jonas Ådahl
313e3e771c Make meta_* logging utilities not require line break
Unlike g_* logging utilities, the meta_* counterparts behave like odd
printf() functions. Lets change that so they fit better into how logging
is done everywhere else.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1466
2020-10-08 16:38:41 +02:00
Jonas Ådahl
53f61f3778 stack-tracker: Don't log warnings on race conditions
X11 window stacking operations are by nature prone to race conditions.
For example, we might queue a "raise above" operation, but before it
actually takes place, the sibling the window was to be rased above, is
withdrawn.

In these cases we'd log warnings even though they are expected to
happen. Downgrade these warnings to debug messages, only printed when
MUTTER_VERBOSE is set.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
2020-06-09 18:46:38 +00:00
Jonas Ådahl
74c0d9140c stack-tracker: Fix coding style of meta_stack_op_apply()
Change tabs to spaces, clean up variable declarations.

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
2020-06-09 18:46:38 +00:00
Carlos Garnacho
850ef51879 core: Split x11-display initialization in 2 signals
We have a "setup" phase, used internally to initialize early the x11
side of things like the stack tracker, and an "opened" phase where
other upper parts may hook up to. This latter phase is delayed during
initialization so the upper parts have a change to connect to on
plugin creation.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/771
2019-09-11 22:30:13 +02:00
Carlos Garnacho
78232fa3eb core: Check X11 display availability before use in MetaStackTracker
This object can be generally triggered without a X11 display, so make sure
this is alright. For guard window checks, use our internal
meta_stack_tracker_is_guard_window() call, which is already no-x11 aware.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/730
2019-08-26 17:39:10 +00:00
Carlos Garnacho
ca51cd8488 core: Prepare MetaStackTracker for X11 display being closed
If the display is closed prematurely, go through all windows that
look X11-y and remove them for future calculations. This is not
strictly needed as Xwayland should shut down orderly (thus no client
windows be there), but doesn't hurt to prepare in advance for the
cases where it might not be the case.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-08-06 00:41:36 +00:00
Niels De Graef
1c6ea5d1db Use a consistent style for enum braces
https://gitlab.gnome.org/GNOME/mutter/merge_requests/361
2019-02-28 09:31:01 +01:00
Jonas Ådahl
a97cc84b81 Fix warnings when building without verbose mode 2018-11-06 17:17:36 +01:00
Jonas Ådahl
2f4a68c8c3 Clean up include macros mess
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.
2018-11-06 17:17:36 +01:00
Jonas Ådahl
356cad094b stack-tracker: Don't sort O-R's under guard window on top
As of "stack-tracker: Keep override redirect windows on top"
(e3d5bc077d), we always sorted all
override redirect on top of regular windows, as so is expected by
regular override redirect windows. This had an unwanted consequence,
however, which is that we should still not sort such override redirect
windows on top if they are behind the guard window, as that'd result in
windows hidden behind it now getting restacked anyway.

Fix this by only sorting the override redirect windows that are found
above the guard window on top. This fixes the override-redirect stacking
test.
2018-07-17 16:30:18 +02:00
Armin Krezović
390314adfb Rename errors.[ch] to meta-x11-errors.[ch]
Also rename meta_error_trap_* to meta_x11_error_trap_* and
move meta-x11-errors.c to src/x11

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:17 +02:00
Armin Krezović
e6b885210c Make stack tracker work without X11
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
98d912ba5f Move stack tracking and guard_window outside of MetaScreen
Move stack, stack_tracker to MetaDisplay guard_window to MetaX11Display

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
722c975aca Move alarm and xids management to MetaX11Display
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
dacc041d0c Switch meta_error_trap functions to MetaX11Display
They are X11 specific functions, used for X11 code. They have been
improved per jadahl's suggestion to use gdk_x11_lookup_xdisplay and
gdk_x11_display_error_trap_* functions, instead of current code.

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
18779109de Start populating MetaX11Display
- 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
2018-07-06 19:47:16 +02:00
Rui Matos
e3d5bc077d stack-tracker: Keep override redirect windows on top
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
2017-07-14 15:30:57 +02:00
Jonas Ådahl
cd225c4e19 Always use the default screen
GDK doesn't support multiple screens, so effectively we don't either.
Lets stop pretending we do.

This fixes a few -Wdeprecated warnings.

https://bugzilla.gnome.org/show_bug.cgi?id=769070
2016-07-23 10:55:02 +08:00
Owen W. Taylor
21f123c69f Don't restack windows while we are unmanaging them
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.
2014-09-16 13:44:42 -04:00
Jasper St. Pierre
a676249c0c stack-tracker: Fix an off-by-one error in restack_managed
When restacking the last window alone, we would trigger this off-by-one
error. This would throw us off the end of the array, causing lower_below
warnings for nonsensical values.

Since the last window already is lowered below everything else, we
shouldn't need to lower it.
2014-09-12 17:10:34 -06:00
Jasper St. Pierre
2833c702c6 stack-tracker: Make lower_below / raise_above internal as well
These are unused elsewhere.
2014-09-12 16:56:27 -06:00
Owen W. Taylor
f163a15b13 MetaStackTracker: optimize out unnecessary X restacking
We have a quite accurate view of the X stack, so there's no good reason to ask
the X server to do restacking that has no effect. (Restackings that have no
effect on either X windows or Wayland windows were generally optimized out in
the synchronization code, but in other cases like moving an X window that is
only beneath Wayland windows to the top of the stack we would make such
requests.)

Removing such requests:
 - Is a small efficiency win in itself
 - Allows us to immediately go ahead and apply Wayland changes to the verified stack
 - Prevents queued Wayland changes piling up waiting for an X event that will never
   be received, since the X server will not send confirmation of no-op restacks.

Since such operations may still have an effect on the relative stacking of X
and Wayland windows, we need to continue applying them to the local stack.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
87779ed34e MetaStackTracker: make functions used only internally static
Now that all actual stack shuffle is handled inside stack-tracker.c, we can make
meta_stack_tracker_record_[raise_above/lower_below] internal to that file and
remove the unused meta_stack_tracker_record_lower().

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
04bc846ef3 Move logic for syncing the stack to the X server into MetaStackTracker
stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and
code for enforcing the desired stack on the actual stack of X and Wayland windows;
the latter part is properly the domain of stack-tracker.c; moving the code to
apply the stack there both simplifies it and keeps stack.c more manageable.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
3457366066 Move manipulation of the X stack to MetaStackTracker
Since MetaStackTracker is the code that knows about the current X stacking order
and the relationship between X windows and Wayland windows, it's cleaner to
encapsulate stack manipulation in MetaStackTracker rather than have the calling
code make the X calls and only call into MetaStackTracker to inform it about
the changes.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
cb66cf6398 MetaStackTracker: eliminate the resynchronization process
The step where we requery the stacking order from the server than combine
it in an arbitrary fashion with Wayland windows can be eliminated by observing
that we are the final authority for Wayland window stacking - so if we
apply each X event that we receive from the X server to our stack in a
way that leaves the X windows ordered in the same way as on the server,
and apply events that we have stored locally in a way that doesn't affect
the ordering of X windows, than we have a fully correct ordering of windows.

Ordering this in the order of first applying the X event and then applying the
local portion also means that as long as we had an up-to-date view of the X
stack the composite operation will be identical to what was requested.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
73573a85de Replace MetaStackWindow with a 64-bit "stack ID"
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
2014-09-12 13:42:56 -04:00
Jasper St. Pierre
5f25ca0c3a stack-tracker: More small cleanups 2014-07-10 16:29:35 -04:00
Jasper St. Pierre
41b4a079c7 stack-tracker: Remove unused variable 2014-07-10 16:29:35 -04:00
Jasper St. Pierre
e4235376d8 stack-tracker: Add some more debug output 2014-07-10 16:29:34 -04:00
Jasper St. Pierre
043a201f90 stack-tracker: Clean up dumping 2014-07-10 16:29:18 -04:00
Jasper St. Pierre
d1a588a94f stack-tracker: Fix the case where the serial is too old
The code here before was just flat out wrong, and made us consistently
requery the server at startup.
2014-07-10 16:02:01 -04:00
Jasper St. Pierre
01b6d9bfe2 stack-tracker: Fix code style 2014-07-10 16:00:38 -04:00
Jasper St. Pierre
9711d95996 stack-tracker: Fix comments 2014-07-10 16:00:38 -04:00
Giovanni Campagna
098c8908ed MetaStackTracker: make sure all stack ops are freed eventually
If we apply a prediction immediately instead of queueing, we should
also free the operation immediately.
If we discard the prediction queue because we resync fully, we
need to free each operation too.

https://bugzilla.gnome.org/show_bug.cgi?id=729732
2014-05-07 19:04:54 +02:00
Jasper St. Pierre
25a16c3379 Remove trailing whitespace 2014-05-02 09:34:48 -04:00
Adel Gadllah
a378faf495 stack-tracker: Fix unitialized variable 2014-04-20 16:02:48 +02:00
Jasper St. Pierre
cd905a34fb compositor: Kill off MetaCompScreen
Compositors haven't been able to manage more than one screen for
quite a while. Merge MetaCompScreen into MetaCompositor, and update
the API to match.

We still keep MetaScreen in the public compositor API for compatibility
purposes.
2014-03-26 12:04:48 -04:00
Jasper St. Pierre
8b2b65246a Assume the compositor always exists
At one point, it was supported to run mutter without a compositor,
but we don't allow that any longer. A lot of code already assumes
display->compositor exists and doesn't check for a NULL pointer,
so just kill the rest of the checks.
2014-03-18 18:25:32 -04:00
Jasper St. Pierre
0be4622e14 stack-tracker: Comment out bad warning
It triggers too often, making G_DEBUG=fatal-warnings quite useless.
Owen is going to rewrite this code sometime in the near future, so
I'm just gonna kill this warning for now.
2014-02-24 09:46:22 -05:00
Andika Triwidada
9b21346427 Changed obsolete FSF postal address into generic URL.
Fix https://bugzilla.gnome.org/show_bug.cgi?id=721517 #2
2014-01-13 11:35:47 -05:00
Giovanni Campagna
b53bf0e8c2 Fix distcheck
Missing translation files, missing dists and some -Werrors.
2013-09-03 17:00:18 +02:00
Robert Bragg
40e820f551 Add support for stacking X and Wayland windows together
This breaks down the assumptions in stack-tracker.c and stack.c that
Mutter is only stacking X windows.

The stack tracker now tracks windows using a MetaStackWindow structure
which is a union with a type member so that X windows can be
distinguished from Wayland windows.

Some notable changes are:

Queued stack tracker operations that affect Wayland windows will not be
associated with an X serial number.

If an operation only affects a Wayland window and there are no queued
stack tracker operations ("unvalidated predictions") then the operation
is applied immediately since there is no server involved with changing
the stacking for Wayland windows.

The stack tracker can no longer respond to X events by turning them into
stack operations and discarding the predicted operations made prior to
that event because operations based on X events don't know anything
about the stacking of Wayland windows.

Instead of discarding old predictions the new approach is to trust the
predictions but whenever we receive an event from the server that
affects stacking we cross-reference with the predicted stack and check
for consistency. So e.g. if we have an event that says ADD window A then
we apply the predictions (up to the serial for that event) and verify
the predicted state includes a window A. Similarly if an event says
RAISE_ABOVE(B, C) we can apply the predictions (up to the serial for
that event) and verify that window B is above C.

If we ever receive spurious stacking events (with a serial older than we
would expect) or find an inconsistency (some things aren't possible to
predict from the compositor) then we hit a re-synchronization code-path
that will query the X server for the full stacking order and then use
that stack to walk through our combined stack and force the X windows to
match the just queried stack but avoiding disrupting the relative
stacking of Wayland windows. This will be relatively expensive but
shouldn't be hit for compositor initiated restacking operations where
our predictions should be accurate.

The code in core/stack.c that deals with synchronizing the window stack
with the X server had to be updated quite heavily. In general the patch
avoids changing the fundamental approach being used but most of the code
did need some amount of re-factoring to consider what re-stacking
operations actually involve X or not and when we need to restack X
windows we sometimes need to search for a suitable X sibling to restack
relative too since the closest siblings may be Wayland windows.
2013-08-10 19:13:49 -04:00