| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
And of course Scrollbar, but that one does no drawing itself.
|
|
|
|
|
|
| |
See https://developer.gnome.org/hig/stable/typography.html
https://bugzilla.gnome.org/show_bug.cgi?id=772371
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This was causing warnings in HighContrast.
https://bugzilla.gnome.org/show_bug.cgi?id=770614
|
|
|
|
|
| |
glib will use the correct marshaller automatically. And as a side
effect, we also get all glib optimizations, like a va marshaller.
|
|
|
|
|
|
|
|
| |
This is a long-standing problem of GtkScale.
https://bugzilla.gnome.org/show_bug.cgi?id=766372
https://bugzilla.gnome.org/show_bug.cgi?id=578626
https://bugzilla.gnome.org/show_bug.cgi?id=79229
|
|
|
|
| |
This is the right place for this.
|
|
|
|
| |
Make sure it's obvious what if block it belongs to.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Simplify code and remove the mouse location indirection.
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Depreacated -> Deprecated
through -> trough
|
|
|
|
| |
Make sure the color info is actually drawn inside the trough.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
The function queues an allocation now, not a draw.
|
|
|
|
| |
This is already called by range_grab_add().
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Where they're needed.
|
|
|
|
| |
Instead of making it dependent on the slider size.
|
|
|
|
|
|
| |
Since it causes problems with event coordinates.
This reverts commit 0883ff5eedf73b1197f2a49fb7e55ce227917335.
|
|
|
|
|
| |
This can happen if the theme sets a negative margin, but the coordinate
should never be negative.
|
|
|
|
| |
We're going to modify this in the next commit.
|
|
|
|
| |
The slider is not HFW/WFH - just pass -1 to get rid of the warnings.
|
|
|
|
| |
Requested by Lapo.
|
|
|
|
|
| |
The border is typically part of the reactive part of the widget. This
matches the pre-gadget behavior.
|
|
|
|
|
|
| |
We create and destroy gadgets inside the range hierarchy here,
and if we don't explicitly remove their CSS nodes from the parent,
they stick around.
|
| |
|
|
|
|
| |
This is so that e.g. the focus ring is drawn under the slider.
|
|
|
|
|
| |
Just draw the slider, since that is the only thing GtkColorScale cares
about.
|
|
|
|
| |
Nothing uses these functions inside GTK anymore.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Instead of directly accessing the widget allocation, we can use the
gadget API to test whether the coordinates are in the main gadget.
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Marks are always either the first or the last child of the scale.
|
| |
|
| |
|
|
|
|
|
| |
The slider gadget is a child of the trough gadget, so draw it from
there.
|