Fritzing is somewhat hard to use


‘Experiences’ are concise in their descriptions and meanings. Rusty training wheels…:face_with_raised_eyebrow:

SO from what I understand, Fritzing, ‘DOES NOT, fit your standard’, we hear that.

What can be done? Git-hub, fork repo, learn QT, contribute. What more can I say? It’s not hard for the savvy… I will admit, Like anything though, to become better, it probably needs alot more development time. BUT, does that make it unusable? Far from it actually…

Fritzing is an easy way to accommodate everyone from beginner to advance user. Learning curves are different for everyone, for every software package…(life in general)

So it’s all apples to oranges.

EVERYONE is entitled to their opinions, but you know what they say about opinions… haha everyone has one…BUT I will say an import/export to/from KiCAD feature would be A+

Thanks for giving it a go Robert!


The other way you might be able to do it is have a normal sketch, and one with 3.3V and GND reversed. Then just gerber both and swap the top layer file.


I think a big part of the problems I am having is in how the graphics is working. Either QT is a very slow library (seems unlikely) or Fritzing is not using it effiently (very possible). I am running Fritzing on a Raspberry Pi, but using my laptop as a display using a SSH X11 tunnel. (And no, it is not the SSH X11 tunnel that is slow – I do the same thing with KiCAD, the Arduino IDE, JMRI, and other X11 programs and everything else runs fast enough. The Pi does have a 100mbit Ethernet and I have a GBit switch – the network is itself quite fast enough.)

And maybe it is the version I have on the 'Pi: 0.9.0 (it was what was in the repository for Raspbian).

