I implemented pinging, but never actually enabled the feature
properly on Wayland surfaces by setting the net_wm_ping hint to
TRUE, causing the fallback path to always be hit.
Rename net_wm_ping to can_ping so it doesn't take on an
implementation-specific meaning, and set it for all Wayland windows.
To prevent the MetaSurfaceActor from being destroyed, we normally
unparent it before we unmanage the window. However, this doesn't
work for XWayland windows, which we unmanage when we get UnmapNotify
or DestroyNotify, not when we get the wl_surface_destroy.
To solve this, add an early hook in meta_window_unmanage that
unparents the surface actor if we have one. At the same time, clean
up the destruction code to remove old comments and assumptions about
how wl_shell behaves.
This was a bad idea, as ping/pong has moved to a client-specific
request/event pair, rather than a surface-specific one. Revert
the changes we made here and correct the code to make up for it.
This reverts commit aa3643cdde.
In order for the compositor to properly determine whether a client
is an X11 client or not, we need to wait until XWayland calls
set_window_id to mark the surface as an XWayland client. To prevent
the compositor from getting tripped up over this, make sure that
the window has been fully initialized by the time we call
meta_compositor_add_window.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
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
Use our new "surface_mapped" field to delay the showing of XWayland clients
until we have associated together the window's XID and the Wayland surface ID.
This ensures that when we show this window to the compositor, it will properly
use the Wayland surface for rendering, rather than trying to use COMPOSITE and
crash.
https://bugzilla.gnome.org/show_bug.cgi?id=720631
The goal here is to make MetaWindow represent a toplevel, managed window,
regardless of if it's X11 or Wayland, and build an abstraction layer up.
Right now, most of the X11 code is in core/ and the wayland code in wayland/,
but in the future, I want to move a lot of the X11 code to a new toplevel, x11/.
We no longer unmap the toplevel windows during normal operation. The
toplevel state is tied to the window's lifetime.
Call meta_compositor_add_window / meta_compositor_remove_window instead...
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.
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 caf43a123fhttps://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.
Now that there are no grabs we don't have to worry about explicitly calling
display_notify_window after grabs have been dropped. Fold that into
meta_window_new_shared().
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
Do this by duplicating the current code and porting it to use
X again. A better approach would involve our own event structures,
and I really don't want to do that right now. We can clean this up
later.
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
We require a MetaWindow to properly implement some of the requests
for xdg_surface, so add a way to have an unmapped MetaWindow that
we can store properties on, that we later map when the client
attaches a buffer...
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
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
Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
in the code path for throttling motion events. But this meant that
if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
motion events - for a keyboard resize, or after the end of the grab
operation - it would end up in a stuck state.
Use a separate per-window timeout to reliably catch the failure to respond
to _NET_WM_SYNC_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=694046
During resizing we froze window updates when configuring the
window, and unfroze the window updates when processing the
next resize. This wasn't absolutely reliable, because we might
not have a next resize. Instead tie window freezing more
directly to the current sync request value - a window is
frozen until it catches up with the last value we sent it
in _NET_WM_SYNC_REQUEST.
Testing with unresponsive clients showed that there was a bug
where window->disable_sync once set, would not actually disable
sync, but it *would* disable noticing that the client was
unresponsive for the next resize. Fix that by checking for
->disable_sync before sending _NET_WM_SYNC_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=694046
Send a _NET_WM_FRAME_DRAWN for each newly created window, as required
by the specification. This avoids a race where a window might be created
frozen but already unfrozen by the time we first see fetch the
counter value.
Remove a duplicate call to meta_compositor_set_updates_frozen() which
was called before the MetaWindowActor is created and hence did nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=694771
meta_window_is_remote compares a cached copy of the system hostname
with the hostname of the client window
(as presented by the WM_CLIENT_MACHINE property).
Of course, the system hostname can change at any time, so caching
it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
change when the system hostname changes, so comparing it with the
new system hostname is wrong, too.
This commit makes the code call gethostname() at the time
WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
that value, rather than comparing potentially out of sync hostnames
later.
https://bugzilla.gnome.org/show_bug.cgi?id=688716
We do, in fact, need freezing to affect window geometry, so that
move-resize operations (such as an interactive resize from the
left, or a resize of a popup centered by the application) occur
atomically.
So to make map effects work properly, only exclude the initial
placement of a window from freezing. (In the future, we may want
to consider whether pure moves of a window being done in response
to a user drag should also be excluded from freezing.)
Rename meta_window_sync_actor_position() to
meta_window_sync_actor_geometry() for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
During resizing, An odd counter value (indicating the beginning of a frame)
shouldn't cause us to redraw and start a new frame, only an even counter
value. This was causing the frozen state for the window frame counter to
overlap the frozen state for the resize, causing the window not to be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
In different places we checked the grab op differently when determing
whether we are using _NET_WM_SYNC_REQUEST. This was somewhat covered
up previously by the fact that we only had a sync alarm when using
_NET_WM_SYNC_REQUEST, but that is no longer the case, so consistently
use meta_grab_op_is_resizing() everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.
Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:
- Increment by 1: a no-delay frame
- Increment by more than 1: a non-urgent frame, handle normally
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Resizing the frame triggers creation of a new backing pixmap for the
window, so we should do that first before we resize the client window
and mess up the contents of the old backing pixmap.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Some windows may already have event masks on them that we've selected
for, especially if we're using GTK+ windows. In particular, this fixes
window menus in the XI2 port.
https://bugzilla.gnome.org/show_bug.cgi?id=690581
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
Using a public method for setting the (cached) icon geometry rather
than accessing the struct members directly allows setting the icon
geometry from extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=692997
We have some code in gnome-shell that does the equivalent of:
window.get_workspace() == workspace || window.is_on_all_workspaces();
which is a bit unwieldy. We already have a method in mutter,
so use that and document it.
https://bugzilla.gnome.org/show_bug.cgi?id=691744
Currently, we ping windows only when attempting to delete them, but
if the application is not responding, we want to show the dialog
as soon as possible. Given that we cannot be passively notified that
the window stopped responding with the current X11 protocol, a good
workaround is to ping the window when activating it.
If the window stops responding while active, it is expected the user
will try to switch window or open the overview, and when coming back
he'll get the failure dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
We want to maintain the invariant that an attached modal dialog is always
of type MODAL_DIALOG, so recompute is_attached_dialog() when the window
type changes.
https://bugzilla.gnome.org/show_bug.cgi?id=690454
In random places that are not grabs, we selected for events on
things like the root window, stage window, COW and more. Switch
these over to using the proper XI2 APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
As calling XIGrabDevice multiple times will change it, just
drop the XChangeActivePointerGrab path and just go down the
XIGrabPointer path always.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Mechanically transform the event processing of mutter to care
about XI2 events instead of Core Events. Core Events will be left
in the dust soon, and removed entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
This removes some duplicate event type checks, and will make
the code cleaner in the future when we want to make the grab_op_event
handler take an XIDeviceEvent directly.
Based on a patch by Owen Taylor <otaylor@fishsoup.net>
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Since we want nice alt-tab applications for gnome-shell, we should up the
limit to 96. In the future, we probably want to get rid of the icon-cache,
and allow looking up a correctly sized icon directly from the window.
To prevent app breakage, set the legacy WM_HINTS pixmap size directly to
32x32.
https://bugzilla.gnome.org/show_bug.cgi?id=689651
When using the show-desktop shortcut with no desktop window, unshowing
will focus the second-most-recently-used window. If we find a desktop
window, it will be focused explicitly and everything works as expected;
however without a desktop window, we end up hiding the focus window,
which will use focus_default_window() with the not_this_one parameter
to move focus away. We used to get away with this, as the not_this_one
parameter was ignored until commit e257580b94, now with bug 675982
fixed, we need to explicitly handle the show-desktop case.
https://bugzilla.gnome.org/show_bug.cgi?id=686928
If someone plugs in a new monitor, while all their regular windows
should move in absolute X coordinates to ensure they stay on the
same monitor, the desktop window should stay put.
https://bugzilla.gnome.org/show_bug.cgi?id=681159
When we consider tiling a special case of maximization, it makes
more sense to always unmaximize to the normal state rather than
restoring a previous tile state.
https://bugzilla.gnome.org/show_bug.cgi?id=677565
Currently we decide whether a modal dialog should be attached or not
when mapping it, i.e. we don't pick up preference changes that happen
while the dialog is up. It's not really a big deal given that modal
dialogs are usually transitory, but it's easy enough to add a bit of
extra polish ...
https://bugzilla.gnome.org/show_bug.cgi?id=679904
Side-by-side tiling is conceptually very close to maximization
("half-maximized"), so it makes sense to also hide the titlebar
in this state if requested by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=679290
Similar to meta_screen_get_primary_monitor, this returns a monitor index.
The monitor that the pointer is on. The previous private implementation
has been renamed to meta_screen_get_current_monitor_info.
https://bugzilla.gnome.org/show_bug.cgi?id=642591
It is impossible to switch to other windows when keep-on-top is set
for maximized windows; given that keep-on-top is only ever useful
to keep a window visible while focusing a different window, the
current behavior is pointless. So ignore keep-on-top while a window
is maximized.
https://bugzilla.gnome.org/show_bug.cgi?id=673581
Starting the auto-maximize process on a window like a
META_WINDOW_DESKTOP window that is not maximizable gets placement into
a confused state and eventually results in the window being positioned
at the wrong position (the position that an auto-maximized window would
be restored to.)
https://bugzilla.gnome.org/show_bug.cgi?id=673566
"warning: 'match_tile_mode' may be used uninitialized in this function", it
complains. It thinks it's not unused because of other values of
window->tile_mode, but other complex logic ensures that it can't be
META_TILE_MAXIMIZED, so this is a safe commit.
Windows that have minimum widths larger than the screen can't be maximized,
even though we put them in a maximized state and allow users to do so:
the window just won't change size and position. Fix this by simply not giving
the option to maximize, like what happens for non-resizable windows.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
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
Since we're going to be evaluating the work area at startup now, we need
to make sure that we don't iterate over workspaces before they're assigned.
The easiest way to do this is to make sure that meta_window_get_workspaces
doesn't crash.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Returns the matching tiled window. This is the topmost tiled window in a
complementary tile mode that is:
- on the same monitor;
- on the same workspace;
- spanning the remaining monitor width;
- there is no 3rd window stacked between both tiled windows that's
partially visible in the common edge.
https://bugzilla.gnome.org/show_bug.cgi?id=643075
Windows that start up in a size that is almost as big as the workarea create
extra work for the user (resizing or maximizing) so save the user's time by
detecting such windows and automaximize them.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
Basically we don't really want to create windows that are almost maximized in
size but not actually maximized. This creates work for the user and makes it
very difficult to use and resize manually.
So set the newly unmaximized window size to the previously used size or 80% of the
size of the current workarea (attempting to retain natural aspect ratio if
possible), whichever is smaller.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
After _unmanage the object is semantically dead even if technically it's not,
so remove the prefs listener here to prevent it being called for a dead
object.
In particular this fixes a crash when starting up gnome-shell with at least
one gimp utility window opened which causes mutter to create a MetaWindow for
it only to immediately get an UnmapNotify afterwards which causes mutter to
unmanage the MetaWindow. Afterwards prefs_changed_callback is called for this
dead MetaWindow and tries to dereference the window->monitor pointer which is
already NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=671087
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
To account for this use case, a setting for requesting that windows'
titlebars should be hidden during maximization has been added to
GTK+, add support for this in the window manager.
https://bugzilla.gnome.org/show_bug.cgi?id=665617
The current code requires windows to be resizable to be considered
for tiling, which excludes all maximized/tiled windows. While this
restriction concurs with the desired behavior for edge-tiling, it
feels overly restrictive for keybindings.
As the edge-tiling code in update_move() already ensures the above
restriction, it seems save to remove it from the can_tile_maximized()
function, assuming that windows that are not meant to be tiled or
maximized won't provide a maximize function.
https://bugzilla.gnome.org/show_bug.cgi?id=648700
Usually tiling involves a size change and the frame is redrawn
automatically, however this is not the case when switching directly
between left- and right-tiled.
Ensure that a redraw happens in that case as well.
https://bugzilla.gnome.org/show_bug.cgi?id=648700
Move preferences to GSettings, using mainly shared schemas from
gsettings-desktop-schemas.
Unlike GConf, GSettings support is not optional, as Gio is already
a hard dependency of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=635378
meta_window_move_resize_frame operates much like
meta_window_move_resize, but ensures the window
and its frame (if present) will fit within the
specified dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=651899
If we are moving in snap mode (shift pressed) we don't want to tile. We must
also cancel any pending tiling if snap mode is activated during the move drag.
https://bugzilla.gnome.org/show_bug.cgi?id=662270
meta_window_get_current_tile_area() computes the area where the tiled window
should be based on the current pointer position but that's only meaningful
when the user is actually dragging the window.
When running the tiling constrain the pointer might be on other monitor and at
that point the window jumps to this other monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642580
Since the frame window size that meta_window_move_resize() uses depends
on whether the window has horizontal/vertical resize functionality, we
need to update this flag before we resize the window.
https://bugzilla.gnome.org/show_bug.cgi?id=659854
If a window had a type hint intended for override-redirect windows
like NOTIFICATION, we ended up with a window that was decorated but
with a frame type of FRAME_TYPE_LAST, causing assertion failures.
Fix this by making recalc_window_features() just call
meta_window_get_frame_type().
https://bugzilla.gnome.org/show_bug.cgi?id=599988
_NET_FRAME_EXTENTS should contain the difference between where a window asked
to be placed, and where it is. Ideally, this should be the same as the visible
extents.
https://bugzilla.gnome.org/show_bug.cgi?id=659848
A window can specify geometry that it is placed at. We need to exclude invisible
borders when calculating where to place the window, otherwise the window will have
a strange offset.
https://bugzilla.gnome.org/show_bug.cgi?id=659848
If XRANDR is availible, we track the first (or primary) output per
crtc (== xinerama monitor) so when the monitors change we can try
to find the same output and move windows there. If we can't find the
original monitor in the new set (or XRANDR is not supported) we move
the window to the primary monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=645408
