Suggestions for additional documentation

[microMerlin]

@vanepp

2. svg name unique to this part only.
   svg names should be unique to the part so that a change does not affect any other part in most case. The potentiometers in this case are an exception because it is desirable for the schematic svg to be common for all pots! This avoids a change in one part accidentally affecting many parts which I think is the better option than saving some space in the repository by sharing svgs.

There are other cases where a common svg file across multiple parts is desirable. Many parts have the same standard PCB footprint. Those should be shared as well. There could be multiple files for a single footprint, for things like different pad sizes and shapes. BJT, MOSFET, op amp, are more cases where the schematic should be reused. I think there are many cases where existing parts have inappropriately created a new svg, where the only change is the addition of a part number. That can be done using a text label part in the sketch instead. The “schematic” tends to be the same for most “SPI” or “IIC” part modules. They do not really need unique svg files.

The existing documented naming convention supports this. The “description” portion of the file name can be as specific or generic as appropriate

It would also be “helpful” if a compatible footprint could be substituted in a sketch, without needed to create a complete duplicate part.

@vanepp

5. Connectors should be a drawing element not a group.
   While specifying a group name as a connector works (Fritzing appears to use the first drawing element of the group as the connector) if you ungroup the svg the connectors are all lost. I think it is worthwhile to not allow groups to be connectors for that reason (ungrouping the svg will make the part not work anymore because the connectors are gone!) The breadboards are the most notable example of this in core parts although there are probably others. The development version of FrtizingCheckPart corrects this.

It is unfortunate that one of the common ‘fixes’ for the mess that Inkscape makes, is to to do mass, recursive ungroups. It would be nice to be able to «safely» put the connector id on a group for the non-circular pcb pads. That would allow tying the associated graphics together. I use an alternate cleanup process, that deletes “unused” groups (no attributes on the “g” element), and ids. It explicitly keeps any id that starts with “connect”.

@vanepp

6. Connectors should be in pin order and the last thing in the svg.
   Doing this allows renumbering svg files with a python script by scanning for the first occurance of connector (or connector0 as you choose) and then assuming all elements after that are connectors which should increase in pin number by 1 for each new connection. I have and use python scripts that do this, although they need some additional work on options to be releasable.

A python script that processes svg files should not need the ids in order. The standard xml file handling tools should be able to collect all of the elements with “connect…” ids, and allow sorting and updating them regardless of where they are in the file. Renumber needs to be done simultaneously with the fzp file. Also across multiple parts, if the svg is shared.

Reusing existing svg files can conflict with the desire to have connection numbers both in increasing order, and matching the connection number in the fzp file. When the only difference for a part is the pin ordering, there is really no need for a new schematic. Just to reference the correct ids in the fzp file. The connectors can be in pin number order in the svg, but they might not match the connector numbers in the fzp.

@vanepp

7. Svg file names should end in the layerId
   For consistancy (many parts are already this way) the svg name should end with layerId.svg (i.e. basic_fsr_5_breaboard.svg rather than basic_fsr_5.svg) so it is obvious what layer the svg file is for.

The folder also shows what the layer is, or the (equivalent) prefix in fzpz files. It is common to use the breadboard view for the icon as well. I would not hurt anything to ‘duplicate’ that information with a suffix. I think the file naming convention already includes that.

@vanepp

10. Fritzing version, what to update it to in a part.
    I’m inclined to update it to the current version of Fritzing that you have tested the new part on. That may be unwise (at least without a lot of care!) for parts that have older version dependent elements (for example older model pin headers, change to the current version based on a hard coded Fritzing version. Recognizing this is happening will likely be an issue, as it isn’t something most parts makers are going to take in to accout. It may be that we need to figure out all the cases where this currently occurs and add a test to FritzingCheckPart.py to warn about

Be very clear about that “tested Fritzing version”. Due to code changes over time, Fritzing handles some part details differently based on that version number. If you are making a new part from an existing part, certain things could break if the specified Fritzing version is changed. That said, a really old version number in a part probably means it «at least the new part» should be updated to something more modern, and following the more recent rules.

@vanepp

13. Search parameters cleanupSearch is currently a mess.
    This is a search for ic. I would expect this to bring up all the ics (which it in fact may do!) but why also electrolytic caps (and multiple copies of the same electrolytic cap) boards, switches etc. I’m not sure what can be done about this, but something better than what we have now would be good.

This is getting well outside the current topic of “Suggestions for additional documentation”.

That probably matches because “electrolytic” ends with “ic”. Agreed that it is a mess. Should have selectable options on what to search: «at least» family, description, tag, title, even label, and either sub string or full word matches.

@vanepp

14. What to do about parts that are no longer available?
    The 3 textile pots below are in this category. The manufacturer has apparently gone under and there don’t appear to be any replacements. It will be useful to have the current parts in at least the obsolete parts bin so existing sketches from when they were available still work, but they shouldn’t show up in a search (?) as they aren’t available if you don’t already have one. I’m not sure what the best way to handle this is.

15. No present source for the part.
    If we can not find a commercial source for the part should we just delete it as no longer being useful? I’m inclined to say yes as we can’t get them anywhere.

Fritzing is used by a lot of DIY users. They could have a lot of parts on their workbench that you can no longer buy in stores. A possible alternative to deleting or obsoleting these:

– add a “status” tag with a value of “historical” or “nla”. Combine that with a way to filter the searches and bins by tag values (and save as a preference). Fritzing could default to only showing ‘active’ parts, but a simple toggle would allow those with an overflowing ‘junk box’ of parts to expand the list.

@vanepp

8. No present source for the part.
   If we can not find a commercial source for the part should we just delete it as no longer being useful? I’m inclined to say yes as we can’t get them anywhere. They probably then need to move to obsolete parts so previous sketches still work but I think we should clean up the parts bins by deleting parts that are no longer available. So far I have found and substituted alternate parts for those not found though except as noted for the textile pots, tbey appear to be gone with no available replacement. As part of this require a url to a source of the part, so we know when a part is no longer available. The slide pot is one example of this. I can’t find an example of a 2.5in slide pot that has a pcb foot print that matches the part. There obviously was one when the part was made, but there is no url (or manufacturer) in the part to tell us where we might source it. A source of the part seem like a good idea to me.

Just because “we” can not find a source does not mean that none exists.

A url in a part is a convenience, not a requirement. My usual preference for a url «if only one in a part» would be a datasheet, instead of a supplier. At least for anything reasonably generic.

I thing generic parts should be more common in core. Something that is usable to create a Fritzing sketch, that needs to have an ‘override’ specified for the part number. No ‘supplier’ url is is ‘correct’ for that.

A source for parts used in projects is a requirement to actually build it. Like the “nla” suggestion, a “no url” or “no source” flag could be used to filter these without deleting them.