Just queue_resize()ing the range itself doesn't work as it will just
re-allocate all the child widgets (i.e. just the trough) to its old
position and size.
We want to ensure all of the display cache entries are released in the
normal fashion before releasing the structures so that we can maintain
the invariant that cache_iter will always exist while in the cache.
This is happening for me when snapshotting small thumbnails in the file
chooser. The GtkScaler will scale the 1px height/width by 2, resulting
in nothing being drawn at all.
There is no reason for this to be a signal, since multiple handlers
don't make sense anyway. It was also broken because the scale needs to
know when a signal handler is added so it can update the value
representation.
Replace the signal with a set_format_value_func function which allows us
to do that.
Fixes#113
When loading a SVG icon from a gresource file only containing SVG icons,
but without having a SVG loader available in gdk-pixbuf, we would crash
when trying to eventually load the resource. Fix this by gracefully
handling this by simply failing to load the icon, while the first time
it happens, log a warning.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2084
- use even sides for the titlebuttons so the result is a circle and not an ellipse
- add maximum border radius
- set min width/height to 0
- adjust margin and padding to match the previous look
GtkFileChooserNativeWin32 is created and shown on a secondary thread.
This thread initializes COM support with CoInitializeEx but does not
finalize it, so we have a leak. Fix that by calling CoUninitialize()
before thread terminates.
See Merge Request !1043
Although slightly less efficient, keeping the order in the choices
list makes it easier for GtkFileChooserNative implementations to
add widgets in the order specified by the application.
See Merge Request !1043
When processing the list of icons for a window to add them to
_NET_WM_ICON gdk_x11_surface_set_icon_list only adds as many
icon sizes as will fit within X protocol limits.
It achieves this by keeping a running total of the number of
bytes taken up by icons already processed and bails as soon
as it goes over the limit.
The problem is, one 512x512 icon is already over the limit,
and so no icons will get added at all if the first icon in
list is 512x512.
Indeed, the code seems to assume the list is sorted from smallest
icon to biggest icon.
This commit changes the caller to sort the list.
