1
0
Fork 0
Commit graph

72 commits

Author SHA1 Message Date
Rémi Bernon
8f242f8bf0 core: Fix multiple reparent requests handling
If window decoration is modified within a short period of time, mutter
sometimes starts processing the second request before the first
UnmapNotify event has been received. In this situation, it considers
that the window is not mapped and does not expect another UnmapNotify /
MapNotify event sequence to happen.

This adds a separate counter to keep track of the pending reparents. The
input focus is then restored when MapNotify event is received iff all
the expected pending ReparentNotify events have been received.

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>

https://gitlab.gnome.org/GNOME/mutter/merge_requests/657
2019-09-02 15:50:37 +00:00
Carlos Garnacho
0c5866a9e1 core: Avoid queueing a stack operation on the frame when the X11 is closing
When rushing to unmanage X11 windows after the X11 connection is closed/ing,
this would succeed at creating a stack operation for no longer known windows.
Simply avoid to queue a stack operation if we know it's meaningless.

https://gitlab.gnome.org/GNOME/mutter/merge_requests/709
2019-08-06 00:41:36 +00:00
Florian Müllner
7bd33e7b00 frame: Remove flashing support
It's now unused.

https://gitlab.gnome.org/GNOME/mutter/issues/491
2019-03-12 00:27:07 +00:00
Florian Müllner
de76074336 ui: Remove fallback app menu
The app menu is in the process of being retired[0], and the shell
stopped displaying it while applications are in the process of
dropping it. It therefore doesn't make sense to always show a
fallback menu in server-side decorations, applications that still
set the menu can rely on GTK+'s own fallback instead.

[0] https://gitlab.gnome.org/GNOME/Initiatives/wikis/App-Menu-Retirement

https://gitlab.gnome.org/GNOME/gnome-shell/issues/624
2019-01-30 18:39:42 +00: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
Carlos Garnacho
8dcac664fa core: Preserve focus across decoration changes
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
2018-09-24 13:44:53 +00: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ć
d79ffd3976 Move UI and key grabs 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ć
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
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
Florian Müllner
46eb682c83 Revert "window: Remove old tiling code"
This reverts commit 8bded7d497.
2016-01-10 15:16:09 +01:00
Florian Müllner
8071e5b149 Revert "frame: Don't allow resizing of edges that are constrained"
This reverts commit 8a481b3e10.
2016-01-10 15:16:06 +01:00
Jasper St. Pierre
8a481b3e10 frame: Don't allow resizing of edges that are constrained
https://bugzilla.gnome.org/show_bug.cgi?id=751857
2016-01-09 18:11:15 -08:00
Jasper St. Pierre
8bded7d497 window: Remove old tiling code
We'll soon replace this with a better scheme

https://bugzilla.gnome.org/show_bug.cgi?id=751857
2016-01-09 18:08:32 -08:00
Jasper St. Pierre
f3fecd478d frame: Always use the client window's visual for our frame
Since the frame is the window that's redirected, there's no reason for
it to match the root window. There *is*, however, a big incentive to
match the window's visual, since not doing so might trigger automatic
redirection.

On a specific platform, we construct a depth-32 root window, and stick a
depth-24 child window inside it. The frame ends up being created
depth-32, not depth-24, so we get automatic redirection.
2015-04-01 15:02:20 -07:00
Carlos Garnacho
d63b9a1797 core: Unset all input events on the GDK connection
With all input events being handled through clutter, this only confuses
things, and most nominally, coerces touch events through places we didn't
intend to, like the window frame.

This makes again all touch events only handled in the passive grab on X11,
while the rest stays pointer (emulated) only.

