← Back to team overview

kicad-developers team mailing list archive

Re: Some thoughts on symbol remapping

 

On 12/13/2017 01:56 AM, Oliver Walters wrote:
> I finally had a chance to try the symbol remapping on a real project,
> and I have a few thoughts on how I think it could be improved from a
> users perspective (with code to back up my thoughts!)
> 
> 1. "Remap" should replace "rescue"
> 
> The remap tool, with some work, should replace the "symbol rescue" tool.
> There are two major cases which it should cover:
> 
> a) Handling "legacy" (v4 and prior) symbols which do not specify a
> library nickname
> b) Handling missing libraries or symbols
>  i) A library has been moved or deleted
> ii) An item has been renamed in a library


These are two distinctly different processes and need to stay separate.
Please do not merge them.

> 
> The rescue tool does not seem to work at all now, with the new
> sym-lib-table approach. I think I have come up with a way to combine the
> two tools that provides a better approach anyhow.

Please explain.  The last testing I did, both the legacy and fully
defined LIB_ID rescue works as required.  Are you saying if you delete
or modify a library symbol used in a schematic with a fully defined
LIB_ID that is does not get rescued properly from the cache library?  If
so, please file a bug report so I can fix it.

> 
> 2. Let users "remap" multiple times.
> 
> The current implementation only allows remap if *all* the symbols are
> un-mapped. If a partial remap occurs then the users are left high and
> dry. Partial remaps should be allowed, this gives the users chance to
> fix their library tables or whatever.

I'm not opposed to this but only for symbols that do not already have a
library nickname assigned to the schematic symbol LIB_ID.  Once a symbol
is remapped and mapping is correct, the only other valid operation is to
choose a new symbol.  I would reject any change that fell back to
looking up symbols by name alone (no library).  This was the entire
point of the remapping and would reintroduce the bug that has been
around since the beginning of the project.

> 
> 3. Separate project-remap from symbol-remap
> 
> The regeneration of library tables should be separate from symbol
> remapping. Rescue the project once, (with a visible warning to user at
> first project load, as is currently the case). But, allow symbol remap
> from the menu at any stage (even if there are no symbols to remap!)

This will likely not work because more often than not, successful
remapping depends on the project specific symbol libraries not just the
global symbol libraries.  This is why the remapping utility first
creates a project specific symbol library table based upon the libraries
it needs (contains symbols used in the schematic) from the old library
list.  Keep in mind, the remapping does not just look for the first
occurrence of a symbol with a given name in the symbol library table
(that would be broken), it actually matches the full file path and file
name from the symbol library table to do the mapping.  There is a bug
where symlinks will get mapped as a different library.  I have a fix for
that but I have had time to test it.

> 
> 4. Group similar symbols together when remapping
> 
> If a schematic has 100+ 'R' symbols, they should be grouped together so
> that they can *all* be remapped at once. Collect similar symbols
> together. (See demonstrator image below).

Nice but not crucial to the remapping.  Sorting could be added to the
existing remapping feature as well.

> 
> 5. Allow manual remap selection
> 
> If auto-remapping fails for a particular symbol, allow the user to
> select a new symbol manually

This isn't really remapping.  This is reassigning a library symbol.  If
a symbol cannot be located in any library in the old library list, there
is no way to recover it.  This was true before the switch to fully
defined LIB_IDs.

> 
> 6. Allow skipping of remapped symbols
> 
> Some may be not able to be remaped at the current time. Allow user to
> skip and come back later.

Do you really want listen to users scream about broken symbol links?
Keep in mind, once the remapping is complete, all of the old libraries
from the symbol library table are removed from the project files so they
are no longer available for future remapping which will almost certainly
lead to issues.  I will reject keeping the old library list in tact as
it was part of the original issue.

> 
> 7. Provide a dry-run first and let the user see what is happening.

I'm fine with a dry run feature.  I had it on my todo list but if you
get to it before I do.  My feelings wont be hurt.

> 
> 
> I have actually implemented all of the points above. See demonstrator
> images here:
> 
> A) Dry run with explicit output messages, and information on what will
> be changed
> 
> Inline image 1
> 
> B) Success!
> 
> Inline image 2
> 
> If this is a good approach I will spend some more time on this, there
> are still some issues to work out. However, It is (to me) a much cleaner
> approach.
> 
> Thoughts?
> 
> Oliver
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


Follow ups

References