Standalone applications load project-level settings from default location

[Seth Hillbrand]

Starting eeschema as a standalone application causes it to load the symbol libraries twice when first adding a new part.

The first load (with progress bar) happens when pressing "a" to add a new part. Then the libraries are loaded again after the part is selected and the symbol browser window is closed.

Of note, there is an assert when adding a new part in standalone mode:
eeschema_config.cpp(779): assert "!prjPath.empty()" failed in SchSymbolLibTable().

This may be related to https://bugs.launchpad.net/bugs/1734773

Application: eeschema
Version: (2018-01-21 revision 81642dddd)-master, debug build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.52.1 GnuTLS/3.5.8 zlib/1.2.8 libidn2/0.16 libpsl/0.17.0 (+libidn2/0.16) libssh2/1.7.0 nghttp2/1.18.1 librtmp/2.3
Platform: Linux 4.9.0-5-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    Curl: 7.52.1
    Compiler: GCC 6.3.0 with C++ ABI 1010

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=OFF

[Wayne Stambaugh (stambaughw)]

Do you have broken symbol library table entries? I'm not seeing the assertion so I'm wondering if that is the issue at play here. I just tested this in linux and the symbol libraries are not getting reloaded (I checked with a debugger) so perhaps broken symbol library table entries are causing the issue.

[Seth Hillbrand (sethh)]

Hmm.. No, I have the standard sym-lib-table from the github kicad-symbols. I'm attaching a video of what I see. Note that the progress bar pops up first when I press 'a' to add the symbol and then again after I select the symbol and go to place it.

The progress bar does not appear again after this.

I haven't checked to see if the display of the progress bar actually corresponds to loading the libraries from disk or if it is just re-loading from a cache. If you don't see the progress bar twice, I can check further with a debug build.

[Wayne Stambaugh (stambaughw)]

@Set, are you still seeing this issue with the latest symbol library changes? I cannot trigger this on my Debian testing box.

[Wayne Stambaugh (stambaughw)]

On 01/27/2018 11:08 AM, Wayne Stambaugh wrote:
> @Set, are you still seeing this issue with the latest symbol library
 ^@Seth^

Sorry about that!

> changes? I cannot trigger this on my Debian testing box.
>

[Seth Hillbrand (sethh)]

It is still happening on my machine (Debian stretch). But I just tried a different box with the same compiled executable and also Debian stretch and couldn't trigger it.

I'll spend some time tracing it

[Jeff Young (jeyjey)]

I'm going to flag this as incomplete for now. If you manage to get it reproducing again, please reopen.

[Seth Hillbrand (sethh)]

Jeff, I can reliably reproduce on my machine. I appreciate your efforts to prune the bug database but this one is assigned to me and I'd like to keep it open until I fix it.

[Jeff Young (jeyjey)]

No worries. We're making a pretty good dent in the backlog, so I'm happy. :)

[Seth Hillbrand (sethh)]

Interestingly enough, it turns out that I had a file named .eeschema in my home directory that must have been left over from running eeschema in standalone with a pre-symbol table version. Running in standalone mode, this file gets loaded as the Eeschema configuration. My file (attached) had a bunch of old library links.

It got loaded from "LoadAllLibraries" that gets called (Project::SchLibs()) after we place a part to load the cache library.

@Wayne- We could force this to ignore the config file libs unless we are remapping but this would probably cause issues if users skipped the remapping step. Maybe we set a project variable "m_loadOldLibs" but I dislike the idea of polluting the class. More elegant would probably be splitting the loading of legacy tables into a separate function to be specifically called by remap. Do you have thoughts/preference on this?

BTW, on windows this is probably "%USERPROFILE%\eeschema.ini"

[Jeff Young (jeyjey)]

I don't quite follow this as I'm not familiar with the remapping stuff. Is there an action for us in here? (If so, should we rename the bug to better capture it?)

[Wayne Stambaugh (stambaughw)]

@Seth, I don't know if I'm comfortable with the changes you are proposing. The risk of breaking v4 designs is and mucking up the remapping too high for my tastes. I'm guessing this only happens when editing a schematic that is in a folder that doesn't have a project file so Eeschema loads the default one from the template library. If the user has a updated default project file, there should be no legacy libraries loaded because the that list has been cleared. I think this behavior is actually correct if this is the case.

[Seth Hillbrand (sethh)]

That's fine. It was more spitballing than a definite proposal. I'm happy leaving this as is for now. If it becomes an issue after v5 is out, we can revisit.

[Seth Hillbrand (sethh)]

Jeff- I'm going to keep this open as it isn't "fixed" in the sense that it won't cause problems. Even if we want to keep the .eeschema file loading, there are two issues.

1) The v4 libraries load after the part is already selected, meaning the second placement will have different libraries
2) The v4 libraries are loaded and available for placing parts but their nicknames are blank, so using them will create schematics that still need to be remapped.

I think that this is a very low priority but keeping it open is, I think, the best option here until completely addressed.

[Seth Hillbrand (sethh)]

From the duplicate: project settings also loaded in standalone Gerbview, pcbnew.

[Seth Hillbrand (sethh)]

This is proving to be trickier than I envisioned (or I am making it so). The error is sufficiently rare that I am pushing back to 5.1

[KiCad Janitor (kicad-janitor)]

Fixed in revision b71c2e5edf822f77cb62a4a09e201a2e51ab39d6
https://git.launchpad.net/kicad/patch/?id=b71c2e5edf822f77cb62a4a09e201a2e51ab39d6