This maybe should be in developers but I choose here instead. This is a “put up the flag and see who salutes” type discussion. Below are a bunch of things that I think Fritzing could use (the key point here being I, you may not agree 
).
Parts standards:
The FritzingCheckPart.py script when run against core finds a lot of errors. Considering how (and whether) to try and fix those indicates the need for some further guidelines / standards for parts creation. The Parts file format document on github here:
provided most of the things the script checks for. There are however a few that aren’t covered and probably should be if agreement can be reached.
Below is my list, hopefully you will add yours and/or indicate why mine are a bad idea.
-
svg file doc height / width in inches, view box at 1px = 1 thou (i.e. height * 100 and width *100) as suggested in the parts file format doc. A Howto article on converting an svg that isn’t compliant in to one that is in Inkscape would be a good thing. It is possible if not exactly easy, and could certainly stand some automation with a python script to make some or all of the needed changes.
-
schematic connectors .1in or .2in long on .1in centers, part as small as possible for max parts per schematic page and part interoperability (there will likely be exceptions though)
-
in schematic inputs on the left, outputs on the right (more a guideline than requirement though). For parts such as the Raspberry PI with dual row headers in breadboard the first row of the header on the left of the schematic and the other row on the right of the schematic in the same pin order as breadboard. That is what I am changing all the PI parts to.
-
schematic terminal 10 thou rectangle as standard, line widths 10 thou for consistancy. This one implies a source change as generic IC and the headers generate 0 width terminals which break Inkscape. So we need to change the parts generator in the source.
-
breadboard default alignment .1 in (for breadboard compatability) even if the part is smd and thus smaller. In that case mount it on a breakout board with .1 connectors even if there isn’t one available yet.
-
Think about making the part perf board friendly (or two parts, one standard breadboard format, one perfboard friendly where the part only covers the physical space it would take up on the perfboard which may make the connectors in an odd place such as the to220 regulator part here:
Are top down viewed components available in Fritzing?
Figure out a new tag for perf board friendly parts so people can find them with search.
-
Make the parts checking script check for all the cases (it does many of them now, but there are more to add).
-
Do a clean up of core parts. I have already started on this with the Raspberry PI parts (the Zero which was incorrect, is done and loaded and the rest are in progress as I get time). Focus first on parts that are broken (I’ve fixed three or four some in core for folks that discovered they were wrong) and moveing on from there as time / interest permits. That is part of the drive for parts standards above. We need to know what we are aiming towards when fixing parts.
-
Once we have come to a consensis (assuming we can
) get buy in from the parts maintainer since without his agreement this goes nowhere much although the guidelines are still useful.
Now on to a development wishlist:
-
fix bugs! First and foremost. There are lots of them that could use work and development is starting somewhat and the development environment now works much better.
-
Change the schematic terminalId size on gererated parts from 0 width to 10thou (assuming proper scaliing). While this is covered in 4 below, this is possible in the short term where 4 likely isn’t.
-
Figure out a modification to allow us to specify an existing svg in core parts (perhaps core in the svg name in the fzp file). That is a potential big win in that for genric IC for instance there needs to be only one svg for each package size making each part smaller and taking less bandwidth to download it. It also enables a standard footprint library from core in pcb view rather than the current find one where ever you can method.
-
move the generated parts stuff (variable length ICs, variable length headers) out to a “plug in” type interface that isn’t dependent on source changes to change it (and would allow for local versions for specialized tasks). I’d prefer to do it in python, but we will see whats possible. The idea is to be able make parts that are changeable with inspector without having to change the source and make a release just write and install a plugin to do what you want. We would need to figure out what inspector does internally and how to design this, but I think it should be possible.
There is my current list, feel free to add to it, or disagree . Also feel free to volunteer to do some of it!
Peter
at least in this version)
Two distinct thoughts from those words:
