Commit Graph

162 Commits

Author SHA1 Message Date
Olivier Fourdan
10796e6726 window/x11: Add flag to thaw commits after resize
To be able to thaw commits following a resize that might have frozen
commits, to keep freezes and thaws even, we need a way to tell whether
a repaint should also thaw commits.

Add a flag to `MetaWindowX11` and the appropriate functions to set and
query it.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
2020-01-16 09:22:25 +01:00
Olivier Fourdan
845157c111 window/x11: Add freeze_commits()/thaw_commits()
Xwayland may post damages for an X11 window as soon as the frame
callback is triggered, while the X11 window manager/compositor has not
yet finished updating the windows.

If Xwayland becomes compliant enough to not permit updates after the
buffer has been committed (see [1]), then the partial redraw of the X11
window at the time it was posted will show on screen.

To avoid that issue, the X11 window manager can use the X11 property
`_XWAYLAND_ALLOW_COMMITS` to control when Xwayland should be allowed to
post the pending damages.

Add `freeze_commits()` and `thaw_commits()` methods to `MetaWindowX11`
which are a no-op on plain X11, but sets `_XWAYLAND_ALLOW_COMMITS` on
the toplevel X11 windows running on Xwayland.

[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
See-also: https://gitlab.gnome.org/GNOME/mutter/merge_requests/855

https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
2020-01-16 09:22:25 +01:00
Ray Strode
bac188b568 window: Always disarm XSYNC watchdog when X client responds
At the moment we only disarm the watchdog timer set up for SYNC counter
requests if we're in the middle of a resize operation.

It's possible that the resize operation finished prematurely by the user
letting go of the mouse before the client responded.  If that happens, when the
client finally updates mutter will erroneously still have the watchdog timer
engaged from before until it times out, leading to resizes for the next second
or so to not get processed, and the client to get blacklisted from future sync
requests.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/942
2020-01-16 09:22:25 +01:00
Jonas Ådahl
6e5ac0b585 Use G_GNUC_FALLTHROUGH instead of comments
Get the same task done in a bit more C:y way.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/998
2020-01-09 17:58:29 +01:00
Florian Müllner
c843102eec stack: Delegate layer calculation to a window vfunc
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
2019-11-29 15:14:38 +01:00
Robert Mader
8e172aeecb cleanup: Use g_clear_handle_id() for g_source_remove()
It makes sure we do not forget to zero the id and lets us avoid
zero checks before. We use it for all new code, lets clean up the
existing code base.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/947
2019-11-22 01:27:40 +01:00
Robert Mader
92375c75f8 cleanup: Use g_clear_signal_handler() where possible
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.

A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.

No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
2019-11-21 15:02:27 +00:00
Jonas Ådahl
c474ad6a53 Stop including core.h where it's not used
It provides glue for window frame controls and internal window
management, and that is only relevant for a couple of places in src/ui/.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/854
2019-10-15 07:17:29 +00:00
Hans de Goede
fa461525ee window-x11: Refactor meta_prop_get_latin1_string() calls
Instead of storing the result of meta_prop_get_latin1_string() into
a temporary string value, g_strdup-ing that temp value storing the
g_strdup result into window->sm_client_id and then g_free-ing the
temporary string, we can pass window->sm_client_id as the place where
meta_prop_get_latin1_string() stores its result, since the result
from meta_prop_get_latin1_string() is itself a g_strdup-ed string,
so there is no need to g_strdup it again.

Note this drops the check to only issue the
"Window %s sets SM_CLIENT_ID on itself ..." warning once. This check is
not necessary as update_sm_hints() is only called once at window
creation time and is never called again.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
e2330617ac xprops: Free latin1/utf8_string_from_results() return value with g_free()
latin1_string_from_results and utf8_string_from_results use g_strndup,
so the returned string should be freed with g_free, rather then with
free or XFree. This fixes all free-s of buffers returned by these 2
functions to properly use g_free.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Hans de Goede
5eaf655224 xprops: Free meta_prop_get_cardinal_list() return value with g_free()
meta_prop_get_cardinal_list directly passes through the results->prop
pointer which is g_malloc memory, so we should free the buffer it
returns with g_free.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/786
2019-10-03 17:20:54 +00:00
Marco Trevisan (Treviño)
5ca0ef078d window-x11: Focus a window in the active workspace as take-focus fallback
Starting with commit 2db94e2e we try to focus a fallback default focus window
if no take-focus window candidate gets the input focus when we request it and
we limit the focus candidates to the current window's workspace.

However, if the window is unmanaging, the workspace might be unset, and we could
end up in deferencing a NULL pointer causing a crash.

So, in case the window's workspace is unset, just use the currently active
workspace for the display.

Closes https://gitlab.gnome.org/GNOME/mutter/issues/687

https://gitlab.gnome.org/GNOME/mutter/merge_requests/688
2019-07-18 10:09:45 +02:00
Marco Trevisan (Treviño)
6d8293a422 window-x11: Use any focusable window as fallback delayed focus window
As per commit f71151a5 we focus an input window if no take-focus-window accepts
it. This might lead to an infinite loop if there are various focusable but
non-input windows in the stack.

When the current focus window is unmanaging and we're trying to focus a
WM_TAKE_FOCUS window, we intent to give the focus to the first focusable input
window in the stack.

However, if an application (such as the Java ones) only uses non-input
WM_TAKE_FOCUS windows, are not requesting these ones to get the focus. This
might lead to a state where no window is focused, or a wrong one is.

So, instead of only focus the first eventually input window available, try to
request to all the take-focus windows that are in the stack between the
destroyed one and the first input one to acquire the input focus.
Use a queue to keep track of those windows, that is passed around stealing
ownership, while we protect for unmanaged queued windows.

Also, reduce the default timeout value, as the previous one might lead to an
excessive long wait.

Added metatests verifying these situations.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
2019-07-08 11:46:52 +02:00
Marco Trevisan (Treviño)
c327b2df95 window-x11: Accept any focusable window as fallback focus
As per commit f71151a5 we were ignoring WM_TAKE_FOCUS-only windows as focus
targets, however this might end-up in an infinite loop if there are multiple
non-input windows stacked.

So, accept any focusable window as fallback focus target even if it's a
take-focus one (that might not reply to the request).

Added a stacking test to verify this.

Closes: https://gitlab.gnome.org/GNOME/mutter/issues/660
https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
2019-07-08 11:21:17 +02:00
Marco Trevisan (Treviño)
9aee47daa9 window-x11: Don't double-check for unmanaging windows
When looking for the best fallback focus window, we ignore it if it is in the
unmanaging state, but meta_stack_get_default_focus_window() does this is check
for us already.

So, ignore the redundant test.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/669
2019-07-08 11:21:17 +02:00
Florian Müllner
feb9d129db window-x11: Fix typo 2019-06-24 19:33:30 +02:00
Marco Trevisan (Treviño)
f71151a5dd window-x11: Focus the default window with delay while waiting for take-focus
When requesting to a take-focus window to acquire the input, the client may or
may not respond with a SetInputFocus (this doesn't happen for no-input gtk
windows in fact [to be fixed there too]), in such case we were unsetting the
focus while waiting the reply.

In case the client won't respond, we wait for a small delay (set to 250 ms) for
the take-focus window to grab the input focus before setting it to the default
window.

Added a test for this behavior and for the case in which a window takes the
focus meanwhile we're waiting to focus the default window.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/307
2019-06-24 09:42:07 +00:00
Carlos Garnacho
86de79cfc5 core: Untangle input focus management
In all places (including src/wayland) we tap into meta_x11_display* focus
API, which then calls meta_display* API. This relation is backwards, so
rework input focus management so it's the other way around.

We now have high-level meta_display_(un)set_input_focus functions, which
perform the backend-independent maintenance, and calls into the X11
functions where relevant. These functions are what callers should use.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
2019-05-24 15:30:31 +00:00
Carlos Garnacho
5e0523cc8b x11: Move X11 calls to map/unmap a MetaWindow to MetaWindowX11
Add 2 vmethods so that MetaWindowX11 may handle the X11 calls itself.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/420
2019-05-24 15:30:31 +00:00
Marco Trevisan (Treviño)
f7ecf3b618 meta: Remove meta_free_gslist_and_elements
This function was added for historic reasons, before that we had GSlist's
free_full function.

Since this can be now easily implemented with a function call and an explicit
GDestroyFunc, while no known dependency uses it let's move to use
g_slist_free_func instead.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/57
2019-05-15 14:49:56 -05:00
Marco Trevisan (Treviño)
f798912cbd window: Move can_ping to a function and implement in X11
https://gitlab.gnome.org/GNOME/mutter/merge_requests/421
2019-02-13 02:07:41 +00:00
Marco Trevisan (Treviño)
3bf80a967c window-x11: Move delete_window to MetaWindowX11Private
https://gitlab.gnome.org/GNOME/mutter/merge_requests/421
2019-02-13 02:07:41 +00:00
Marco Trevisan (Treviño)
6c3b0cfc36 window-x11: Move take_focus to MetaWindowX11Private
https://gitlab.gnome.org/GNOME/mutter/merge_requests/421
2019-02-13 02:07:41 +00:00
Marco Trevisan (Treviño)
43633d6b2f window: Add is_focusable class method
Implement is_focusable for both x11 and wayland and just use this check
so that we can abstract things more and be less dependent on window backend.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/421
2019-02-13 02:07:41 +00:00
Florian Müllner
d5a7bbd094 Fix builds with G_DISABLE_ASSERT
Commit 25f416c13d added additional compilation warnings, including
-Werror=return-type. There are several places where this results
in build failures if `g_assert_not_reached()` is disabled at compile
time and the compiler misses a return value.

https://gitlab.gnome.org/GNOME/mutter/issues/447
2019-01-25 09:43:06 +01:00
Florian Müllner
6e1b14b26b x11: Remove hide-titlebar-when-maximized support
It's a UI pattern that has been superseded by client-side decorations,
apps that used to set the hint have generally moved on to headerbars.
Given that and the limitation to server-side decorated X11 windows,
GTK4 removed the client-side API for setting the hint, it's time to
follow suite and retire the feature.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/221
2018-11-26 13:12:18 +00:00
Jonas Ådahl
787bb4316d x11/window: Minor cleanup
Limit the scope of the 'monitor_rect' variable and break up a long line.

https://bugzilla.gnome.org/show_bug.cgi?id=790207
2018-11-14 16:04:10 +01:00
Jonas Ådahl
640a04d0e4 window: Make edge constraint code more readable
It relied on indices in arrays determining tile direction and
non-obvious bitmask logic to translate to _GTK_EDGE_CONSTRAINTS. Change
this to explicitly named edge constraints, and clear translation methods
that converts between mutters and GTK+s edge constraint formats.
2018-11-08 13:21:21 +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
e2e7296612 window: Move out 'updates frozen' state into implementations
Implementation of said state was just related to X11, so move it into
window-x11.c. The Wayland path always fell back on the returning TRUE,
so just do that for now.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/229
2018-09-19 15:39:54 +00:00
Jonas Ådahl
f4d07caa38 window: Pass flag to meta_window_update_monitor() instead of bool
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
2018-08-27 08:33:00 +00:00
Armin Krezović
81c1c70c0a Move workspace related code from MetaDisplay to MetaWorkspaceManager
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:17 +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ć
e8171ccdc1 Use MetaMonitorManager insted of MetaDisplay where possible
This drops display's monitors-changed signal and makes all
the code rely on MetaMonitorManager.

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:17 +02:00
Armin Krezović
1d5e37050d Stop using MetaScreen where it is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
b7c3dada81 Move workspace handling to MetaDisplay and MetaX11Display
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
82307dd694 Move xinerama management to MetaX11Display
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
e1c67a1824 Move monitor management API to MetaDisplay
This includes changing various users to use MetaDisplay directly, who
used MetaScreen only for this before.

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
68f261e8e2 Move rest of non-X11 specific objects from MetaScreen
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
2018-07-06 19:47:16 +02:00
Armin Krezović
1530f27513 Move X11 event, icon cache and property handling to MetaX11Display
https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
05899596d1 Move X11 helper windows and xprops to MetaX11Display
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ć
cd8f4259be Move screen size and cursor setting to MetaDisplay
Split X11 specific parts into MetaX11Display. This also required
changing MetaScreen to stop listening to any signals by itself, but
instead relying on MetaDisplay forwarding them. This was to ensure the
ordering. MetaDisplay listens to both the internal and external
monitors-changed signal so that it can pass the external one via the
redundant MetaDisplay(prev MetaScreen)::monitors-changed.

https://bugzilla.gnome.org/show_bug.cgi?id=759538
2018-07-06 19:47:16 +02:00
Armin Krezović
c64d5ad8af Move X11 extension queries to MetaX11Display
Also split extension queries into their own functions

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
Georges Basile Stavracas Neto
822c2666f5 window: Let implementations finish state changes
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
2018-04-25 21:55:05 -03:00
Olivier Fourdan
19bf4cf4f8 x11: Do not discard shape region for undecorated windows
mutter would discard the shape region set by the client if its matches
the entire client area in meta_window_x11_update_shape_region().

However, if the window is later resized (maximized or other), the
compositor will fail to update the shape region properly for undecorated
windows because the shape region was discarded, which causes black areas
to appear in place of the updated areas.

If the client window is undecorated, keep the shape region even if when
it matches the client area.

https://gitlab.gnome.org/GNOME/mutter/issues/27

Closes: #27
2018-02-22 08:02:01 +00:00
Olivier Fourdan
97f142d1cc x11/window: Mark restored workspace as “set”
When a window's workspace is not NULL, on_all_workspace should be FALSE.
Similarly, when on_all_workspace is TRUE, the window workspace should be
NULL.

This is an assumption in multiple places in the code, including when
setting the workspace state, the window is either added or removed from
all workspaces only if the window's workspace is NULL.

This rule is initially enforced at creation in _meta_window_shared_new()
when a initial workspace is set. However, when the initial workspace is
set from the session info, the initial workspace is not marked as “set”
which leads to an assertion failure when unmanaging windows, because the
window is not removed from all the workspaces.

When applying the session info to a window, mark the workspace as “set”.

https://gitlab.gnome.org/GNOME/mutter/issues/4

Closes: #4
2018-01-30 10:08:58 +01:00