10110111
commented
2 days ago Stellarium version: <Name of downloaded installable file?> Operating system: <Name, version number>
These should have been filled in.
Open Hamousher opened 2 days ago
10110111
commented
2 days ago Stellarium version: <Name of downloaded installable file?> Operating system: <Name, version number>
These should have been filled in.
Hamousher
commented
2 days ago Hi I have tried ver 24.2 -qt6-win64 and an earlier version my wife has this version which is ok so I copied to my pc which still has the same fault and my desktop is running windows10 pro ver 22H2 OS build 19045.4598 PC is a lenovo m900 tower Intel i7-6700 CPU 3.4ghz with 32 gb memory and Radeon RX6400 gpu 4gb memory 64 bit.
Regards David
On Sun, 30 Jun 2024 at 08:58, Ruslan Kabatsayev @.***> wrote:
Stellarium version: <Name of downloaded installable file?> Operating system: <Name, version number>
These should have been filled in.
— Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/3791#issuecomment-2198445064, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXT2B36PB2WBIBUIXJNCWTZJ6NCFAVCNFSM6AAAAABKDZHYVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGQ2DKMBWGQ . You are receiving this because you authored the thread.Message ID: @.***>
gzotti
commented
2 days ago What is your operating system language set to? Can you think of any other reason that a system-provided date dialog shows Arab numbers? If not,
attach the logfile log.txt from your user data directory. Look into the Guide for its location.
Hamousher
commented
1 day ago Hi Georg, OS language is English UK and options English US and Bulgarian. The characters appearing in Stellarium are Persian numbers only and there would be no reason for me to use them. Maybe some code in the software is corrupted in relation to the language to use in the boxes that require a numerical code. With regard to the log, I have searched the complete computer and there is no log.txt file. I have even checked all the files in Users \David manually. In the Stellarium program there is a log. The only way I could send this is to do multiple screen shots, unless there is a way to copy it from the app.
Regards David
On Sun, 30 Jun 2024 at 23:08, Georg Zotti @.***> wrote:
What is your operating system language set to? Can you think of any other reason that a system-provided date dialog shows Arab numbers? If not,
attach the logfile log.txt from your user data directory. Look into the Guide for its location.
— Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/3791#issuecomment-2198695330, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXT2B3OJSZBDQIMOTH2XPLZKBQTBAVCNFSM6AAAAABKDZHYVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGY4TKMZTGA . You are receiving this because you authored the thread.Message ID: @.***>
Hamousher
commented
1 day ago Hi George, I have managed to get setup in the observatory and have a log file attached regards David
On Mon, 1 Jul 2024 at 05:42, David Hamilton @.***> wrote:
Hi Georg, OS language is English UK and options English US and Bulgarian. The characters appearing in Stellarium are Persian numbers only and there would be no reason for me to use them. Maybe some code in the software is corrupted in relation to the language to use in the boxes that require a numerical code. With regard to the log, I have searched the complete computer and there is no log.txt file. I have even checked all the files in Users \David manually. In the Stellarium program there is a log. The only way I could send this is to do multiple screen shots, unless there is a way to copy it from the app.
Regards David
On Sun, 30 Jun 2024 at 23:08, Georg Zotti @.***> wrote:
What is your operating system language set to? Can you think of any other reason that a system-provided date dialog shows Arab numbers? If not,
attach the logfile log.txt from your user data directory. Look into the Guide for its location.
— Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/3791#issuecomment-2198695330, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXT2B3OJSZBDQIMOTH2XPLZKBQTBAVCNFSM6AAAAABKDZHYVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGY4TKMZTGA . You are receiving this because you authored the thread.Message ID: @.***>
Writing log file to: C:\Users\David Hamilton\AppData\Roaming\Stellarium\log.txt File search paths: [0]: C:\Users\David Hamilton\AppData\Roaming\Stellarium
Config file: C:\Users\David Hamilton\AppData\Roaming\Stellarium\config.ini
Default surface format: QSurfaceFormat(version 2.0, options QFlags
alex-w
commented
1 day ago Hmm... Qt ignore language settings for "inner" Qt UI elements like calendars
github-actions[bot]
commented
1 day ago Hello @Hamousher!
OK, developers can reproduce the issue. Thanks for the report!
Hamousher
commented
1 day ago so, its not just the calender that is the problem all the boxes that need a numerical value are also showing Persian or Farsi numericals and the telescope mount does not operate from the Stellarium app. On disconnecting the cable to the synscan hand control from the pc and connecting to an adjacent laptop it all works just fine
gzotti
commented
1 day ago We know there are issues with the telescope plugin on Qt6-based builds. (See release notes and FAQ.) Do you say that the Arab numerals show up only when your telescope is actually attached (at least cable-connected)? Does it work OK (show European numbers) when you have the Telescope plugin active, but no telescope plugged in?
Hamousher
commented
18 hours ago Good morning Georg, the arab numerals are on the app when the telescope is attached or not, so all the time. When the cable is connected the telescope does not work and it does not matter the arab numerals are there all the time. Yesterday I took the pc and laptop to the observatory, using the same telescope and cable the laptop worked fine, found the moon on the app and selected it then slew the telescope which then tracked the moon. Disconnected the cable from the laptop and plugged it into the pc, found the moon and selected it but no bullseye for the telescope though the app says it was connected and the telescope remained stationary. I have used the pc with the same telescope and cables previously with an earlier version of stellarium and it worked ok!! I have now deleted the app several times and re installed and the same results. I have two telescopes both with RS232 and cables and have tried both cables and RS232 But cant try the other telescope as it has ZWO system with guide and main camera and EAF on the focuser Please note I will be unable to carry out any more tests for 1 week as we are going away for a few days Regards David
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail Virus-free.www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Tue, 2 Jul 2024 at 01:19, Georg Zotti @.***> wrote:
We know there are issues with the telescope plugin on Qt6-based builds. (See release notes and FAQ.) Do you say that the Arab numerals show up only when your telescope is actually attached (at least cable-connected)? Does it work OK (show European numbers) when you have the Telescope plugin active, but no telescope plugged in?
— Reply to this email directly, view it on GitHub https://github.com/Stellarium/stellarium/issues/3791#issuecomment-2201177761, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAXT2BY2KLTCVZEOZCHFOZ3ZKHIVXAVCNFSM6AAAAABKDZHYVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBRGE3TONZWGE . You are receiving this because you were mentioned.Message ID: @.***>
gzotti
commented
15 hours ago OK, then these two are at least unrelated. This would have been really weird voodoo...
10110111
commented
15 hours ago cannot easily be reproduced or even explained
Hasn't @alex-w reproduced this one?
gzotti
commented
15 hours ago The tag looks like it, but I don't know how.
alex-w
commented
14 hours ago Hasn't @alex-w reproduced this one?
Not complete reproducible - I can reproduce the issue of ignoring language settings in Qt's dialogs (this is missing feature IMHO) and few years ago we're got the report with very similar issue for arabic/persian/etc. numbers in dialogs.
@Hamousher Could you attach screenshot for locale settings in operating system?
gzotti
commented
14 hours ago AFAIK the program is initialized in the "C" locale, right? Is there anything missing then? How does that affect the Qt modules? Are they used uninitialized?
alex-w
commented
14 hours ago AFAIK the program is initialized in the "C" locale, right? Is there anything missing then? How does that affect the Qt modules? Are they used uninitialized?
This is a good and difficult question - please see log from current master
10110111
commented
13 hours ago AFAIK the program is initialized in the "C" locale, right?
Only LC_NUMERIC is set to "C", but QApplication uses what it got from the system before this (and calls setlocale accordingly, which is then overridden in LC_NUMERIC by Stellarium).
Now, setting LC_TIME=ar.utf8 (in environment variable on Linux) leads to days of week inside the calendar widget being in Arabic. Setting LC_NUMERIC=ar.utf8 results in the numbers in the calendar being Arabic. This reflects the fact that QApplication reads these variables before we reset any of them in Stellarium.
P.S. I'm not sure how this works on Windows, maybe QApplication reads the registry or queries some locale-related Win32 API.
gzotti
commented
12 hours ago Good find. I did not check the code so far. Just that I assumed some trace of an Arab setting may have remained from some previous system setting. But en_UK, enUS and bg system language settings should not cause that. Again, just suggesting, can we read system language, initialize LC* with whatever is appropriate for current system language, then overwrite LC_NUMERIC=C. Or is it enough to set LC_NUMERIC earlier, before any Qt module has a chance to initialize?
10110111
commented
12 hours ago Again, just suggesting, can we read system language, initialize LC_* with whatever is appropriate for current system language
Just checked, on Windows Qt calls GetLocaleInfo. So no, you can't easily force it this way. But you can call QLocale::setDefault(desiredLocale) before creating any widget (or the instance of QApplication?). This won't work when you change locale on the fly though.
I guess we still need to know the defaults when there's no config yet.
gzotti
commented
6 hours ago I see in the helpfile:
Warning: In a multithreaded application, the default locale should be set at application startup, before any non-GUI threads are created.
Probably adding in line 189 in main.cpp helps:
QLocale::setDefault(QLocale::c());
What other critical settings would change by this?
10110111
commented
6 hours ago
QLocale::setDefault(QLocale::c());
You should use the actually desired locale, rather than "C". Otherwise you'll simply get English in the calendar widgets instead of the language chosen by the user.
Actually, I've now realised that we could set the locale for the calendars explicitly by using QWidget::setLocale. The need for this is strange though. How do we localize other stock widgets, like, say, file open/save dialogs?
gzotti
commented
6 hours ago We have our own language settings which should be used for the actual widgets. The "C" would just act as global initializer before reading config.ini. We could recommend restarting the program after a language change if dynamic re-setting is too cumbersome. OTOH there is the "languageChanged" (or similar) signal. Here GUI elements can be nudged at runtime.
10110111
commented
6 hours ago The "C" would just act as global initializer before reading config.ini.
You still need to get the default for the case when there's nothing in config.ini yet.
OTOH there is the "languageChanged" (or similar) signal
Apparently, the uic-generated retranslateUi() method doesn't touch the QDateTimeEdit widgets. So we need to write the code to call setLocale on them in the languageChanged handlers everywhere where we have these widgets.
gzotti
commented
6 hours ago Prepend a qDebug() << QLocale::system().bcp47Name(); for diagnostic purposes? With this in a future beta @Hamousher could possibly find what's wrong with the system and why these wrong arab numbers appear on just this one computer or under such rare circumstances. Then reconstruct a meaningful name and set this instead of C for global initialisation. Sure, if a locale is set in config.ini, we could use that instead.
Yes, our *Dialog::retranslate() methods are the places to fix the widget locales.
10110111
commented
6 hours ago Prepend a qDebug() << QLocale::system().bcp47Name(); for diagnostic purposes?
It's not only needed for diagnostics. You also need a sensible default for a first-time launch.
why these wrong arab numbers appear on just this one computer or under such rare circumstances
Similarly wrong Russian weekday names I have on my machine with English being the Stellarium locale, because I have LANG=en_US.UTF-8 and LC_TIME=ru_RU.UTF-8 in my system. I just never paid enough attention to such details, but this has always been present in Stellarium's calendars.
I still wonder how the calls to retranslateUi etc. appear to affect the file dialogs, because they are stock dialogs, just as the calendar widget, and we don't call QWidget::setLocale on anything.
On my desktop language is selected English but most of the boxes containg numerals appear as foreign and can't be changed. On my laptop is no problem
Expected Behaviour
Actual Behaviour
Describe or maybe attach a screenshot?
Steps to reproduce
System
Logfile
If possible, attach the logfile
log.txtfrom your user data directory. Look into the Guide for its location.