https://bugzilla.gnome.org/show_bug.cgi?id=745335
2015-03-14 16:03:44 -07:00
Jasper St. Pierre
05353c1f7e frame: Don't redraw immediately when we resize
We're locked to frame sync anyway, so it doesn't make sense to try to
redraw early. In casual testing, this seems to actually make things
faster, as well.
2015-01-30 13:13:49 -05:00
Jasper St. Pierre
d561b3b18f frames: Clutterify frame event handling
This lets us remove our horrible X11-based, GDK-based hacky frame event
handling in favor of a more sane one in Clutter.
2015-01-19 21:56:08 -08:00
Jasper St. Pierre
12135afa5e frames: Give Havoc and Owen a heart attack
Break down the beautiful core/ui abstraction barrier by inserting
a pointer to MetaWindow into a MetaUIFrame. I'm a scoundrel, I know.
We'll use this very soon to destroy meta_core_get.
2015-01-01 11:42:25 -08:00
Jasper St. Pierre
dcce4e64bc frames: We don't need to pass in the frame rect to get_bounds either
The MetaFrameGeometry already has this information.
2015-01-01 11:42:13 -08:00
Jasper St. Pierre
4d3511649b frames: Don't pass the frame rect into get_mask
We can query it directly.
2015-01-01 11:19:35 -08:00
Jasper St. Pierre
8fdbae192a frame: Start converting over to direct usage of MetaUIFrame 2014-12-31 22:44:20 -08:00
Jasper St. Pierre
2413e672c8 frame: Put a MetaUIFrame* in our MetaFrame
This is a small start, but it lets us start to clean up this
UI split mess.
2014-12-31 22:43:00 -08:00
Jasper St. Pierre
90111c03a1 Only poke the frames UI code from inside frame.c
Add frame.c wrappers for the missing calls, then adapt.
2014-12-31 22:35:29 -08:00
Jasper St. Pierre
23681800d9 frame: Remove extra argument from sync_to_window 2014-12-31 22:35:29 -08: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
Giovanni Campagna
d0f2c6be6d ui: always set the frame background to None
This way the xserver never paints the frame background, even if
the client window is destroyed. This allows us to have clean
destroy window animation.

There is no problem with interactive resizing because applications
are using the XSync protocol, so we're not painting unless the
client has redrawn.

https://bugzilla.gnome.org/show_bug.cgi?id=734054
2014-07-31 17:54:38 +02:00
Jasper St. Pierre
1749a85e96 frame: Only XSync when we're on the X11 compositor backend
The only case we have is the case where the two X11 connections are the
same. When on Wayland, the XSync is costly and expensive, and we should
minimize it.
2014-07-10 13:31:26 -04:00
Jasper St. Pierre
30b54aae34 frame: Don't select for core events on the frame window
We override these with XI2 event types anyway. There's no point to
selecting to them.
2014-07-07 19:22:09 -04:00
Carlos Garnacho
7b0930f798 frame: Only select for ButtonPress/Release/Motion/Crossing
Touch events are largely ignored on GdkEvent emulation, so only
make frames receive pointer events, only the pointer emulating
touch will be reported, and any other further touches will be
ignored, which is about the behavior we want. This makes window
dragging possible again on touch.
2014-07-07 19:17:06 -04:00
Jasper St. Pierre
f3f3c94831 frame: Don't reset window->rect 2014-05-28 10:50:23 -04:00
Jasper St. Pierre
6e06648f7a window: Refactor all move/resize operations to be in frame rect space
For Wayland, we want to have everything possible in terms of the frame
rect, or "window geometry" as the Wayland protocol calls it, in order
to properly eliminate some flashing when changing states to fullscreen
or similar.

For this, we need to heavily refactor how the code is structured, and
make it so that meta_window_move_resize_internal is specified in terms
of the frame rect coordinate space, and transforming all entry points
to meta_window_move_resize_internal.

This is a big commit that's hard to tear apart. I tried to split it
as best I can, but there's still just a large amount of changes that
need to happen at once.

Expect some regressions from this. Sorry for any temporary regression
that this might cause.
2014-05-27 15:44:34 -04:00
Florian Müllner
c2ea650b3c Add support for app-menu button in window decorations
We want to synchronize the button layouts of our server side
decorations and GTK+'s client side ones. However each currently
may contain buttons not supported by the other, which makes this
unnecessarily tricky.
So add support for a new "appmenu" button in the layout, to display
the fallback app menu in the decorations.

https://bugzilla.gnome.org/show_bug.cgi?id=730752
2014-05-27 19:40:05 +02:00
Jasper St. Pierre
05419b8450 frame: Make sure to XSync before grabbing keybindings
Otherwise, the X server might read the backend's connection before
GTK+'s, meaning that it sees the XIGrabKeycode requests before the
CreateWindow.

This fixes keybindings on windows not working immediately.

Thanks to Rui Matos <tiagomatos@gmail.com> and
Julien Cristau <jcristau@debian.org> for helping track down the issue.
2014-05-21 11:29:36 -04:00
Jasper St. Pierre
25a16c3379 Remove trailing whitespace 2014-05-02 09:34:48 -04:00
Jasper St. Pierre
d8dfe4e4ad display: Remove the RENDER extension requirement
Surprisingly, it's completely unused across all of the codebase.
2014-04-22 14:17:09 -04:00
Jasper St. Pierre
337db2a660 window: Kill off the rest of colormaps
I removed the XInstallColormap / XUninstallColormap but forgot
to remove the fields in MetaWindow and the code to set them.
2014-03-20 16:27:22 -04:00
Jasper St. Pierre
aec3edb1cc Always map the client and frame windows
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.

