Without enforcement to the expander-size, we can end up rendering icons
rather fuzzy. This uses the expander-size style property to determine
the square for the icon, centered on what was the calculated space for
the expander.
The 'gtk-fontconfig-timestamp' and 'gtk-modules' settings are
currently not available at all on Wayland. On X11, they are
implemented through xsettings maintained up-to-date by
gnome-settings-daemon.
This patch implements both GtkSettings for Wayland using a
new dbus interface also provided by gnome-settings-daemon.
Closes#886
X uses unscaled sizes, so they must be scaled properly. Otherwise
GtkSockets end up twice as big as they should be.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=765327
Signed-off-by: Jason Zaman <jason@perfinion.com>
Close!165
:climb-rate is not about what you get when you single-click on a button,
as this implied: it's what happens if you hold down a button or a key.
Fix the description of @climb_rate to new(), and while here, mention the
key in the blurb of :climb-rate itself.
gdk_wayland_*_grab()/ungrab() would emit crossing events which translate
as focus_in/focus_out events for keyboard.
However, the ungrab() functions compare the native toplevel as this is
what gets the Wayland pointer enter/leave events with the grab window,
so if the grab is issued on a child gdk window, those won't match and we
would emit more focus_out events than focus_in events.
This means that a widget such as spice-gtk which issues a keyboard grab
whenever the pointer enters the window and releases the grab when it
leaves the window would get uneven numbers of focus_in/focus_out events.
Also, gdk_wayland_seat_ungrab() would not emit crossing events for
keyboard devices, whereas gdk_wayland_device_ungrab() does, which adds
even more potential discrepancies between focus_in/focus_out events.
To solve this problem, introduce two new helper functions which check
the relevant native windows to emit crossing events when needed that get
called evenly from both gdk_wayland_seat_grab()/ungrab() and gdk_Wayland
_device_grab()/ungrab() APIs.
Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=780422
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/792
X uses unscaled sizes, so they must be scaled properly. Otherwise
GtkSockets end up twice as big as they should be.
Closes: https://bugzilla.gnome.org/show_bug.cgi?id=765327
Signed-off-by: Jason Zaman <jason@perfinion.com>
We've had it for a long time, and it hasn't really made
a difference. And I don't think we are prepared to turn
this into a hard error. So just drop it.
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
The last round of patches to get the desired direction of value move in
response to scrolls/keypresses on scales had the inadvertent side effect
of giving the opposite direction on scrollbars. Seeing as gtkrange.c is
already a collection of hacks, add another so that fix only holds if the
instance is a GtkScale, since that is what those patches were aimed at.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1065
These can't be returned as part of the font description,
so we need new api for them. For now, this is just readonly
properties. Maybe these should be writable too, eventually.
GtkTextView scrolls to the insertion point when the text
buffer signals a paste is done. This is wrong when there
are multiple views on the same buffer, and the paste
happened in another view.
To fix this, flip the handling of the scroll_after_paste
boolean to only be TRUE if we know that we want to scroll.
