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
Prior to the DisplayConfig merge, we would set _NET_WM_FULLSCREEN_MONITORS
to (unsigned)-1 when unset. After that, we would have invalid
reads inside meta_screen_monitor_index_to_xinerama_index() (called
with -1).
The way I read the specification, the proper way to indicate
that the window is back to fullscreen on all monitors is to
remove the property, so do that.
Also, add an assertion that meta_screne_monitor_index_to_xinerama_index()
is doing the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=724258
When GDK sends an unmaximize _NET_WM_STATE ClientMessage, it tells us to remove
the _NET_WM_STATE_MAXIMIZED_HORZ and _NET_WM_STATE_MAXIMIZED_VERT states. Before
this time, it would independently call:
meta_window_unmaximize (window, META_MAXIMIZE_HORIZONTAL);
meta_window_unmaximize (window, META_MAXIMIZE_VERTICAL);
Which, besides being foolishly inefficient, would also mess up our saved_rect
tracking, causing the window to only look like it was unmaximized vertically.
Make this code more intelligent, so it causes us to unmaximize in one call.
https://bugzilla.gnome.org/show_bug.cgi?id=722108
This grab was added in commit caf43a123f40d3a68599ac5453a79759b828e8f0
https://bugzilla.gnome.org/show_bug.cgi?id=381127
to minimize window flickering when switching workspaces.
While this grab is held, some signals are emitted to the shell,
which can lead to deadlocks (reproduced under Mali binary OpenGLESv2
drivers).
Now that we are a compositing window manager, we do not have to
worry about flickers, this grab should no longer be necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=721709
Remove some obvious server grabs from the window creation codepath,
also ones that are taken at startup.
During startup, there is no need to grab: we install the event handlers
before querying for the already-existing windows, so there is no danger
that we will 'lose' some window. We might try to create a window twice
(if it comes back in the original query and then we get an event for it)
but the code is already protected against such conditions.
When windows are created later, we also do not need grabs, we just need
appropriate error checking as the window may be destroyed at any time
(or it may have already been destroyed).
The stack tracker is unaffected here - as it listens to CreateNotify and
DestroyNotify events and responds directly, the internal stack
representation will always be consistent even if the window goes away while
we are processing MapRequest or similar.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The return code of XGetWindowAttributes() indicates whether an error
was encountered or not. There is no need to specifically check the error
trap.
The trap around XAddToSaveSet() was superfluous. We have a global error
trap to ignore any errors here, and there is no need to XSync() as GDK
will later ignore the error asynchronously if one is raised.
Also move common error exit path to an error label.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
The compositor code used to handle X windows that didn't have a
corresponding MetaWindow (see commit d538690b), which is why the
attribute query is separated.
As that doesn't happen any more, we can clean up. No functional changes.
Suggested by Owen Taylor.
https://bugzilla.gnome.org/show_bug.cgi?id=721345
When we move focus elsewhere when unmanaging a window, we *need* to move
the focus, so if the target is globally active, move the focus to the
no-focus-window in anticipation that the focus will normally get moved
to the right window when the target window responds to WM_TAKE_FOCUS.
If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left
on the no-focus-window, but there's no way to distinguish whether the
app will respond or not.
https://bugzilla.gnome.org/show_bug.cgi?id=711618
Initial placement during meta_window_constrain() can result in changes
to the borders, so we need to recompute our border sizes after
constraining. This fixes incorrect window borders on
initially maximized windows.
https://bugzilla.gnome.org/show_bug.cgi?id=720417
When unmaximizing, we changed bits of window state, then called out
to code that used the frame extents *before* we cleared old cached
extents. Clear the cache up-front as soon as we change the window
state.
https://bugzilla.gnome.org/show_bug.cgi?id=714707
For clarity, rename meta_window_get_outer_rect() to match terminology
we use elsewhere. The old function is left as a deprecated
compatibility wrapper.
Instead of passing around MetaFrameBorders, compute it when we need it.
This also allows us to know that we are using MetaFrameBorders only for windows
with frames (where it is meaningful) and not for frameless windows, which
can have custom borders which we need to interpret differently.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
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
There are extensive places in the code where we convert between the client
rectangle and the frame rectangle. Instead of manually doing it use
new helper functions on MetaWindow and the existing meta_window_get_outer_rect().
This fixes a number of bugs where the computation was being done incorrectly,
most of these bugs are with the recently added custom frame extents, but
some relate to invisible borders or even simply to confusion between the
window and frame rectangle.
Switch the placement code to place the frame rectangle rather
than the client window - this simplifies things considerably.
https://bugzilla.gnome.org/show_bug.cgi?id=707194
We now track whether a window has an input shape specified via the X
Shape extension. Intersecting that with the bounding shape (as required
by the X Shape extension) we use the resulting rectangles to paint
window silhouettes when picking. As well as improving the correctness of
picking this should also be much more efficient because typically when
only picking solid rectangles then the need to actually render and issue
a read_pixels request can be optimized away and instead the picking is
done on the cpu.
As part of Wayland support, we should hold the shape and opaque regions
on the MetaWindow rather than fetching them in the MetaWindowActor, as
this gives us better flexibility as to where the regions are set, and
allows for easier Wayland support.
To make merging easier with the Wayland branch, we also append the _x11
suffix to functions that use the X SHAPE extension to fetch the shaped
regions.
https://bugzilla.gnome.org/show_bug.cgi?id=706930
Dialogs that don't have a parent should not be skip-taskbar,
otherwise they get lost and there is no way to recover them
(because they're not autoraised when activating the parent),
but toolkits and applications set the hint anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=673399
Consolidate all places that deal with output configuration in
MetaScreen, which gets it either from XRandR or from a dummy static configuration.
We still need to read the Xinerama config, even when running xwayland,
because we need the indices for _NET_WM_FULLSCREEN_MONITORS, but
now we do it only when needed.
https://bugzilla.gnome.org/show_bug.cgi?id=705670
Originally attached dialogs did not have a titlebar, which the code
still assumes though it hasn't been true for a while; nowadays, the
actual look of attached dialogs is controlled by the theme.
As GTK+ recently gained the ability to set custom titlebars, we need
to support attached dialogs with either full borders (WM decorations)
or border-only (GTK+ titlebar).
Just remove the left-over assumption to make it work as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=702764
We need to update window->monitor on override_redirect windows as well, other
wise they may end up with an invalid struct which triggers and assert when
meta_window_is_monitor_sized is called.
https://bugzilla.gnome.org/show_bug.cgi?id=702564
Avoid a round trip to the xserver we already have the current position
anyway. Querying from the server on every move can cause the compositor to
stall during movement.
If an app pops up an OR window and sets input focus to it, like
Steam does, we'll think the focus window is null, causing us to
think the app is not focused.
OR windows should not be special if they get input focus, where
the input focus would be set to NULL. Instead, the window should
be marked as focused.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Mutter previously defined display->focus_window as the window that the
server says is focused, but kept display->expected_focus_window to
indicate the window that we have requested to be focused. But it turns
out that "expected_focus_window" was almost always what we wanted.
Make MetaDisplay do a better job of tracking focus-related requests
and events, and change display->focus_window to be our best guess of
the "currently" focused window (ie, the window that will be focused at
the time when the server processes the next request we send it).
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Make it a static function for now, but this will be a private
function soon, replacing meta_window_lost_focus. This should
contain no functional changes, only cosmetic indentation changes,
so best viewed with ignorews=1 or -w or -b, you know the drill.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Clients using _NET_WM_MOVERESIZE to start a drag operation may encounter
a race condition if the user presses and releases a mouse button very
fast, getting "stuck" in a grab state. While this is easily fixed with
the user pressing the button or hitting Escape as the EWMH spec suggests,
its's still a bit of annoyance for users.
After starting a grab operation, check that the button is actually pressed
by the client, and if not, cancel the grab operation. This prevents the
stuck grab in a race-free way, although it requires an extra round-trip
to the server.
With client-side decorations becoming more popular, the use of
_NET_WM_MOVERESIZE is on the rise, thus this bug is seen more frequently
than before.
https://bugzilla.gnome.org/show_bug.cgi?id=699777
In 97a4cc8c, we accidentally lost the check that kept us from
sending multiple configures to a window before it responds to
_NET_WM_SYNC_REQUEST. So _NET_WM_SYNC_REQUEST stopped working
properly. Add a check back with the same effect.
https://bugzilla.gnome.org/show_bug.cgi?id=696091
