https://bugs.kde.org/show_bug.cgi?id=443608
Bug ID: 443608
Summary: Manual position entry disregards fractional part if
the decimal separator is not a dot
Product: systemsettings
Version: master
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: kcm_nightcolor
Assignee: plasma-b...@kde.org
Reporter: bugs....@maxmitti.tk
CC: kwin-bugs-n...@kde.org
Target Milestone: ---
Created attachment 142341
--> https://bugs.kde.org/attachment.cgi?id=142341&action=edit
Input before pressing apply and switching module
When the Night Color activation time is set to “Sunset to sunrise at manual
location”, I can enter the longitude and latitude including a fractional part
but the fractional part is ignored and will be disregarded when switching to
another settings module and back. This is because my locale use comma (“,”) as
decimal separator.
STEPS TO REPRODUCE
1. Set numbers format to German (mine is Austrian German or “Österreichisches
Deutsch”) and relogin to apply changes.
2. Set Night Color activation time to “Sunset to sunrise at manual location”
3. Enter latitude and longitude with comma as decimal separator. E.g. “47,5” /
“11,5” and apply. Note that dots can not even be entered.
4. Switch to Compositor settings (or any other module) and switch back.
OBSERVED RESULT
Latitude is set to 47 and longitude to 11.
Also the calculated times correspond to these values.
EXPECTED RESULT
Latitude stays set to 47,5 and longitude to 11,5.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
ADDITIONAL INFORMATION
The bug happens due to the use of JavaScript’s parseFloat, which only parses
floats with dot as a decimal separator, here:
https://invent.kde.org/plasma/plasma-workspace/-/blob/master/kcms/nightcolor/package/contents/ui/NumberField.qml
lines 25 and 33.
Replacing all commas with dots before calling parseFloat fixes the problem
mostly. However this is only a dirty workaround.
Additionally the conversion from float to text on line 21 also has to be
adjusted, otherwise the input behaves funnily in some cases.
In general, I am quite sure that the correct fix is to replace float-string
conversions in both ways (lines 21, 25 and 33) with locale aware variants.
Note: While I am using the versions specified above obtained via Archlinux
Packages the bug is obviously still present on master at the time of reporting.
--
You are receiving this mail because:
You are watching all bug changes.
