A function that blocks the mainloop and creates a recursive
one goes against normal GObject signal usage, causes unexpected
issues, and is a pattern that should be avoided.

Dan Torop authored Apr 13, 2017 and Olivier Fourdan committed Jun 02, 2017

Under Wayland, when multiple keys are pressed and the user releases a
key, key repeat should continue unless the key released is the one
currently repeating.

In the case of:

- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key2 repeat
- key2 release

The behavior should be to cancel keyboard repeat, though key1 is still
held down. This is consistent with prior X11/XWayland behavior.

The following also must work:

- key1 press
- key2 press
- key2 release
- key2 press
- key1 release
- key2 should continue to repeat

The fix for bug #778019 should continue to work:

- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key2 should repeat

The choice to change the counter nkeys to the flag repeat_active
helps to solve the second test case.

https://bugzilla.gnome.org/show_bug.cgi?id=781285

begin_resize_drag() and begin_move_drag() check for xdg_surface being
not null, but those apply on xdg_toplevel so they should check for
xdg_toplevel being non-null instead.

https://bugzilla.gnome.org/show_bug.cgi?id=781945

When an event is received while a tooltip is showing, the GtkTooltip's
event handling code can end up calling gdk_window_set_transient_for()
from gtk_tooltip_set_last_window().

The Wayland GDK backend will try to automatically create a subsurface
in gdk_wayland_window_set_transient_for() but if the parent surface is
gone meanwhile, this will will cause a crash when trying to create a
subsurface from a parent with a null surface.

Checking for the parent is not sufficient, we ought to check for the
parent surface as well to avoid the crash.

https://bugzilla.gnome.org/show_bug.cgi?id=782283

Applications can specify the type hint as utility even on toplevel
windows.

When that toplevel is also marked as a transient for another window,
GDK Wayland backend would translate that as an xdg_popup which is not
appropriate.

While utility temp windows should remain mapped as subsurfaces (such as
the ones used by treeviews), regular windows should not translate as
neither a subsurface nor an xdg_popup.

https://bugzilla.gnome.org/show_bug.cgi?id=781945

The code used SIGDN_URL to get an URL for the selected item, but Windows URLs
are a mix of unicode and percent encoded characters in the locale encoding
and not something GFile can understand. The result is a garbage file
path.

Instead use SIGDN_FILESYSPATH to get a real file path if available.

Also checks the return value of g_utf16_to_utf8 because file paths on
Windows can contain lone surrogates which would make the conversion fail.

https://bugzilla.gnome.org/show_bug.cgi?id=783347

If we have sassc installed then we want to rebuild the themes that use
SCSS whenever one of their dependencies change.

Another selector forces round corners for headerbars in a stack, and it
has higher priority than the selector covering the non-stack case from
commit 796f9b5b. Totem’s MainToolbar
happens to be in a stack, and we should maintain symmetry here anyway.

So, as window classes .maximized and .tiled are excluded from this other
selector, the newly handled .fullscreen case must be excluded here also.

https://bugzilla.gnome.org/show_bug.cgi?id=770513

Daniel Boles authored May 31, 2017 and Daniel Boles committed May 31, 2017

Make parse-sass.sh use sassc instead of the old Ruby method.

Totem uses a fullscreen window with a headerbar at the top, and without
this change, that headerbar has rounded corners, which look different
from a maximised window and let video content show through beneath.

https://bugzilla.gnome.org/show_bug.cgi?id=770513

I think parse-sass.sh needs updated to match what Adwaita does now, but
for now, this is sufficient to let us regenerate HighContrast again.

In addition to 406db150

There is no need to have every application log a warning when the
Wayland display server goes away, and we are using _exit instead of
exit elsewhere.

This is also what the X11 backend does (see gdk_x_io_error).

https://bugzilla.gnome.org/show_bug.cgi?id=745289

In order to make it really sure the GtkPointerFocus is valid while being
removed from a GtkWindow.

We were getting the toplevel most often here, so the gestures weren't
properly cleaned up.

As we now refrain from sending the crossing events if there's an
implicit grab, those events must be sent on button release when
the implicit grab is broken.

This is now called outside update_pointer_focus_state() with the events
that actually matter (i.e. pointer ones, so no sequence == NULL checks)

Check the grab widget (both explicit and implicit) and check for a cursor
from the target widget up to this grab widget. If the target widget is
outside the grab widget, only the grab wigdet's cursor will be checked.

This also means that we have to ensure the cursor is updated on button
releases, as an implicit grab being deactivated must trigger a cursor
lookup from the target widget.

We must account for the widget allocation now that there is no view_window.

We must account for the widget allocation now that there is no view_window.

In these situations we must perform the "is it claimed" check before removing
the (touch)point, as doing so when the gesture is empty will be too late if
the gesture actually claimed input.

Timm Bäder authored May 20, 2017 and Carlos Garnacho committed May 25, 2017

These are just leftovers, it's already gone from public API and the
_{set,get}_property implementations.

Look up the event target, not the "event widget" which is based on the
event window, and thus points to the toplevel.

This just applied to child windows, but now GDK should just take care of
toplevels, which shall get crossing events from the windowing when the right
conditions apply.

Removing this code fixes confused crossing state in widgets and messed up
window_under_pointer tracking (Which now is meant to be toplevels) when any
of the remaining child GdkWindows trigger these crossing events.

For some reason this wasn't done on windows with an impl, but it totally should.
Probably hidden by grabs in menus and somesuch being done on a child window.

There's no need anymore to translate coordinates, the event already contains
popover-relative ones.

This makes interaction possible with popovers again.

Timm Bäder authored May 10, 2017 and Carlos Garnacho committed May 25, 2017

We already issue the first _get_parent call before even entering that
loop, so make sure `parent` is not NULL. This happens when event_widget
is already a toplevel, and this change fixes row-dragging in treeviews.

Timm Bäder authored May 10, 2017 and Carlos Garnacho committed May 25, 2017

Same story as in GtkListBox.