Just did few tests to confirm, after installing Interactive BOM Plugin, PCBNew resets my colors definitions and does not allow to save my colors.
I can change these while PCBNew is running, but upon restart colors seem to revert to defaults.
If I remove the plugin, I can again save my colors.
Anyone experienced that behaviour? Win64, (5.1.5-52-g344440955)-1.
Doesn’t happen for me on windows 5.1.5-3 release build.
Are other settings saved? Colors are saved in the same place as for example window position and size is saved. If you install the plugin does pcbnew remember it’s window position between restarts?
OK new findings here: Colors are reset only when the opacity is below 100%.
If you keep solid colors (=opacity 100%) they are properly saved. Window position is stored.
But every non-100% opaque color is reset to default.
Definitely caused by the i-BOM plugin.
@qu1ck can you set layer color to opacity below 100 and see if it remains, or is defaulted?
Yes, changing both opacity and color works for me.
Look at settings file in %appdata%\kicad\pcbnew. Can you check if colors are actually changed when you change them in pcbnew? That way we will know if the problem is in saving settings or if it is in reading them.
Btw ibom does not touch that file at all. If you see this issue you should see it with other plugins as well, can you check any other action plugin?
keep investigating…
my %appdata%\kicad\pcbnew file is not updated with the interactive plugin enabled, but the settins are stored (somewhere) as PCBNew “remembers” my colors of choice with full opacity.
Maybe the default path is altered somehow? Looking around for the settings file.
It might be that the update to the settings files happens only when KiCad is closed.
1 Like
OK, me not clever enough 
Indeed focused on PCBNew, but the files were updated after closing the whole KiCad process.
Now to the things:
Transparency is properly saved, I can see an entry:
Color4DPCBLayer_F.Cu=rgba(255, 0, 255, 0,902)
and after re-start, it is replaced by:
Color4DPCBLayer_F.Cu=rgb(132, 0, 0)
Now I find what is the cause: it’s my Locale with the f**n “comma” instead of proper “dot” as a decimal separator.
If I manually set the opacity to “0.902” instead of “0,902” it opens OK.
But why did the iBOM plugin reveal this bug?
AFAIR there was some bug for the “comma” reported recently… Must dig the forums a bit.
Ugh, this bug again.
I described temporary workaround here: https://gitlab.com/kicad/code/kicad/issues/3881#note_288671608
1 Like
Yeah, this fixes my problem.
But then… why change iBOM’s variable impacts KiCad itself?
Is the decimal_separator variable a global one for KiCad?
IMO setting changing the look of the “decimal separator” (if necessary, I’m all against it anywa) should well… change the look of the character ONLY.
It’s internal representation shall remain, regardless of any stupid character we want to use to visually separate the decimals. Otherwise we’ll run into any kind of interchangability issues.
The locale settings (which include the number format like the decimal separator) are global to a process. If some script running inside KiCad adjusts it, it will impact everything else within the same running program. This is not a KiCad feature, it’s just how locale works in the C/C++ standard library. We work around this by explicitly setting the locale to what we want just before reading/writing files. Unfortunately this means that if someone forgets to do that, or if there is another bug, it can cause issues.
I think that JP’s recent fix here might be relevant:
In some cases (on Windows) the previous way we were doing it was not properly setting the locale.
This impacts whenever we are reading/writing files that need decimal separators.
@qu1ck it would be interesting to know if this problem still happens with your script after JP’s commit.
Do you think it should be reported on GitLab just to make sure it will not sneak unattended during saving the user-defined colors with decimal-separated opacity value?
Or it’s a general fix? I’m a bit n00b-ish on the internal design of Kicad.
It is already fixed in KiCad as far as I know. The only question would be whether to backport it to 5.1 branch.
@fred4u the issue is not setting some variable in plugin code but calling setlocale() which affects parent process as well.
@craftyjon I couldn’t reproduce this with either latest from master or with 5.1.3 release build. Saving colors with opacity worked properly and also arcs with decimal angles worked fine (https://gitlab.com/kicad/code/kicad/issues/3881)
I could only reproduce this bug https://gitlab.com/kicad/code/kicad/issues/3830 and fixed it now in plugin by switching back to original locale of the process.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.