kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

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

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.

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.

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!)

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).

5. Allow manual remap selection

If auto-remapping fails for a particular symbol, allow the user to select a
new symbol manually

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.

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


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

[image: Inline image 1]

B) Success!

[image: 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