We only keep one align flag per child, so it seems odd to
keep separate h/v expand flags. Just keep one expand flag
and interpret it according to orientation. Allow setting
the expand flag for child widgets too, though, so we can
make widget expand without interfering with the recursive
widget expand flag.
Update all callers.
Use the new possibility of expanding child widgets to make
the label of check and radio buttons expand. This fixes
unexpected behavior of these widgets in RTL in some places.
https://bugzilla.gnome.org/show_bug.cgi?id=765742
Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
We previously considered any click inside the trough if it
hit an area that the slider might cover. Bring this behavior
back; the trough of scales is otherwise just too narrow to
hit easily with a click.
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.
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.
The way this method is used from the GtkRange subclasses doesn't really
work well when the slider properties change as a consequence of e.g. a
style class being applied (e.g. the fine-tune style class).
In fact, there's no need to read the minimum slider size out of band,
and we can obtain the same result in a way that always work by setting a
private property on GtkRange.
Since we can use negative margins, we should not use the margin box
for the slider area. Use the border box instead, since that's what is
typically mapped to the visible area.
This commit introduces another node, called "contents", that holds the
main contents of the range. This allows for the main gadget itself to
span across the whole surface of the widget now.
And reset the grab_location in the ::released handler of the multipress
gesture.
Previously, when leaving fine-tune mode, the ::released handler of the
multipress gesture would call stop_scrolling, which calls
range_grab_remove and resets the grab_location. The ::drag-end handler
is executed after that, and only unsets priv->in_drag if the
grab_location is MOUSE_OUTSIDE, which it never was, since the ::released
handler already reset it. This lead to priv->in_drag being set even
though no dragging was in progress anymore, which e.g. made shift
pressed after leaving the fine-tune mode entering it again.
https://bugzilla.gnome.org/show_bug.cgi?id=761402
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.
Use G_PARAM_DEPRECATED with deprecated style properties.
This will make it easier to identify and remove such stale
properties from css, since it will now trigger warnings.
The introduction of the trough node was not properly carried
into the code constructing stepper nodes, and was causing
assertion failures there. This was only showing up on Windows,
since Adwaita and HighContrast don't have steppers.
We were not queuing a draw (and not updating the CSS node) when
the slider visibility changed. This was exposed by the Trough
button in tests/testscale.
Fix this by taking slider visibility into account when deciding
whether to queue a draw in response to adjustment changes.
Change things around so that warp-to-click and jump-by-pages are
bound to left-click and shift-left-click, depending on the value
of gtk-primary-button-warps-slider. Autoscrolling is bound to
right-click.
To achieve this, reorganize gtk_range_multipress_gesture_pressed
so that the functions are clearly separated.
Make shift right-click on the trough start autoscrolling. The
autoscrolling is similar to the way steppers operate now, with
the difference that we vary the scrolling speed based on the
distance of the pointer from the widget.
Clicking on steppers does different things depending on which
button you use. We used to scroll to the end on secondary click
and use high-speed autoscrolling on middle-click. Switch these
two around, since the scroll-to-end functionality is less likely
to be useful, and the seconary button makes the autoscrolling
more easily available.
The calculation to update the initial slider position on zoom
changes was not working correctly when using keys to toggle
zoom on and off for scales. Avoid it by updating the position
beforehand.
Moving the mouse while pressing one of the steppers was making
the slider jump to the end, unexpectedly. This was caused by the
drag gesture kicking in when it shouldn't. Fix this by making
all drag gesture signal handlers only do something if we are in
a drag thats started on the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=751050
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Compute the proportion of the range that should be filled to match the
fill level, and use it to compute the starting point and length of the
area between the slider and the fill level.
https://bugzilla.gnome.org/show_bug.cgi?id=734741
As Sebastian pointed out, just resetting the initial slider
position was an incomplete fix, because it does not cause the
delta to be recomputed, which is important in this scenario,
because you've likely travelled some distance over the slider
before the long press kicks in.
Instead, explicitly record both the slider position and the
delta.
We record the starting position on button press, but only
start the zoom mode when the long press timeout kicks in.
Depending on circumstances, this can cause a noticable jump.
Avoid this by resetting the recorded starting position after
the long press timeout. Suggested by Sebastian Keller.
