GitLab

This is generally expected of containers where it makes sense.

Implement request modes fully.

We expand the center child first, but only as far
as we can keep it centered.

Make it possible to fill the slots by using the
type attribute on child nodes. This is necessary
since GtkCenterBox does not derive from GtkContainer.

We prefer to give the center widget its natural size,
and we center it as long as possible.

Any slot may be unfilled, not just the center one.

It provides functionality that GtkBox used to have,
and is generally useful.

Otherwise things will not work in a release tarball.

These have appeared recently.

Use 48x48 in the list, instead of 32x32. We have the space.

This makes it more obvious how to use the icon.

Instead of hardcoding all the add_icon calls,
read the icon list from a keyfile, for easier
extensibility.

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

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.

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.