ahlstromcj/seq66

Usr file breaks pattern colors

Closed this issue · 15 comments

igorangst commented

Hi,
I just did a fresh checkout ( commit f8bcfa3 ), and noticed that that the pattern colors did not work after I launched seq66 for the second time. I could track down the problem to the usr file, in particular to the section [user-ui-tweaks]. If I delete this section, the colors work out fine, if it's present, everything is gray (see screenshots).

Compiled from sources on Ubuntu 20.04. Let me know if you need more info or logs.

Screenshot from 2022-02-23 22-52-28
Screenshot from 2022-02-23 22-53-19

ahlstromcj commented
igorangst commented

OK, it seems it's really coming from an invalid / outdated 'usr' file. Setting the values in the 'usr' file to

progress-box-width = default
progress-box-height = default

fixes the issue. Any other values (for example 0.8 and 0.5) do not work.

ahlstromcj commented
igorangst commented

Strange. Anyway, the defaults work fine for me, so I guess this can be closed for the moment. Thanks for the quick reaction.

ahlstromcj commented
igorangst commented

This problem seems to persist:
When qseq66 closes and saves the usr file, the values for the box size are always set to 0
progress-box-width = 0 progress-box-height = 0
Also, in order to prevent saving the usr file, I need to untick the "save at exit" box in the Sessino tab each time, otherwise it switches back to save and corrupts again the usr file when closing down.

Compiled version 0.98.10 under Linux.

ahlstromcj commented
ahlstromcj commented

It turns out that the only way to get them 0 is to (inadvertently or not) set one to 0, and the other becomes 0 as well. Now that is confusing! So I added a checkbox and jettisoned the idea of using 0's to turn off the progress box. This adds the "pattern-boxes-shown" flag to the 'usr' file. Have not checked this code in yet, though.

igorangst commented

This is really weird. I could track down the problem, but I do not understand it nor can I fix it: It's the string_to_double function that turns a nice "0.8" string into 0. I added some console outputs, and it's actually the call to std::stod(s) itself that fucks up and ignores everything after the dot. Why the hell? It works fine if I compile a small example program calling std::stod("0.8").

Seems like this is an isolated issue with my compiler or libcpp. I will continue digging...

ahlstromcj commented
igorangst commented

I GOT IT!

I figured out std::stod depends on the locale settings of the system. Since I'm based in France, the locale number format is "0,8" rather that "0.8". If I change the dots for commas in the usr file, it works. Wow, that was a tricky one!

What would be the right way to fix this?

ahlstromcj commented
igorangst commented

For now, I set my locale to British. That fixes it for me. In my opinion the file format should not depend on the locale, so files can be shared without hassle.

ahlstromcj commented

I have added a "--locale" option (not yet checked into the portfix branch). For example:

./Seq66qt5/qseq66 --locale fr_FR.UTF-8

sets the local accordingly, and in the Edit / Preferences / Display one sees that the progress-box sizes show commas for the decimal point (and the written 'usr' file uses commas as well).

So one can set the locale to en_US.UTF-8 so that the period is the decimal point. Could do locale detection or force it, but perhaps this is more flexible for users unconcerned with sharing Seq66 config files.

igorangst commented

For me, this issue is fixed. Thanks a lot.