On some systems, the gtk settings are not used properly for wayland.
Indeed, g_settings_schema_source_get_default is used, and as the docs says it,
"all lookups performed against the default source should probably be done
recursively.".
https://bugzilla.gnome.org/show_bug.cgi?id=759409
Remove some now unused includes and dead code, and rename
gtk_drag_set_icon_window to gtk_drag_set_icon_widget_internal,
since it is no longer restricted to toplevel windows.
Under Wayland, the compositor does it, so there is no need
for us to move the window ourselves. For X11, we are now
doing the animation from the X11 backend. Trigger that by
calling gdk_drag_drop_done().
What changes here is that we have to keep the icon_window
alive for as long as the drag context exists. Use a weak
reference to do so.
Showing the drag cancel animation can be done in the X11
drag context implementation now that we hold the drag
window there, and have the start coordinates.
Since we can't control if and when the application destroys
the drag widget, we take a snapshot of the window contents
and display that during the animation. This should be good
enough for all practical purposes.
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
In commit 2c61316677 we avoided emitting
the style-changed signal if no CSS property changed.
Unfortunately, this also caused CSS styles to not be updated when
animations started if those animations did not change any CSS value
immediately. In those cases the animation would just never start.
The obvious example was the spinner.
Catch the case where a CSS style did not change and don't emit the
style-changed signal in that case.
This saves not only the emission of the signal, but also doesn't cause
invalidation in child nodes, which would previously get a PARENT_STYLE
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
We were only storing the dialog size on unmap, but resetting to the
stored default value more often, e.g. on focus-out. This was causing
the dialog to 'jump back' to its remembered size after the user
manually resized it, leading to frustration and bug reports.
Instead, save the dialog size on every ::size-allocate of the toplevel.
To avoid needlessly spamming dconf, only write the new value if it
changed.
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
...in the process simplified the touch-selection styling, check
and radios not fixed there since I'm going to add proper osd assets
for those (istead of forcing the dark variant assets there as before).
