Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
So the slider does not overlap the value label. Since the value label is
allocated at the widget edge in gtk3, the correct fix here would
probably be to remove the 12px padding we apply to the entire scale and
instead apply it only to the trough.
The trough widgets have the slider on top of the fill level and the
hilight widget. Make sure the widget stacking respects that.
This is particularly relevant because picking event targets should pick
the slider and not the hilight widget.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
Add :dir(ltr) where expected, i.e. everywhere we now have a widget but
had a gadget before.
Also, fix the expected output to expect mark subnodes in the order
specified in the GtkScale does, i.e.
├── mark
├── [label]
╰── indicator
for marks at the top of the scale and
├── mark
├── indicator
╰── [label]
For marks at the bottom of the scale.
This previously only mentioned its effect on the displayed value, and
even after the previous commit, its rounding of the actual value upon
change still reads like too much of an afterthought. Worse, it wasn’t
mentioned at all in the doc for the @digits parameter. Change this to
emphasise rounding always occurs and the displayed value is secondary.
Whether it should is an open question, but for now, the documentation
should clearly indicate that currently rounding is only applied upon
changes to the value, not to the existing value when ::digits changes.
This is already clear in the doc for the underlying Range::round-digits.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
The documents state that gtk_scale_set_digits() “causes the value of the
adjustment to be rounded off to this number of digits, so the retrieved
value matches the value the user saw.” Note the lack of any condition.
But in fact, if draw-value was false, rounding was disabled on the base
Range, so values that weren’t displayed weren’t rounded. This made the
docs wrong and made an apparently cosmetic detail alter functionality.
Fix by ensuring the number of digits set on Scale is always propagated
along to gtk_range_set_round_digits(), thus rounding to it in all cases
when the value changes, regardless of whether the value is displayed.
This doesn’t address the other idea from Bugzilla: that changing the
number of digits should clamp the _existing_ value if it’s more precise.
This contradicts digits docs in the base Range, but the above from Scale
can be read as implying it’ll happen. For now, that’s an open question.
https://bugzilla.gnome.org/show_bug.cgi?id=358970
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.
Use .marks-before/after to indicate the presence of marks.
As Lapo points out, compatibility with the previous names
is not really that important, since everything else changed
around it.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
It turns out that it is too hard (and in some cases, impossible)
to get this information from node positioning, so bring back the
.scale-has-marks-above/below style classes on the main node.
This should allow us to fix the 'pointy sliders'.
https://bugzilla.gnome.org/show_bug.cgi?id=766440
We're measuring both the width of the minimal and the maximal value for
the value gadget, but only give the value the minimal width for its
current value, resultnig in an always left-aligned value.
Fix this by assigning the width of the value gadget to the value layout
and letting pango align the text inside the layout.
https://bugzilla.gnome.org/show_bug.cgi?id=766120
if (orientation) doesn't make a lot of sense but C doesn't complain and
instead evaluates orientation to TRUE for GTK_ORIENTATION_VERTICAL
(since that's 1), thus inverting the value sizes.
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.
Try harder not to push the scale out of balance by marks. With
this change, the remaining difference in the drawing is down
to asymmetric assets and margins coming out of the theme.
To fully support such asymmetric rendering, we need implement
baseline alignment for scales.
https://bugzilla.gnome.org/show_bug.cgi?id=749650
We don't want scale marks to affect scale sizing and positioning,
so draw them inside the range recangle. This avoids size changes
for marks that don't have labels, at least.
https://bugzilla.gnome.org/show_bug.cgi?id=749650
Instead of issuing g_warning, fill the provided GError.
This lets us test this error handling, and is the right
thing to do. Use the new GtkBuilder helpers and
g_markup_collect_attributes to do so.
