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
There is now a meta_display_handle_event alongside the
meta_display_handle_xevent function which handles events in terms of
Clutter events instead of X events. A Clutter event filter is
registered so that all Clutter events will pass through this function.
The pointer event handling code from the X event version has been moved
into this new function and has been modified to use the details from
the Clutter event instead of the X event. This is a step towards
moving all of the event handling code over to use Clutter events.
Based-heavily-on-a-patch-by: Neil Roberts <neil@linux.intel.com>
To properly resize clients, we need to send them configure events
with the size we computed from the constraint system, and
then check if the new size they ask is compatible with
our expectation.
Note that this does not handle interactive resizing yet, it
merely makes the API calls work for wayland clients.
https://bugzilla.gnome.org/show_bug.cgi?id=707401
Make sure that meta_display_list_windows() returns wayland windows
too, by keeping a separate hash for wayland clients.
This fixes a crash in the alt-tab code of gnome-shell.
Reviewed by drago01 in IRC.
Warnings that are going to the journal should be not translated:
they're not user visible, and translating them would just make
bug reporting harder (as now the developers need to understand
what the warning is saying)
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Switching meta/util.h to gi18n.h was wrong, mutter is a library
and needs gi18n-lib.h, but that cannot be included from a public
header (since it depends on config.h or command line options),
so split util.h into a public and a private part.
https://bugzilla.gnome.org/show_bug.cgi?id=707897
Add a new interface, gtk_shell, than can be used by gtk to
retrieve a surface extension called gtk_surface, which will be
used to communicate with mutter all the GTK extensions to EWMH
https://bugzilla.gnome.org/show_bug.cgi?id=707128
Add support for GTK application menus
To do so, we need to be able to set surface state before creating
the MetaWindow, so we introduce MetaWaylandSurfaceInitialState as
a staging area.
The gtk-shell-surface implementation would either write to the
initial state, or directly to the window.
At the same, implement set_title and set_class too, because it's
easy enough.
https://bugzilla.gnome.org/show_bug.cgi?id=707128
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
The previous code was leaving focus fields dirty in MetaWaylandPointer
and MetaWaylandKeyboard at time (which could crash the X server
because of invalid object IDs)
The new code is more tighly integrated in the normal X11 code
for handling keyboard focus (meaning that the core idea of input
focus is also correct now), so that meta_window_unmanage() can
do the right thing. As a side benefit, clicking on wayland clients
now unfocus X11 clients.
For the mouse focus, we need to clear the surface pointer when
the metawindowactor is destroyed (even if the actual actor is
kept alive for effects), so that a repick finds a different pointer
focus.
https://bugzilla.gnome.org/show_bug.cgi?id=705859
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.
This adds support for running mutter as a hybrid X and Wayland
compositor. It runs a headless XWayland server for X applications
that presents wayland surfaces back to mutter which mutter can then
composite.
This aims to not break Mutter's existing support for the traditional X
compositing model which means a single build of Mutter can be
distributed supporting the traditional model and the new Wayland based
compositing model.
TODO: although building with --disable-wayland has at least been tested,
I still haven't actually verified that running as a traditional
compositor isn't broken currently.
Note: At this point no input is supported
Note: multiple authors have contributed to this patch:
Authored-by: Robert Bragg <robert@linux.intel.com>
Authored-by: Neil Roberts <neil@linux.intel.com>
Authored-by: Rico Tzschichholz.
Authored-by: Giovanni Campagna <gcampagna@src.gnome.org>
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.
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
During a resize, if we don't have a configure pending, then a counter
change shouldn't trigger anything other than the normal drawing:
it's just a spontaneous frame from the application. So don't try
to update the position or remove our timeout ID.
https://bugzilla.gnome.org/show_bug.cgi?id=696091
Trying to track the fullscreen status outside of Mutter, as GNOME Shell
was doing previously, was very prone to errors, because Mutter has a
very tricky definition of when a window is set to be fullscreen and
*actually* acting like a fullscreen window.
* Add meta_screen_get_monitor_in_fullscreen() and an
::in-fullscreen-changed signal. This allows an application to
track when there are fullscreen windows on a monitor.
* Do the computation of fullscreen status in a "later" function that
runs after showing, so we properly take focus into account.
* To get ordering of different phases right, add more values
to MetaLaterType.
* Add auto-minimization, similar to what was added to GNOME Shell
earlier in this cycle - if a window is set to be fullscreen, but
not actually fullscreen, minimize.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
Since the tile mode is now always reset on maximize(), this code
no longer does anything (not to mention that side-by-side tiled
windows haven't snapped back for a while now).
https://bugzilla.gnome.org/show_bug.cgi?id=682779
We used to restore side-by-side tiling when unmaximizing, so we
kept the tile-mode during maximization. Since commit 10d53fc7d
there's no longer a good reason to do so, and it can result in
tile previews being shown erroneously on window drag operations
without motion (double-click on titlebar), so reset the tile
mode in maximize().
https://bugzilla.gnome.org/show_bug.cgi?id=682779
The tile preview is expected to be shown underneath the focus window.
However the code that restacks the preview broke when override-redirect
windows were moved to a separate window group.
To fix, special-case tile previews to put them in the NORMAL layer.
https://bugzilla.gnome.org/show_bug.cgi?id=696053
