Preferences - Configure Paths settings not saved when made in a secondary session

[KiCad bug report]

When having two KiCad sessions open at the same time, and changes are made to the "Preferences - Configure Paths" (tested with footprints path), in the second session, they mess up library access after having closed and re-opened the applications. When using the first session afterwards for example, the libraries still show up in the "footprint editor" (I guess it's just populating the list from the fp-lib-table), however, there are no more footprints inside the libraries.

Is KiCad written in a way that it can have sessions running in parallel on the same computer, or do we have to limit its usage to only one pcb-project at a time ?

Application: kicad
Version: (5.1.0-0), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Platform: Mac OS X (Darwin 17.7.0 x86_64), 64 bit, Little endian, wxMac
Build Info:
    wxWidgets: 3.0.4 (UTF-8,STL containers,compatible with 2.8)
    Boost: 1.68.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.51.0
    Compiler: Clang 8.0.0 with C++ ABI 1002
Build settings:
    USE_WX_GRAPHICS_CONTEXT=ON
    USE_WX_OVERLAY=ON
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[John Beard (john-j-beard)]

This is an annoying thing that has existed for a while.

KiCad reads and writes to the config files (mostly?) at shutdown. This means that:

* The last session to close "wins", prior sessions to close have their configs overwritten
* Other sessions do not notice config changes, and if they are restarted, they wipe out the changes made by others
* If KiCad crashes, you lose config changes in that session

I suppose you could watch the config files with inotify or similar and react to changes "live".

You could also save a session key into the config on read and then remove it on write - other sessions that start in the meantime can then warn that they're about to overwrite. If the user wants this, the overwriting session updates the key to its own, and when the original session goes to write it can also prompt to overwrite or not.

[Wayne Stambaugh (stambaughw)]

KiCad is not really designed to run multiple sessions at a time. You should have seen a warning dialog that KiCad is already open. Ignore that at your own peril. Maybe in the future will will change to a multiple project interface but for the foreseeable future KiCad will have a single project interface.

[Wayne Stambaugh (stambaughw)]

On 4/16/19 5:06 PM, Wayne Stambaugh wrote:
> KiCad is not really designed to run multiple sessions at a time. You
> should have seen a warning dialog that KiCad is already open. Ignore
> that at your own peril. Maybe in the future will will change to a
                                            ^^ we ^^
> multiple project interface but for the foreseeable future KiCad will
> have a single project interface.
>
> ** Changed in: kicad
> Milestone: 5.1.2 => None
>

[KiCad bug report (kicad-bug-report)]

On 4/16/19 5:06 PM, Wayne Stambaugh wrote:
> KiCad is not really designed to run multiple sessions at a time.

That's a pity :-(

On the other hand, I do understand that migrating to a multi-project interface has huge implication on the architecture of an application (like loads of inter-process communication...).

However, I think that loading the settings at start-up, and only saving them at closing is not really a good practice... Any application crash makes you lose your settings (and KiCad seems to crash on a regular base, even in a single session). Just reading and saving the settings to disk at every change would probably already solve a lot of the multi-session issues. As you don't change settings 1000 times a second, that should be no problem for disk-access either.

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2387