The coordinates in ConfigureNotify *should* be the coordinates of the
client window; using the coordinates of the frame window compensated for
a problem with the interpretation of StaticGravity for some clients but
broke other clients.
This reverts commit f4f70afe31.
https://bugzilla.gnome.org/show_bug.cgi?id=736719
Some applications, like totem, create keyboard/pointer objects from the
same client, and expect it to work. We made this work a while ago, but
due to an oversight in the code, we increment the serial on button press
for every resource that we need to send events to.
Since operations like move/resize use the grab serial of the devices to
determine whether the operation is exact, we need to make sure the same
serial goes to all devices.
Restructure the code so that all that's in the resource loop is the
sending of the event -- all the calculation that's needed happens
outside.
This fixes moving / resizing the Totem window not working sometimes.
https://bugzilla.gnome.org/show_bug.cgi?id=736840
The fix in d61dde1 regressed the position of popup windows, since the
size was 0x0 when we wanted to do a sole move. Only fizzle out in the
path where we actually *do* resize.
https://bugzilla.gnome.org/show_bug.cgi?id=736812
Going through GSD's settings was done in context of patches that
did not land; it is simpler and more consistent with GTK+ to use
the corresponding XSetting instead.
We only broadcast input to the focus_resource_list, so we need to make
sure it's put in the proper list on startup.
This fixes input not working for windows when they first appear.
Argh. There's always more stuff to fix with keyboard/pointer. Every
single time I think I've fixed it, more stuff pops up.
GTK+ requests get_xdg_surface before attaching a buffer, and since it
might take a long time for GTK+ to get around to attaching a buffer and
committing it, our idle for MOVE_RESIZE will kick in beforehand.
And our idle will try to resize the 0x0 window that currently exists,
constrain it to 1x1, which will send a configure event of 1x1 to the
window while it boots up, causing it to awkwardly resize to the minimum
size of the window.
Make sure that in this case, our idle doesn't cause any problems, and
that we fizzle out any idles like this.
The "proper" way to do this would be to delay the creation of the
MetaWindow until a surface is committed, but that's difficult for a
variety of reasons, and might cause unintended issues with focus.
This prevents issues from happening when processing Enter/Leave events
while in another kind of grab op like a Wayland popup or resizing a
window.
This can't ever really happen except outside of a race condition,
with the X server, since we won't ever pass input events to the
X server in any of these cases, but it can't hurt to be more correct
about what the intended operation is.
GTK+ focuses its own windows with RevertToParent, which means that when
a GTK+ CSD window is destroyed, the X server will set the focus back to
the root window. The event stream that we is an UnmapNotify followed by
a FocusOut event. Our own UnmapNotify-handling code unmanages the window
and forcibly changes the focus to the next default window in the stack.
Since UnmapNotify events don't come with timestamps, we query for one,
and set the window focus using that.
But there's *still* a FocusOut event in the stack, with an older
timestamp and serial than our own focusing. We see this, throw it out
since it's older than the most recent focus, but then our own code that
notices the root has been focused kicks in and tries to focus the
default window... using a timestamp older than our most recent focusing.
meta_display_sanity_check_timestamps notices this, and (rightly so)
puts a warning in our face, telling something is awry.
Only let our workarounds kick in when the event is new enough, otherwise
our code will get confused over old events.
This stops the:
Window manager warning: last_focus_time (367917173) is greater than comparison timestamp (367917170). This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW. Trying to work around...
warning spam when closing a CSD window.
The last_sent size is effectively what size we should send in configure
requests where the size hasn't changed. Thus, if an app commits a new
size, we need to make sure we respect it and don't reconfigure it with
a size it wasn't expecting when the state changes.
This fixes apps being sent a configure event with 0, 0 on startup,
which was confusing Clutter into displaying a 0x0 viewport.
Restacking the frame for a window while unmanaging the window is
harmless, but for undecorated (in particular, client-side-decorated)
windows, this causes problems because the window is typically
destroyed by the client immediately after withredrawing the window.
Skip windows flagged as being unmanaged when assembling the new
stack and when comparing the old order to the new stack.
Add a stacking test for this.
Windows can be freed at some point after they are unmanaged - because
there is an effect in progress, because a language binding is holding
a reference. Therefore, we need to clean up the later to associate
the xwayland and wayland windows deterministically in an "unamanaged"
handler.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
g_idle_add() makes no guarantee about when it will be run - if Mutter
is busy drawing and blocking glXSwapBuffers() it could happen only
minutes later. Use meta_later_add (META_LATER_BEFORE_REDRAW) instead -
this will deterministically be run after the Wayland socket is read
from but before the next frame is painted.
https://bugzilla.gnome.org/show_bug.cgi?id=736694
We shouldn't scale the cursor size in mutter we g-s-d exports
the correct size on hidpi so use gtk-cursor-theme-size.
This way we also catch changes on resolution updates.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
This reverts commit 4fe66ce0a9.
This is wrong ... we should not scale the cursor size but read
the cursor xsettings that gets exported by gsd. Also this won't update on
resolution changes.
https://bugzilla.gnome.org/show_bug.cgi?id=729337
When restacking the last window alone, we would trigger this off-by-one
error. This would throw us off the end of the array, causing lower_below
warnings for nonsensical values.
Since the last window already is lowered below everything else, we
shouldn't need to lower it.
The merge of the commit af46ef3b 'meta_window_new: clean up error handling'
to the wayland branch accidentally added an extra call to meta_error_trap_push(),
meaning that we leaked one level of error traps for each new window.
Fixes warning:
Gdk-WARNING **: XSetErrorHandler() called with a GDK error trap pushed.
https://bugzilla.gnome.org/show_bug.cgi?id=736589
When the screen resizes, we get a configure event for the composite overlay
window - don't pass that to MetaStackTracker, since the COW isn't in the
stack.
Fixes warning:
mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x65 not in stack
We have a quite accurate view of the X stack, so there's no good reason to ask
the X server to do restacking that has no effect. (Restackings that have no
effect on either X windows or Wayland windows were generally optimized out in
the synchronization code, but in other cases like moving an X window that is
only beneath Wayland windows to the top of the stack we would make such
requests.)
Removing such requests:
- Is a small efficiency win in itself
- Allows us to immediately go ahead and apply Wayland changes to the verified stack
- Prevents queued Wayland changes piling up waiting for an X event that will never
be received, since the X server will not send confirmation of no-op restacks.
Since such operations may still have an effect on the relative stacking of X
and Wayland windows, we need to continue applying them to the local stack.
https://bugzilla.gnome.org/show_bug.cgi?id=736559