However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.

I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.

Remove this now.

The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. In the future, we might want to
show previews of shaded windows in the overview and Alt-Tab. In that
we'd also keep shaded windows mapped, and could remove all unmap logic,
but we'd need a more complex method of showing the shaded titlebar, such
as using a different actor.

At the same time, simplify the compositor interface by removing
meta_compositor_window_[un]mapped API, and instead adding/removing the
window on-demand.

https://bugzilla.gnome.org/show_bug.cgi?id=720631
2014-02-14 23:19:41 -05:00
Jasper St. Pierre
20545941fa Revert unintentional merge from wip/surface-content to wayland
This reverts a lot of commits.
2014-01-22 09:18:13 -05:00
Jasper St. Pierre
8e6f8087e8 Always map the client and frame windows
Traditionally, WMs unmap windows when minimizing them, and map them
when restoring them or wanting to show them for other reasons, like
upon creation.

However, as metacity morphed into mutter, we optionally chose to keep
windows mapped for the lifetime of the window under the user option
"live-window-previews", which makes the code keep windows mapped so it
can show window preview for minimized windows in other places, like
Alt-Tab and Expose.

I removed this preference two years ago mechanically, by removing all
the if statements, but never went through and cleaned up the code so
that windows are simply mapped for the lifetime of the window -- the
"architecture" of the old code that maps and unmaps on show/hide was
still there.

Remove this now.

The one case we still need to be careful of is shaded windows, in which
we do still unmap the client window. Theoretically, we might want to
show previews of shaded windows in the overview and Alt-Tab, so we remove
the complex unmap tracking for this later.
2014-01-21 19:01:18 -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
Daniel Drake
7bfc9109f7 frame: remove unnecessary server grab
meta_window_ensure_frame() creates its own grab and has a comment
claiming that it must be called under a grab too.

But the reasoning given in the comment does not seem relevant here.
We only frame non-override-redirect windows, so we are creating
the frame in response to MapRequest. There is no way that the child
could receive a MapNotify at this point, since that only happens
much later, once we go through the CALC_SHOWING queue and call
XMapWindow() from meta_window_show().

Remove the unnecessary grab.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
2014-01-07 07:17:09 -06:00
Owen W. Taylor
a4a8f1f863 MetaFrame: Cache borders
Cache the computed border size so we can fetch the border size at
any time without worrying that we'll be spending too much time in
the theme code (in some cases we might allocate a PangoFontDescription
or do other significant work.)

The main effort here is clearing the cache when various bits of window
state change that could potentially affect the computed borders.

https://bugzilla.gnome.org/show_bug.cgi?id=707194
2013-11-19 14:04:16 -05: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
Simon McVittie
c2a9ccb7e2 Let the UI layer (via the core) construct the frame mask
This essentially just moves install_corners() from the compositor, through
the core, into the UI layer where it arguably should have been anyway,
leaving behind stub functions which call through the various layers. This
removes the compositor's special knowledge of how rounded corners work,
replacing it with "ask the UI for an alpha mask".

The computation of border widths and heights changes a bit, because the
width and height used in install_corners() are the
meta_window_get_outer_rect() (which includes the visible borders but not
the invisible ones), whereas the more readily-available rectangle is the
MetaFrame.rect (which includes both). Computing the same width and height
as meta_window_get_outer_rect() involves compensating for the invisible
borders, but the UI layer is the authority on those anyway, so it seems
clearer to have it do the calculations from scratch.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2013-04-17 13:35:06 +01:00
Jasper St. Pierre
8c1b2d5eda Simplify the frame testing logic in callers to grab borders
A lot of code did something similar to:

  MetaFrameBorders borders;

  if (window->frame)
    meta_frame_calc_borders (window->frame, &borders);
  else
    meta_frame_borders_clear (&borders);

Sometimes, the else part was omitted and we were unknowingly using
uninitalized values for OR windows. Clean this up by just testing
for a NULL frame in meta_frame_calc_borders and clearing for the
caller if so.

https://bugzilla.gnome.org/show_bug.cgi?id=643606
2012-03-17 06:40:54 -04:00
Jasper St. Pierre
6d0c1f08d2 frame: Make sure to offset by invisible borders when unmanaging windows
When we reparent a window to the root when we're exiting, we need to offset
the position by the invisible borders, otherwise windows will creep up and
to the left.

https://bugzilla.gnome.org/show_bug.cgi?id=660848
2011-10-17 21:53:58 -04:00