It is the things that you don’t know about that cause problems. I’m trying to populate (correctly) as much as practical, so that all of the designed functionality is available going forward. Like the <spice>
tags. I understand what they are for. For specific components the information works well, but generic parts need to be able to provide instance specific values from external information. I see the syntax for providing substitutions, but everything seems to come from property values. If the user can not set them (like the part number), then it is very limited.
We really need access to those historical design notes. Having some of that high level intent would making understanding implementation a lot easier. Even if that implementation ended up branching away from the original design.
I’ve been using that python checking script as a lint check for my parts. It would be helpful to be able to turn off some of the warning messages. From the command line. I already know that I am working with through hole parts, so I do not need to be told how to switch to surface mount. Same for the svg already processed messages. With what I am doing, reuse is the expected case. More useful would be an orphan check, reporting any svg files that did not get referenced by any of the fzp files. Or delay reporting the already processed message until something in the svg requires reporting in the current context.
Knowing more about what the tags (are intended do) do could help in that cleanup process. Or point to other validations to add to the checking script.
The part set I am creating obsoletes 1 core part. The information I found is “How to contribute a fix” on page fritzing-parts/CONTRIBUTING.md at master · fritzing/fritzing-parts · GitHub. That seems to be incomplete, or changed. I did a bulk cleanup to adjust the family names in the obsolete parts cleanup obsolete family text prefixes by mMerlin · Pull Request #158 · fritzing/fritzing-parts · GitHub. To match the partial information I had found then. The latest information does not say anything about modifying the family name. I think it is necessary to change the family name, so that the obsolete part does not show up as available in the selectable options in Inspector. For the part that replaced it. Code could handle that instead.
referenceFile
attribute is in the fzp files, not svg. It is not part of svg. There is no reference I can find for it in the svg attribute documentation.
I need to put creating a complete build environment for Fritzing back on my todo list. I successfully built 0.9.2b on a Ubuntu 12.04 VM a couple of years ago. After a lot of work to get all of the correct dependency versions together. Then priorities changed again.
We need to get a discoveries section started someplace. One if the wikis is an obvious choice. To record some of this information. As a substitute for the full documentation that does not yet exist. Or use as the WIP documentation. Initially could be some cut and paste from the forum threads. But gathered together, and potentially updated with the most recent/complete details.