https://bugs.kde.org/show_bug.cgi?id=398405
TallFurryMan changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #15 from TallFurryMan ---
One first step towards fixing this is in https://phabricator.kde.org/D15492
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #14 from TallFurryMan ---
Preliminary work in the Capture module at
https://github.com/TallFurryMan/kstars, branch
improve__support_decimal_locales.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #13 from Jasem Mutlaq ---
I believe lilXML only supports C locale but I could be wrong. QXMLStreamWriter
could be used to replace any use of lilXML in KStars. It was just that lilXML
was easier to use since it was in INDI, and I don't
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #12 from TallFurryMan ---
I'm planning to:
- replace atof calls used to read XML numbers, which use the system locale,
with QLocale::C string-to-type functions.
- make sure QString calls used to write XML numbers use the QLocale::C
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #11 from TallFurryMan ---
XML files are saved with the system locale, and loaded with no locale. This
issue is in Scheduler and Capture modules. Besides, all control texts need
rework to take locale into account properly.
--
You are
https://bugs.kde.org/show_bug.cgi?id=398405
TallFurryMan changed:
What|Removed |Added
CC||mutla...@ikarustech.com
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=398405
TallFurryMan changed:
What|Removed |Added
Assignee|mutla...@ikarustech.com |eric.dejouha...@gmail.com
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #10 from TallFurryMan ---
I think the issue has been there for a long time actually. Besides, it might
evantually relate to the issue forum user alacant had.
Tested with target "NGC 281", created a scheduler job, saved, loaded XML file,
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #9 from TallFurryMan ---
On my system, QString("%L1").arg(float_var) with float_var does produce "1,2",
while QString("%1").arg(float_var) does produces "1.2".
I'm checking where all this should be used. I'll try to use the english locale
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #8 from Jasem Mutlaq ---
I actually tried %L and it had no effect.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #7 from TallFurryMan ---
Read some Qt docs, and found the problem: all of our arg() and number() calls
basically ignore locale. To properly support that, we can use "%L1" instead of
"%1" for a float number for instance, or use toString(),
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #6 from Jasem Mutlaq ---
I changed toDMSString in dms.cpp to this:
QString dummy;
char pm(' ');
QChar zero('0');
int dd = abs(degree());
int dm = abs(arcmin());
int ds = abs(arcsec());
if (Degrees() < 0.0)
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #5 from TallFurryMan ---
Coordinates end up "HH MM SS.SS" after conversion instead of "HHh MM' SS,SS""
in the RA/DEC boxes, and the "." character is not recognized properly, leading
to offset'd positioning afterwards. With my locale, "."
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #4 from TallFurryMan ---
I reproduced the issue is more serious than I thought. The bug appears (also?)
in the .esl load procedure! Could this be a regression introduced by the
copy of coordinates? This was working properly during August.
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #3 from TallFurryMan ---
Issue might be related to QString::toDouble in dms::setFromString.
Documentation in Qt11 doesn't mention any locale issue, so perhaps this is a
version compatibility problem?
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #2 from TallFurryMan ---
This seems proper indeed. Issue must be elsewhere, let me provide a scenario.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=398405
--- Comment #1 from Jasem Mutlaq ---
This is what is used:
raBox->setText(object->ra0().toHMSString(false, true));
decBox->setText(object->dec0().toDMSString(false, false, true));
So these function are not producing the correct results? Both above
18 matches
Mail list logo
