GitLab

It only needs to be updated in style_updated, and we do it there.

When introducing handlers for state_flags_changed in the node
transitions, chaining up was forgotten.

-gtk-icontheme: "oxygen" works now.

This is a very crude implementation. It's meant for testing only.

No need to connect a signal handler to the icon theme, we get notified
via CSS.

No need to look at the settings when the CSS has a property for the icon
theme.

If that sounds confusing, it's because GTK and CSS can sometimes not
agree on naming.

:active for CSS means that a button is currently pressed on an element.
And that is clearly not the case for spinning spinners.

It's fine to call set_state() on those.

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

This is a property for icons, so we should name it as such.

Use the equivalent gtk_icon_size_lookup() instead.

The iconfactory code doesn't use it anymore, so we don't need to track
it either.

This removes the dependency on state, which should be used for selection
CSS styles, not for actually applying them.

And image-effect does exactly what we want already, so we can start
using it.

The code isn't used anymore. Everything uses
gtk_icon_helper_load_surface() now.

This is in preparation for the next commit.

... and use it for entry icons.

As a side effect, icons dragged from entries will now resize to DND
size.

The size of icons is a property that is relevant to who is rendering the
icon, not to the icon itself.

Example: Starting a DND operation from an entry icon should cause the
icon to resize (from the entr icon's size to the DND icon size).

It now uses GtkImageDefinition instead.

This is the first step towards getting rid of pixbuf loading code in the
icon helper.

It will be used in the next patch.

Make gtk_icon_helper_ensure_surface() a private function that just
ensures the surface was loaded.

Add gtk_icon_helper_load_surface() that is called by the above function
and the dnd code to actually load the surface.

Do not assign it in the functions that actually load the surface. Make
those just return the surface.

Instead, compute it on demand.

This avoids having to cache it in lots of places and simplifies code.

Just do the invalidation check once, there's no need to do it in every
branch of the switch.

Also remove useless checks: These functions will not be called if we
already have a rendered surface.

Just do the invalidation check once, there's no need to do it in every
branch of the switch.

Also remove useless checks: These functions will not be called if we
already have a rendered surface.

Instead of just working for image surface, this should now work for all
bounded surfaces.

Test included.

We do a switch on the image type, so compute the size for a certain
image type right there.

The icon is never rendered, so there's no need for the extra iconhelper
code.

The image definition is supposed to hold the description about the image
to be displayed. The icon helper actually does caching and tracks
changes.

It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().

If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.

This reverts commit 657a43e5.

The commit breaks the assumptions about the arguments in both
gdk_pixbuf_get_from_window() and gdk_pixbuf_get_from_surface().

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

Poor gcc was unhappy.

Under X11, popovers are always constrained to the toplevel
window. Under Wayland, they aren't. This commit adds a
property that allows to explicitly constrain popovers to
the toplevel, giving them the same behavior under Wayland
as under X11.

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

These were a bit crammed, which doesn't match well with spacing used in
various other parts of gtk.

Widgets such as gtkfilechooser may be saving their size and position on
the unmap callback, if the client-side decoration header bar is removed
first, the reported size will be wrong.

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

gdk-wayland backend would not re-configure a surface when its size and
scale match the known size and scale.

But there might be a pending xdg_surface_configure() that would revert
this change so we should re-configure even if the currently known
size/scale match, otherwise we may end up with a wrong size after the
xdg_surface_configure() is received.

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

If we "release" the button first, the drag will be eventually cancelled,
we must first signal GDK_DROP_FINISHED, and then release the button so
the success status prevails.

It doesn't make a lot of sense to have this stored as data offer data,
rather together with the source_targets array, which is what we're
poking here in the end.

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

Propagates to GtkActionBar.