Hi Wayne, > The symlink issue has been fixed so duplicate libraries will not show up > in the project symbol library table with different nicknames. I noticed some issues with my previous build (2017-12-22), but using the 2018-01-03 build, symlinks (both in the directory and filename) indeed seem to be handled correctly.
> > The procedure implemented now (find the symbol in the old list first)
> > totally makes sense. However, I would think that *if* this procedure
> > fails, looking up the symbol by name in the new list could be a good
> > fallback?
>
> Doing this would completely defeat the purpose of the symbol library
> table and reintroduce the bug that has existed since the beginning of
> the project. Symbols are now required to be mapped to a specific
> library. No more searching through the list of libraries and hoping
> that the first instance of a symbol is the correct one.
I'm not suggesting to do this all the time, only during remapping. So at
that time, the library list is the old one, and is still subject to
this ambiguity bug anyway. Also, I'm suggesting to *only* do this if the
remapping otherwise fails, so this would just be a best-effort guess.
Better to have most of these symbols right, then all of them unmapped?
AFAIU any mismappings would also be identified by the subsequent rescue
dialog and pointed out to the user.
> If the remapping algorithm cannot find the exact library match which
> is currently being used (and should be in the project library list or
> the cache) to provide the symbol, then there is no way to determine
> the correct library and therefore cannot be remapped. It also means
> that your schematic is already broken. This is why you should not
> skip the rescue feature.
I can't quite remember if I skipped the rescue dialog (quite possibly),
but I can imagine a user (such as me) would reason that there is no need
for rescueing symbols into a rescue library, since all symbols are
available in their newly set lib table.
Specifically: If my symbols are not available in the old-style library
list, but are available in the new-style library table, I can see three
outcomes:
1. If I perform a rescue, I get all symbols remapped to the rescue lib.
2. If I cancel the rescue, all symbols are unmapped.
3. If I cancel the resecue and my fallback-guessing suggestion is
implemented, most of my symbols will be mapped correctly (and
possibly some will be incorrect).
As a user, I would prefer outcome #3 over the other two. To fix my
schematic from outcome #1 and #2, I will have to manually fix up all
involved symbols to point to the right library again (having them point
into the rescue library makes the schematic work, but is not preferred
when the symbols are available in the symbols).
> > [ About code that adds missing old-style libraries to the project
> sym-table]
> Yes, it exists in eeschema/dialogs/dialog_symbol_remap.cpp.
Ah, I expected this to happen only for libraries containing remapped
symbols, but I see now it happens for all libraries in the schematic,
which makes sense. Thanks.
A related question: How are the changes in library layout intended to be
handled, when combined with the remapping dialog? AFAIU the migration to
the new kicad-symbols repository also involves renaming a lot of
libraries (e.g. Connectors.lib -> Connectors_Generic.lib). If you
upgrade to this new library layout, the (v4) library list must also be
updated to match the new library names? Or is there some automatic
conversion for this?
When you're still running v4, this can be fixed by manually fixing the
library list with the new library names. But when running v5, the
library list can (AFAICS) no longer be edited, but it is also assumed to
be correct by the remap dialog (which it will not be, then). Or am I
missing something here?
This would also be a case where the fallback I suggested above could be
helpful, though I guess a more reliable method would be better here.
Gr.
Matthijs
signature.asc
Description: PGP signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
