Nightly users: changes to settings

Hi everyone who uses nightly builds of KiCad!

For those who don’t follow GitLab that closely, the new settings system got merged today.

This brings a few user-facing changes that you should be aware of:

First, user settings are now stored in versioned subfolders of the KiCad config path. The major and minor versions are used, so currently this means “5.99”. When you first launch KiCad, you’ll see a window asking you where to get the settings from. It will default to using your current KiCad installation, but you can manually pick a different path to migrate from.

Your settings will be automatically upgraded as you use KiCad the first time. All of your settings should be preserved: please report any problems you notice so that I can investigate.

There is no backwards-compatibility for settings. Any settings changes you make after migrating your settings to the new system will only apply to newer versions of KiCad. You can continue to run older versions of KiCad on your system, and they will continue to use the old settings files.

If you have been using the KICAD_CONFIG_HOME environment variable to allow running multiple versions of KiCad on the same machine, this technique is still allowed but should no longer be necessary. If this variable is set, it will determine the base path for settings (there will still be version-specific directories created within that base path). I recommend that you clear this variable before launching KiCad after this change, and then when you see the dialog asking where to import settings from, choose the appropriate path (either the default, or wherever you had set KICAD_CONFIG_HOME to depending on where you’d like to import from).

Second, settings are now stored in JSON format. This mostly will only impact people who are used to manually editing settings files. I think the most common reason people do this is to apply color themes. A real color theme system is also coming in the V6 development cycle! For the moment, this change will break the ability to paste in color settings you find from other people until those themes are updated to the new format. I’ll assist in making a migration script so that those of you who have repositories of colors (such as can make versions of these themes that work with the new system.

For the moment, this change only impacts system settings. A similar change is coming that will impact project settings (i.e. those that are currently stored in the KiCad project file and design files). I’ll make another announcement when that change is ready with more details.

If you are paranoid, it might be good to back up your settings files before updating KiCad. As always, please report any issues on GitLab so that we can investigate and solve them as soon as possible.



As of right now (2020-02-20 about noon European time) the latest nightly build on Windows hasn’t incorporated this commit, so you can see the new migration dialog tomorrow if you update then or after that.

On Windows the installer still overwrites the Windows Start menu structure. Therefore installing and using different versions side by side isn’t still fluent. You have to either create Start menu items manually or start from the installation directory. (This is just FYI for those who have declined from using nightly builds because of all that hassle. KICAD_CONFIG_HOME and a starter script isn’t needed anymore; see Running several KiCad versions on the same Windows machine and

At least the Ubuntu packages have been already configured so that they can be installed side by side. I don’t know if there will be any changes to them - they should work anyways.


@craftyjon , I can’t test right now and don’t know/remember how it behaves, so I ask.

Keeping the old lib-tables from the old (v4) installation has been a real royal PITA; even very recently people have been updating from v4 to v5 and need help from us because the old libraries are used invisibly (a need of an FAQ article is an indicator of a shortcoming in the software). How does the migration handle that? IMO if the user copies from an older version, there should be some kind of information/warning about the library tables and possibility to exclude them from the migration.

That option could possibly be integrated to the first-time library table dialog so that it’s shown after the settings migration even when the library tables have been copied.

BTW, one safety tip for nightly build users came into my mind: keep a copy of today’s nightly build installer archived, in case you have to go back to a version which handles the old settings.

@craftyjon with your changes, the testsuite fails (Linux segfaults, Windows runs into an endless loop).

1 Like

Version: (5.99.0-888-g941de5bfa), release build
A master compile went without any problems.
Only re-adjustment needed for eeschema colors.

Does “make test” succeed for you?

Sorry about that. I pushed a fix that I tested on Linux. Hopefully Windows hit the same problem.

Could you say a bit what happened to your eeschema colors? In theory nothing should change when you install this.

The library tables are not touched by the new settings framework right now. So, they are just copied from whatever directory you migrate from.

Now that they are copied, it would be possible to add code to do additional migration things (show warnings, change the files, etc).

Please file an issue for this so we can discuss with the rest of the dev team

Without the last two fixes.

Running tests…
Test project /home/johannes/software/kicad/kicad/build
Start 1: qa_python
1/8 Test #1: qa_python …***Exception: SegFault 11.21 sec
Start 2: common_eeschema
2/8 Test #2: common_eeschema … Passed 0.13 sec
Start 3: common_pcbnew
3/8 Test #3: common_pcbnew … Passed 0.12 sec
Start 4: qa_common_gerbview
4/8 Test #4: qa_common_gerbview … Passed 0.12 sec
Start 5: pcbnew
5/8 Test #5: pcbnew …***Failed 0.15 sec
Start 6: eeschema
6/8 Test #6: eeschema … Passed 0.13 sec
Start 7: sexpr
7/8 Test #7: sexpr … Passed 0.02 sec
Start 8: kicad2step
8/8 Test #8: kicad2step … Passed 0.02 sec

75% tests passed, 2 tests failed out of 8

Total Test time (real) = 11.93 sec

The following tests FAILED:
1 - qa_python (SEGFAULT)
5 - pcbnew (Failed)
Errors while running CTest
Makefile:151: recipe for target ‘test’ failed
make: *** [test] Error 8

They simply reverted to the default settings. e.g. ugly white background :-1:

Please file a bug report for this and include a zip of your config dir (including the old settings and the 5.99 directory inside), this should not have happened.

The last two commits fixed it. All good again.

Application: KiCad
Version: (5.99.0-890-g503c45b2a), release build
wxWidgets 3.1.3
libcurl/7.58.0 GnuTLS/3.5.18 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-74-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
Build date: Feb 21 2020 02:47:50
wxWidgets: 3.1.3 (wchar_t,wx containers) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Technology: 7.3.0
Curl: 7.58.0
Compiler: GCC 9.2.1 with C++ ABI 1013

Build settings:

Will do.

Also noticed just now that with commit 890 the ‘Open Recent’ project list sort order got messed up on first startup. Second startup showed the previous (correct) list again.

It was still ok with 888 though.

Follow up:

As of commit 890 the colors get properly transferred into the new config infrastructure.
No need for a bug report for now.


What happens is that the sort order reverses on each startup consistently.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.