The addition of GdkMonitor broke the quartz backend. This patch restores
that support by adding a new class GdkQuartzMonitor, and by modifying
the existing classes GdkQuartzDisplay and GdkQuartzScreen where
necessary.
It should be noted that this patch is essentially a refactor as no new
functionality that will impact the user has been added or removed.
https://bugzilla.gnome.org/show_bug.cgi?id=779184
When the GtkWidget hierarchy does not match the GdkWindow hierarchy, the
GtkWidget code may find a common ancestor that cannot be found while
traversing the GdkWindow tree using gdk_window_get_parent().
This happens with for example on Wayland, a GtkPopover has another
GtkPopover as parent, in this case, the GdkWindow parent is the root
window, whereas the GtkWidget parent is the other GtkPopover.
That confuses the gtk_widget_translate_coordinates() logic which will
bail out in this case and won't return the translated coordinates.
Make gdk_window_get_effective_parent() aware of subsurfaces and use the
transient_for which represents the actual parent (whereas the parent
might be pointing to the root window).
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=774148
For some reason, we are seeing damage being NULL here.
While that should never be the case, crashing on it is
unkind and makes the Wayland experience unusable.
Make sure to clear up the number of keys being pressed on enter/leave so
that we don't end up with leftovers if a new window is mapped by a
keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=779374
The key repeat is stopped as soon as a key is pressed, so if the user
quickly presses a key while another is already pressed and being
repeated, key repeat gets cancelled:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key 2 is not repeated even though it's kept depressed
This is a different behavior from X11, which confuses migrating users.
To mimic the X11 behavior, keep track of the number of keys pressed
simultaneously and cancel key repeat only when none is pressed.
This way, if a user pressed a key while another one is being repeated,
the new key press can possibly be repeated as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=778019
When resizing an xdg_popup immediately after the initial mapping, there
is a race condition between the client and the compositor which is
processing the initial size given by the xdg_positioner, leading to the
xdg_popup to be eventually of the wrong size.
Only way to make sure the size is correct in that case is to hide and
show the window again. Considering this occurs before the initial
configure is processed, it should not be noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=772505
Otherwise we wait for the next gdk_drag_motion() call, which will
happen on the next motion event, making the drag window briefly visible
on the 0,0 root coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=778203
Clamping the anchor values as introduced in commit 9a5ffcd to fix bug
777176 breaks menu positioning.
By keeping the anchors rectangle size greater than zero, we end up
deducting some positive value from the original position, so there is no
need to clamp() actually, keeping the values positive is enough and
avoids the issue with menu positioning on the menubar.
An additional benefit is to make the code a lot simpler.
https://bugzilla.gnome.org/show_bug.cgi?id=778009
Currently hiding destroys the wl_surface and all related interfaces,
(including the gtk_surface1) so the next time the GdkWindow is mapped,
we don't bother to set the DBus properties. Toggle the check off so
it's actually issued again after the GdkWindow gets a gtk_surface1.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
