Many themes want to render the trough background/stroke thinner than the
full height/width (which is constructed around the value of the
'slider-width' style property).
Read and apply the CSS margin from the theme on the trough component, so
that themes can make it smaller at their will without the need to
override the render_background, render_frame and render_activity methods
of GtkThemingEngine.
https://bugzilla.gnome.org/show_bug.cgi?id=676196
Shift-click in the slider now starts a drag in 'fine adjustment'
mode, where we move the slider 10-times slower than the mouse.
This can be very helpful when scrolling through a very long document
or webpage, and moving the scrollbar even a single pixel already
jumps too far in the content.
https://bugzilla.gnome.org/show_bug.cgi?id=563688
It seems to be general consensus that button 1 should do the jumping,
so we now jump to the clicked position on primary button clicks and
page on secondary button clicks. Touch behaves like primary.
https://bugzilla.gnome.org/show_bug.cgi?id=563688
This can cause lagging when scrolling as it causes us to repaint
on every scroll event. This wasn't historically a great problem,
but with smooth scrolling we get a lot more events, so this
now creates visible lagging on slower machines.
Scroll events report normalized deltas in terms of an abstract
'scroll unit' now, so our job is to determine a suitable scroll
unit here. Since we are changing the value of the adjustment,
the allocation of the widget does not factor into this at all.
If delta_x/y information is provided in scroll events, use it
to modify the underlying adjustment in steps proportional to
the deltas provided.
If the child widget of a scrolledwindow doesn't set
GDK_SMOOTH_SCROLL_MASK, regular scroll events will be dispatched,
and still handled by these 2 widgets.
This widget is too narrow to make touch interaction tricky enough, so
don't add the penalty of having the slider run farther from the touch
coordinates if it happens to miss the slider.
The implicit grab on priv->event_window already warrants that this
widget is the only one getting events while the button is pressed,
so avoid the extra GTK+ grab here.
If the scale has an origin (it will have one by default), GtkRange will
render the two sides before/after the current value with different style
classes, making it possible for themes to use different colors and
properties for the two areas.
This was possible in GTK 2 with style details, but got lost during the
road to 3.0.
https://bugzilla.gnome.org/show_bug.cgi?id=665140
GtkRange needs to check if its allocation intersects with the resize
grip allocation (trimming its own allocation if it does).
In order to do that, it needs to translate its allocation into window
coordinates, and before that, find the window to whose the allocation
is relative; code goes all the way finding the right parent widget, but
then doesn't actually use it when translating the coordinates, leading
to using the wrong rectangles for the intersection check.
https://bugzilla.gnome.org/show_bug.cgi?id=662308
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Commit 4bb3d64414 introduced a limitation
to GtkRange style properties; when stepper-spacing is > 0,
trough-under-steppers is automatically set to FALSE; this means that
setting a spacing between the steppers (e.g. the scrollbar buttons) and
the trough (i.e. the area over which the slider is free to move) would
make the buttons always get the full allocation on the !orientation
direction.
The rationale is without this limitation, you would get an area which
seems clickable, but it's actually not.
While this is true, and undesirable, for big stepper spacings, themes
that use trough-under-steppers (which is TRUE by default anyway),
might want to set smaller spacings to avoid drawing a double line between
the button and the slider borders.
To add confusion, the documentation got it flipped, i.e. it stated
setting a positive stepper-spacing would set trough-under-steppers to
TRUE (which would also make the behavior expected by commit
4bb3d64414 impossible).
I don't think hardcoding either of the two limitations is a good thing.
We should let themes handle this instead, and remove this limitation. If
you want the old behavior, you can manually set trough-under-steppers to
FALSE if you set a positive stepper-spacing in your theme.
https://bugzilla.gnome.org/show_bug.cgi?id=644777
GtkFileChooserDefault watches the toplevel and montitors "set-focus"
signal on it... however the connection needs to be remade when the
GtkFileChooserDialog is in an embedded toplevel.
Measure's taken: GtkWindow propagates hierarchy changes when
_gtk_window_set_is_toplevel() is called, gtk_widget_unparent()
unsets the widget's parent window earlier in the function so that
the possible hierarchy change is still able to properly access the hierarchy.
GtkFileChooserDefault checks if the "new" toplevel is indeed
gtk_widget_is_toplevel() but not the old one, GtkRange has been
updated to use gtk_widget_is_toplevel() inside it's hierarhcy_changed
vfunc, other classes already do this properly.
