A discussion of future direction

When I tried KiCAD 2 years ago the first part I grabbed was not made properly, like most FZ parts, but now it looks like KiCAD has got professional and started assuring the quality of their parts.

That’s depressing because it’s what we desperately need but don’t have to manpower to implement.

OpenTechLab story of submitting parts.

Sorry the start point didn’t takes so I reposted the vid at the correct 24:42

Well, I am pretty newbie in this forum and although my C++ knowledge is still basic, I would like to help with the development of this awesome software. I have already forked the github repository, which has over than +1000 issues (OMG!), which some of the few ones I checked (the old ones) seems to be fixed and hence, not closed.

Would be good if we just started to clean those issues starting with an organized log and see what can be improved.

As far I can see, creating a new part (based on tutorial) is time consuming (but rewarding) due to the use of other software tools like Inkscape / Illustrator for making .svg files. Also there isn’t a list / wikia where users can look for parts without having to check the github repository or the part list inside the Fritzing App.

Just adding some questions here because I wouldn’t like this open source software to be gone. Cheers!

Good questions to ask and most welcome :slight_smile: . Mostly I think we need people that are interested in helping. There is currently not much going on (at least publicly). Once I get a better handle on development I intend on suggesting ways folks can help even if they can’t do development. There are lots of part in core that are broken. Identifying the ones that are would help. For people willing to learn to make parts, picking a broken one and fixing it and submitting it on github (currently the only way parts are getting added) would help. Unfortuantly that is easy to type, much less easy to do (especially because the procedure to mark parts as obsolete because they have been replaced is not currently documented). More people willing to help is the single most important thing we can get in my view. There are a number of folks here (such as me) that are willing to help at least with the parts we know (which is mostly parts creation).


Great! Well, I am a bit busy right now but I have already forked / cloned the repository in order to check the spanish translation and make some fixes since it is awful as hell those broken spanish messages. As soon as I could, would start traveling deeper with the core thing and understand what could be fixed. Again, not an expert but willing to help.

The willing to help part is the most important. At the moment I’m mostly ignorant of what I’m doing as well but I have the advantage of being retired and thus have time to do what interests me so I can allocate the time to learn and do things. That is a lot harder for folks still working I expect that is the problem the original developers have, Fritzing got this far as a funded research project, open source is a lot harder/ slower as the time isn’t funded.


You said you currently updating / fixing the current broken parts, do you have any log regarding that? Since I can’t find the part list getting fixed on github (so weird) and hence, it would slow down the ones willing to help.

We should start organizing that issue first while other folks learn about the C++ code inside the program.

My usual method of finding broken parts to fix involves running my parts checking script against the core parts directory in Fritzing (it can be set to process all the parts in a directory and produce a list of the errors it finds, on core it is several megabytes of text :slight_smile: ). Many parts show errors. I’ve got most of the raspberry PI parts fixed up (the Zero is the only one currently in core because unlike the others it had an incorrect PCB that was causing problems, the rest are just not quite standard). Some of them (the Sparkfun wireless card, Sparkfun pushbuttons) I have found while fixing parts that folks are having trouble with. One or more of the Arduino parts are causing errors during the database load in development and startup (but aren’t breaking Fritzing) they are probably next on my list. I also have a lot of parts I have made for people and posted in here but not done the work to get in to core. At the moment I’m trying to get (and document!) a development environment up and running to be able to install a new version of Fritzing with the bugs I’ve fixed on Windows so I can run them and test if they really work or are going to break something else. At the moment I think that is the most valuable thing I can do since that documentation may help others start development (which is the #1 thing we need). After that the parts checking script could use some more work as well.


Hey folks,

I can use all the applications required to make parts, I just havent found a coherant explanation of how to do it based on the current release. I don’t mind a learning curve if I think there’s a small chance of acheiving whats reqired. Tell me to do something Peter. I likes learnerin’ fings.


When I came to fritzing 3 or 4 years ago, asking in here was how you learned to make parts. To some large extent that is still true, but here are two sets of tutorials that explain making parts with the current Fritzing version (most others are for older versions:

I will give fair warning that I don’t find parts editor particularly useful and don’t use it, Old_Grey did use parts editor (but has I think moved to Kicad and no longer posts here.) If things are unclear in my set, please post and I’ll try and fix them.


Great, I’ll start there, I do see posts for parts and think I would be able to help, as I do work from home most days and have time to spend half an hour to add to available parts.

There’s a picture of the tester home made PCB, of the part you made. I’ll get the software right and order a few boards.

If I could ask for only 1 bug to be fixed, it would be to remove the delay in dialogs opening and changing folders!

Can you provide an example? I’m either used to it or not seeing it. The next step is to make sure there is an issue open on github for the issue, and then up vote it (although I don’t know exactly how you do that …)


In 10.14.2 when I click to open the file dialog, it takes 30 to 60 seconds to open and then when I go to change folders, I get another 30 to 60 second delay.

From the 10.14.2 I take it this is MacOS? On Windows I don’t see that. The open and folder changes are basically instant. I think the best bet would be to open an issue on github, as a quick search shows no open of closed reports of lag in opening or changing folders. I also don’t remember any similar reports in here (although I may have ignored them as Mac OS, which I know little about.) There may be interesting information available by starting the debug log (Help->Enable debugging log) although it doesn’t report anything until I actually load a part on Windows. As well it would be useful to know if anyone else is seeing a similar problem or if it is only your machine and/or OS version and if you are using the latest 0.9.4 Fritzing version.


Just for another reference point, I do not see the issue on Fedora 31 linux either. With either 0.9.4b, or the latest 0.9.5 dev version.

Filed a repot on github, debugging doesn’t show any issues.

Yah, that is what I expected from the test I did but it was worth at try. If you are a coder, something like strace (as MacOS is FreeBSD under the covers I think) may tell you what function is taking all the time. It looks like something times out before proceeding but I don’t have a clue why. Since we aren’t hearing other complaints, I suspect it is something related to your machine. Shutting AV off and trying running Fritzing may be illuminating, various of the AV programs have caused issues like this in the past.


I dont have any AV running!

It’s the TCCD process, for some reason Fritzing is trying to access contacts which is whats causing the issue.

Add that in to the github issue, as it should provide them with a clue maybe. The more info available the better the chance of an explaination or fix I expect.