Another problem for me is that I don’t have a good Internet connection at home – I am on dial-up (yes, really!), because that it all that is presently available where I live, here in Western Mass. In order to do any development work with Fritzing, I will have to sneaker-net about 11meg of .deb files (for the 'Pi – my x86_64 laptop is running CentOS 6 – the libraries, etc. are too old and yes, I need to update it, but again, that is a complicated process, complete with the complication of poor Internet connectiveity). Also , I have not done any GUI programming in C++ in a very long time and have never used QT before, so there will be a pile of learning there.


This topic came up before, there is a PI version of the current release (0.9.3.b) on one of the PI repos. You would be better to run 0.9.3.b than 9.0 (which I don’t think has parts manager). It should be available here:

I hate to think what a Qt download would be like on dial up, on ADSL it takes 8 or 9 hours.Fritzing will get slow if you are using a higher resolution that the default .1in in views. It usually takes about .001 in to really slow down my I7 but it can. Part of the problem is all the parts are svg and it needs to render all of them.



It looks like that is not going to be easy to do, unless I do a massive upgrade of the 'pi to Stretch (at least all of the libqt packages). I might be better off trying to install it on my BeagleBoneBlack… First I will try building from source and see how that goes.


OK, am going to take fruitloops (my workbench / build box Raspberry Pi) and snoopy (my BeagleBoneBlack) to library tomorrow and use the high speed Internet (all of 20mbits) to download stuff (maybe 0.9.3B on the Beagle, and the libraries to build it on the 'Pi)…


Oh man… maybe kinda off subject… But I have a pretty big project based around a BBBW. You want to run fritzing on this thing? The BBB is just painfully slooooow… I mean it works and serves its purpose. BUT ouch… The Pi is a bit better… But still ouch. Good luck at the library!

I am interested to get my hands on the newer BeagleBone AI… That seems to have a bit more promise…


It is just that BBB is running Debian 9 (Stretch), which seems to be what Fritzing 0.9.3b wants and the Pi is running Debian 8 (Jessie), which means I am limited to 0.9.0, unless I can build 0.9.3b from source.


Are you going to compile these sources on these actual devices? Say versus cross-compiling on a something that will do it in a fraction of the time…?? 24 cores plows threw a compile. BUT For a laugh, I compiled source for a different project that goes with that BBBW-head Unit (unit pictured above). It took days… Amusing to say the least…


I don’t have a 24 core machine. And my 4 core machine runs CentOS 6.


Oh man, this is going to be a full on experience. I do not envy you my man! BUT Should be fun as I am personally curious how long it will take per device. I saw some compatibility issues from BBB to Pi on my project, I to compile a version for each device.


It took me about 3 days to build a cross compiler for embed ARM. And most of a day to build a cross compiler for the ESP32.

BTW: what do I need to tell firefox NOT to grab focus when someone posts a reply. It is excessively anoying.


Next to your home button in the upper left. little i-icon with a circle. click site information for -permissions- X allowed. should shut it up… OR selectively on the bottom of the post, Click on normal and change to mute.


There is no “home” button. I am using an older version of firefox (the new version breaks all of my toolbars and insists on using tabs (which i hate).


OK, I just compiled 0.9.3 on the 'Pi. Took only about an hour. Bitches about (wants the presently not installed new one I compiled eariler – fixed with LD_LIBRARY_PATH), and then complains about not finding any parts, since I didn’t bother “installing” it yet (just ran it as ./Fritzing from the build directory). I did clone the parts repo, so I guess I need to “build” and “install” that. I guess I need to get things installed somehow (I don’t want to install in /usr and mess with apt-get/dpkg’s view of things). I need to do some sort of “fake” install for testing…


That shouldn’t matter. As long as the parts repo is in the same directory where fritzing-app is just running fritzing-app/fritzing works for me without running the release script (at least from QtCreater which may be doing something to make that happen). I’d expect the same to happen if you do the build from the command line.



OK, more random weirdness:

First I thought I had cloned the parts repo. Discovered that I hadn’t. So I cloned it. And things worked (very slowly) at the library with my Pi jacked into the library’s LAN (which in turn is connected to the Internet via a 20GBit Fiber Optic connection.

Now, as for the slowless starting up and in general. When I got home, I rsync’ed things from fruitloops (the machine I took to the library), which is basically a headless build box, although I do have a little monitor for it at my workbench, but that is only so I can run the Arduino IDE to upload programs to MCUs on my workbench (eg breadboarding), to madhatter, another Pi I have attached to my 24" TV. And after dealing will missing libraries (more fun with ssh & tar copying from /var/cache/apt/archives and /var/lib/apt/lists), I started Fritzing on madhatter, and things do NOT work. First I get this dialog box:

Sorry, we have aproblem with the swapping mechanism.
Fritzing still works, but you won’t be able to change parts properties.

The it complains that it cannot find 157 parts. Obvious it is seeing fritzing-parts, but is having some strange problem actually reading the svg files.

Question: does Fritzing 0.9.3 need a live/fast Internet connection to actually work?

Fritzing 0.9.0 only complains that it can’t get to the blog, but otherwise works fine (except it is slow when used through the ssh tunnel).


No, although if it has one it first connects to github to see if there if the parts repo is up to date. If it is interrupted while doing that it tends to corrupt the parts database and gives messages as you are seeing. The first thing to try is a rebuild of the parts data base by entering any view except the welcome screen (i.e. breadboard schematic or pcb) then click Part->Regenerate parts database . That will work for a while and then exit Fritzing, if you restart Fritzing that may have fixed the problem. If not you need to delete the two user directories (of if you have sketches which seems unlikely, move them aside). When it doesn’t find them Fritzing will rebuild them and if it have a network connection try and contact github to check the parts repo. Even though it seems unresponsive (we need to put up a progress screen, but it isn’t there now) wait on a slow machine / connection it may take a while. For me it is usually a couple of minutes on a fast machine and an adsl connection but I have heard reports of 5 minutes or more in the past. The two directories on linux are


I assume they will be the same on the PI.



Well on a 20 Mbit connection (what we have at the library, although I was “sharing” it a batch of patrons surfing the net, maybe a couple of teens watching videos) it is terribly slow. And with a dialup, it just trashed the database. There needs to be an option to disable the update check. I know you are going to say that people need to be up-to-date, but that is a luxury that some of us just cannot afford. Here on this side of the pond, Internet access (at anything like reliable broadband speeds) is actually rather hard to come by in places (it is pretty much non-existent in most of Rural America). Small towns have no cable providers and what passes for a telephone system barely works (there are times and places, that even 911 calls are not really available), and DSL is a dead technology – Verizon won’t entertain new DSL accounts and won’t build new DSL infrastructure). Oh, Verizon does the least it can get away with in terms of maintenance and many states lack the ability to make Verizon do anything Verizon does not want to do (the Commonwealth of Mass is a smaller entity than Verizon).

PS: the Arduino IDE does in fact have a preference setting to suppress the update check on startup.


Actually I completely agree, it is on my list of things to do. There are a variety of cases where it would be useful, teachers for one with a readonly parts database who don’t want the delay of the check at the start of a class with many students logging in at once. A flag to allow you to disable it if you choose seems a good bet.
The trouble so far has been getting development even started. Luckily the Anseler folks see it as good business and what I have seen so far is encouraging. There were some recent commits in the dev branch dealing with the parts swapping issue, so work is going on there. I believe if you have no network access it will try to contact github (for a while, which is what the teachers were objecting to) then quietly proceed without doing the update. On Windows 7 (which I’m running) it has been broken for almost a year as the current libgit2 version on Win7 doesn’t support tls1.2 and github no longer accepts tls1.1 so I have to clone the repository and manually do a database rebuild to get new parts updates.