DRY parts, using references to core SVGs, obsolete SVGs

One way to organize parts is to reuse graphics from existing parts, by referencing to the exact same file from the core parts, and not including a copy in the fzpz.

In theory, this would lead to a stable collection: A fix needs only to be applied to one file, no need to track down all copies (and missing some) of the file.

There might also be a case were a fix would be a breaking change. For example, if some part had RX TX mixed up, most existing sketched already worked around that simply by wiring them in the correct way.

For this, Fritzing has an obsoletion mechanism:

  • We can keep the old part, and add a new one with RX TX in desired order
  • We can also add a replacedBy marker, and Fritzing will suggest to replace the specific part whenever it is encountered in a sketch.

However, my guts feeling is that this needs improvements.

Some questions and ideas.

  1. Does Fritzing bundle the sketch as expected? Does it bundle a copy of the core SVG?

  2. Are there specific tests cases we should take into account for releases ? Are there some SVGs that are very popular for re-use by reference instead of copy?

  3. Should we improve the obsoletion mechanism: 1. Allow silencing warnings. 2. List the actual parts that are obsolete (currently we only select them), better support for individual replacments instead of the upfront “replace all” when loading a sketch. 3. Add a description field, to tell the user what was fixed about a part, and which changes to look out for?

The update and obsolete process could definitely use some improvement. A description about what is changing would help users. That could have some categories of changes to help decide if and when to update the local part or sketch using it. Swapping Rx/Tx is a breaking change for existing sketches. Changing graphics or small tweaks to connector positions (to properly align with the standard grid) is not. Scaling to change to 1000 px/in should not break things. Switching from px to real world units will break some cases and not others. Tweaking pad sizes for pcb view also breaks some and not others depending how tight the existing spacing is.

:grin: We need an AI to help users do updates.

I just saw another related message about DRY parts. Maybe not quite ‘random’, but choosing to use existing graphics is VERY case specific. As mentioned elsewhere, a ‘standard’ footprint is a good candidate. So are generic schematic representations.

Of course. So i have a bunch of TO220 2 pin, 3, 5 and 7 (yes prime numbers!) SVGs which I will share in a while