The adjustment double properties allow values from -G_MAXDOUBLE
to G_MAXDOUBLE, which leads to overflow when calculating
max - min / 10. To avoid that, simply use a fixed page_size of 1.0.
The contents node was not getting state updates at all, and the
trough node was missing some state updates as well, because we
were not calling update_trough_state() in all the places where
it is needed.
...hopefully when needed.
By default I assume a left hand side placement on ltr languages
and the opposite in rtl, for other placements left/right style
classes can be used.
Under Wayland, popovers use subsurfaces, and we end up getting
configure events for these delivered to the toplevel they're in.
To avoid triggering resize loops, ignore configure events that
are not for the toplevel window itself.
https://bugzilla.gnome.org/show_bug.cgi?id=763351
The default value for the double-click key in the
org.gnome.settings-daemon.peripherals.mouse schema is 400.
Use the same value as the declared default for the
gtk-double-click-time GTK+ setting, to avoid pointless
differences in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=720950
The sidebar in the object page was using up more space than it deserves.
Replace it with a combo box in the subheader. Now that we have more space,
put the CSS node tree and the style properties in the same page again.
And add a default color like it was before.
This also fixes other issues with scale values interacting with scale
mark labels, which were buggy at least since 3.18.
When opening the value editor for any GtkAdjustment properties
in the inspector, the popover stretches out for miles, since
it reserves enough space to draw MAXDOUBLE. This is not useful.
Limit the space we reserve to 8 digits.
We're seeing loops where the size of some status icons constantly
dithers between 24 and 25. Since I couldn't track down exactly
where the one extra pixel comes from, just stop reacting
to single-pixel size changes.
https://bugzilla.gnome.org/show_bug.cgi?id=758893
We used to always make the labels in message dialogs selectable,
which is a bit problematic wrt. to keynav - the label can
unexpectedly 'turn blue', which irritates some people.
With the new gtk-keynav-use-caret setting, we can now only
make the labels selectable when it is required for accessibilty
reasons.
When changing tool button contents according to the toolbar-style
property, we need to update the style classes to ensure that the
visual style matches.
https://bugzilla.gnome.org/show_bug.cgi?id=760560
gnome-session takes an "app id" for client and inhibitor registration,
This app id is supposed to be a desktop file id (complete with the
.desktop extension), but gtk+ currently uses g_get_prgname ().
This commit changes gtkapplication to use the application id instead,
which is a much more natural fit. gnome-session is going to be updated
to stop using the .desktop extension, too, so everything is consistent.
https://bugzilla.gnome.org/show_bug.cgi?id=763106
We weren't using the open flags on the other locations signal, which
makes impossible for applications like nautilus to act in the same
way that for any other location where the user can choose between
opening in the current view, in a new window or in a new tab.
Add a new signal with an open flags parameter and deprecate
the other-location signal.
https://bugzilla.gnome.org/show_bug.cgi?id=754743
