GNOME Bugzilla – Bug 789591
Does not accept doubles with two decimal places
Last modified: 2017-11-25 14:06:43 UTC
Go to a value of type "double", such as e.g. /org/gnome/desktop/peripherals/touchpad or /org/gnome/desktop/interface/text-scaling-factor. The value is shown with two decimal places, e.g. "1.00". Type a new value with at most one decimal place, e.g. "1.1". Press Enter or click Apply. The value is accepted (if within the Min..Max range), as expected. Type a new value with 2 or more decimal places, e.g. "1.25". Press Enter or click Apply. The previous value is restored in the text box, the new one is not applied.
Note: It works if you press the +/- buttons to reach the desired number. For the bug to occur, it's important that you type the new value from the keyboard.
Hi, thanks for taking time to report bugs. I can’t reproduce here, but seeing the screenshots you posted on GitHub, looks like you’re using a version maintained by the Mate desktop, based on 3.18 or such. I’ve more or less rewritten all since then (circa 2015…), to have a solid application, with few bugs and many facilities. Honestly, I’m not really motivated to work again on that buggy and hacky code. I’ll happily explain as much as I can the underlying concepts of dconf/gsettings if it can help, but here, if I remember correctly, that’s “only” a Gtk+ weird thing of GtkSpinButton not handling easily doubles. Good luck on working on that!
I didn't post any screenshots anywhere. I've no clue what you're talking about. I'm using Ubuntu Artful; Unity 7; dconf-editor 3.26.1. Please don't close as NOTGNOME. If you're certain that this is a bug in GTK+, please reassign to them.
Oops, sorry. I have been directed to a GitHub bug at the same time I was reading yours, and my little brain thought you were the same person. Sorry. Anyway, I had tested and just tested again (‘double’-values are always source of bugs, and I already have some TODOs about it), and I cannot reproduce. And I don’t really see what could cause such a bug on some computer and not on some other. Can you reproduce with “/ca/desrt/dconf-editor/demo/double”?
Yup, same story with that value. Initially I can see: Default 3.1415926535897931 Current value Default value Use dfault value ON Custom value 3.14 (inactive) I click on the slider, it becomes "OFF" and the input field "3.14" becomes active. I type 2.71 and press Enter. Current value changes to 3.1415926535897931, Custom value changes to 3.14. Then I type 2.7 and press Enter Current value becomes 2.7000(many zeros)02 (that's okay), Custom value becomes 2.70. I have to correct myself a bit: 3 or more decimal digits (after the decimal dot) are usually accepted. Exactly 2 decimal digits (after the dot) is also sometimes accepted (typically after setting a value of 3 digits), but usually not. The behavior is not fully deterministic, suggesting something really nasty going on to me (memory overrun or uninitialized variable or alike). One more thing: when a value is refused, the previous value gets rounded to 2 digits. E.g. type "2.718", Current value becomes 2.718, Custom value becomes 2.72. Now type "3.14", Current value becomes 2.72000(many zeros)02, Custom value reverts to 2.72. --- Also refused, but that can be another issue: negative numbers (even the "-" button doesn't take you there), or the exact number 0 (the "-" button takes you as close as Current value: 2.22e-308, Custom value: 0.00). --- Reproducible with LC_ALL=C so it's not a weird locale issue (decimal comma or whatever). Do you suspect a GTK+ bug? I have 3.22.24 along with whatever patches Ubuntu has.
Haha. That’s a weird locale issue. Works as expected in LANG=fr_FR and LANG=fr_FR.utf8, fails as described in LANG=C. The bug might be in dconf-editor, or in Gtk+ (without Ubuntu patches); let’s hope it’s in dconf-editor, as it will then be easier to correct.
Hmmm, indeed, nice catch. (It didn't occur to me that a somewhat special locale could _fix_ it rather than _break_ it.) With C, C.UTF-8 and en_US.UTF-8 (decimal dot) it fails as described. With fr_FR.UTF-8, it_IT.UTF-8 and hu_HU.UTF-8 (decimal comma) it works as expected if you type the new value using a decimal dot, but fails as described if you enter it using a decimal comma.
I gave up using a spinbutton for double values[1]. That’s not the perfect end for this story, but it should be good enough as the double type is not so commonly used. There’s now a warning explaining to write “with a dot” and “without thousands separator”, and more or less all values could now be written with a correct precision. As that’s an UI change, I won’t fix the 3.26 branch of DConf Editor; the fix will be available in 3.28, that will be released in March 2018. Thanks for the bug report! [1] https://git.gnome.org/browse/dconf-editor/commit/?id=c0eb038640e436bee78239867ec736d2cd767db7