Now that we don't have to regrab to change the cursor, since it's
simply the cursor on the root window, all we have to do is update
the cursor on the screen.
We expect that meta_screen_set_cursor while grabbed will properly
set the cursor on the root window. Make sure this works by simply
always using the root cursor when we have an active grab.
If we send out a configure notify for a window and then have some
other kind of state change, we need to make sure that we continue
to send out that new size, rather than the last size the client
sent us a buffer for.
In particular, a client might give us a 250x250 buffer and then
immediately request fullscreen. We send out a configure for the
monitor size and a state that tells it it's full-screen, but then
it takes focus, and since the client hasn't sent us a buffer for
the new size, we tell it it's fullscreen at 250x250.
Fix this.
It isn't necessary. As an X11 compositor, we'll only see the event
if we have the grab on the window, anyway.
This was causing issues moving windows as a Wayland compositor.
When we're a Wayland compositor, we get all the events, no exceptions,
so we don't need to grab.
This was masking focusing and raising issues under nested that showed
up under native.
If we apply a prediction immediately instead of queueing, we should
also free the operation immediately.
If we discard the prediction queue because we resync fully, we
need to free each operation too.
https://bugzilla.gnome.org/show_bug.cgi?id=729732
If we exit early as not handled, then the normal process_event
handler will fire, and trigger the overlay-key binding. As that's
a special binding that doesn't have a handler, trying to trigger
that handler will crash mutter.
Instead of returning early, just check for xdisplay every time
we try to drive the X grab state machine. We really need a better
solution for this on the Wayland side.
We can only apply a configuration if its outputs match the connected
ones, so discard the current configuration if the set of output changes
(for example for hotplug), otherwise we will crash trying to apply
the bogus previous configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=725637
If we attach to a MetaWindow that disappears before the idle fires,
we'll notice that we can't associate the window properly again and
try to access data on the MetaWindow struct, which might crash.
Install a weak ref that ties the lifetime of the idle to the lifetime
of the MetaWindow.
It seems every GTK+ app does this for some reason at startup. This
is really unfortunate, since we'll have to create and destroy a new
MetaWindow really quickly.
Scale surfaces based on output scale and the buffer scale set by them.
We pick the scale factor of the monitor there are mostly on.
We only handle native i.e non xwayland / legacy clients yet.
https://bugzilla.gnome.org/show_bug.cgi?id=728902
Advertise the scale factor on the output and transform pointer and damage
events as well as input and opaque regions for clients
that scale up by themselves i.e use set_buffer_scale.
We do not scale any 'legacy' apps yet.
https://bugzilla.gnome.org/show_bug.cgi?id=728902
Since commit 6e8d1d79d, move operations are always performed for
the (toplevel) parent of all transient, which is just plain silly
if the dialog is not actually attached to its parent (either because
the dialog is not modal or the setting is disabled).
