Le 13/12/2017 à 08:44, Oliver Walters a écrit : > jp, > > I was unaware of this new feature, that does perform a lot of the functions I > mentioned.
This is a very recent feature. It was needed to allows global changes when a symbol has been renamed in a library or moved from a library to an other library. > > Can this new tool replace the "Rescue symbols" tool under the "tools" menu? It is more like the current "Remap Symbols". So it could replace the current "Remap Symbols" in "tools" menu. > > On Wed, Dec 13, 2017 at 6:19 PM, jp charras <[email protected] > <mailto:[email protected]>> > wrote: > > Le 13/12/2017 à 07:59, Oliver Walters a écrit : > > Following is a screenshot of what happens when a symbol cannot be > remapped: > > > > Inline image 1 > > > > On Wed, Dec 13, 2017 at 5:56 PM, Oliver Walters > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> 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 > > > > 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 > > > > 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 > > Remember there is a tool in schematic editor ( "Edit / Edit Components > to Symbol Library Links" ) > that should seriously help for global remapping. > > > -- > Jean-Pierre CHARRAS > -- Jean-Pierre CHARRAS _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
