After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777858 - gtk_sca_set_draw_value(.., FALSE) changes snap points
gtk_sca_set_draw_value(.., FALSE) changes snap points
Status: RESOLVED DUPLICATE of bug 358970
Product: gtk+
Classification: Platform
Component: Widget: GtkRange
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-01-27 22:24 UTC by Bryant
Modified: 2017-01-27 22:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bryant 2017-01-27 22:24:18 UTC
For this project I've been using the Rust bindings (relevant ticket here: https://github.com/gtk-rs/gtk/issues/432), but it doesn't appear to be related to those and instead be a backend issue.

What's happening is that if I create a GtkScale like so:

GtkScale *scale = gtk_scale_new_with_range(GTK_ORIENTATION_HORIZONTAL, 1.0, 2.0, 1.0);
gtk_scale_add_mark(1.0, GTK_POS_BOTTOM, "1");
gtk_scale_add_mark(2.0, GTK_POS_BOTTOM, "2");

Everything works as expected, where the scale has limits at 1.0 and 2.0 and the snap is to those two locations.

Now if I change things by adding a `gtk_scale_set_draw_value(scale, FALSE)`, the snap points are no longer to 1.0 and 2.0 and instead the slider can be placed anywhere in between.

And calling `gtk_scale_set_digits(.., 0)` doesn't fix the solution while set_draw_value is still called with `FALSE`.

But a kind-of work around is to not call `gtk_scale_set_draw_value(.., FALSE)` and instead do both `gtk_scale_set_digits(.., 0)` and connect the `format-value` signal to return just an empty string, but then there's a bunch of space above the slider that's just empty.
Comment 1 Daniel Boles 2017-01-27 22:27:55 UTC
This was fixed by commit 4a6bd134bdc192b4830a1c6228e27332d4629418 in 3.20, 3.22, and master (4).

*** This bug has been marked as a duplicate of bug 358970 ***
Comment 2 Daniel Boles 2017-01-27 22:29:51 UTC
To clarify, the issue isn't the marks; it's that the number of rounding digits was not applied on change of value when property draw-value was false.
Comment 3 Daniel Boles 2017-01-27 22:34:43 UTC
(In reply to Daniel Boles from comment #2)
> To clarify, the issue isn't the marks; it's that the number of rounding
> digits was not applied on change of value when property draw-value was false.

...and my preferred workaround until this hits my distro is to call set-digits directly on the base Range, rather than the Scale. This fixes the rounding of the value, albeit not the default format-value handler, but I almost never use that anyway.