I guess I should have been more specific when I said “Try changing the decimal seperator settiing.”… 
Glad you figured it out. I’m a bit baffled though why it makes a difference for you as your locale decimal point is the “period” .
so it shouldn’t matter if the setting is checked or unchecked… as “unchecked” means use a period, where “checked” means use a period. I’m wondering if I should change the pref UI to just use a radio button with the choices Period and Comma. Hmmmm.
HeyTheo… just figured I’d give you an update. I’ve been working on migrating Seamly to Qt6, and one of the things I’ve had to fix is the way the app deals with the locale separators - which has been a source of the QTextCursor errors.
The one thing I learned is that some locales use UTF-16 rather than UTF-8, which explains why the app can’t use certain locales as the encoding for the decimal & group separtors is different leading to the cursor errors. It would explain why the en_GB locale - which I believe would be your user locale - doesn’t work, while my en_US does. When the Decimal separatior pref is unchecked, the app uses the standard C locale… which in my case is the same for the User locale, but not for you.
In QT6 they changed the return type for the locale decimal & group separators, as well as the plus and minus signs from a QChar to a QString - except the math parser expects a char. So… in a nutshell in fixing the math parser to use the QString separators, I believe it also fixed the QTextCursor issue. I have been able to run a Windows QT6 build with the locale set to en_GB with no QTextCursor errors. Once I get a QT6 branch to build maybe you could install a MacOs artifact build and see if indeed the QTextCursor will no longer be an issue.
Thank you for the update! That makes sense. I would certainly be happy to test that out for you, once it’s ready drop me a link to the artifact build
Clear and unambiguous is the way…
After fixing the locale issue for Qt6 I realize the text for the pref “Decimal separator: < User locale >” is a bit of a misnomer. This does not direcrly set the decimal separator, rather it determines what locale is used by the GUI for the input / ouput of numbers. The locale determines what decimal & group separators, positiveSign, negativeSign, exponent, 0-9 digits chars are used. And while the decimal separator is usually a period or comma, the group (thousands) separator can vary between the comma, space, non breaking space, and narrow non brealing space.
So currently the prefs are:
Unchecked the C Locale is used, Checked the user’s system locale is used.
IMO it should be:
And the rollover tooltip for each radio button could then display the locale options like it does in the About dialog:
And yes… to the observant: For testing purposes I figured out how to fake the app into thinking the user locale is somewhere else without actually changing my laptop’s system locale setting.
I’m not sure that “Standard C” would make sense to very many Seamly users, but I’m having trouble thinking of a better way. Maybe “Default: . - +”?
IMO semanitcally it needs to say it’s setting the locale… not the actual separators and chars. Here’s what I’m working on:
And since there are only 2 radio buttons I can treat it like a checkbox and not have to change all the settings code - which would be another PITA. I’ll also format the tooltips better, and display a name for a space, non-breaking space, or a narrow non-brealing space which otherwise does not show anything visible.
Okay, yeah, I think that does a great job of addressing my concern. Thanks!
I put the tooltips in an html table, increased the font size, and did all the translations:
And with that I think the Qt6 branch will be ready to test.
Amazing ! Thank you @Douglas 
