A discussion of future direction

The very first part I grabbed when I started in KiCad was wrong, and that’s when I realised that non engineer people making parts for a free EDA are always a risk, so I went back to FZ. Making a full 3D part in KiCad is probably just as hard as a FZ part because it has a very visual BB view - something that others don’t have -. You either like FZ or not,

@vanepp, @StickyNote, At friends of Fritzing, http://friends.fritzing.org/ it might give you some insight on how Fritzing got started and first funded. Fritzing is an open source educational tool designed to fill in a gap during the beginning of the Arduino revolution. A lot of things have changed since then and I don’t think anyone had any idea how this DIY electronic revolution was going to go…

Some of the fab houses have their own EDAs and of course you have the commercial EDAs. Some of them do pretty neat stuff along with their own learning curve… Fritzing is in a class by it self and shouldn’t be compared with the commercial EDAs. Many of Fritzing parts are provided by people like you and me and usually not tested for errors. But I believe Fritzing still does exactly what it was designed to do; and that is to take the student from learning how to read and draw a schematic, test it out on the breadboard, and then design and build a PCB prototype. Like any new program has its own learning curve, it takes awhile to get the hang of it. Fritzing is a lot easier then some of the EDAs… you just got to learn the little tricks… There are things you can do with Fritzing that you can’t do with the commercial EDAs.

I think the most difficult thing about Fritzing is getting Inkscape down to a science. Inkscape has a lot of settings and if they are not setup right, your .svg file does some strange things when imported into Fritzing, “like your scaling problem or strange through hole sizes…”. One of these day, Fritzing will have its own graphics program for creating the .svg files for parts which will make things a lot easier to edit or create new parts.

2 Likes

I have read that, I just wasn’t involved in Fritzing at that time so am not all that knowledgable on the history involved. I can clearly see the results though :slight_smile: , the underlying design of Fritzing is awesome and very well thought out.

I’m hoping my parts checking script (unfortunatly along with a lot of work) will help correct that. I’m working on cleaning up the Raspberry PI family (the zero is already done as it was broken) and will branch out from there, with priority to broken parts (with pauses to fix the script as it breaks :slight_smile: ). That’s why I started this thread as what I want may not be what the community wants or needs.

Even worse is that the two of them have different (and not very compatible goals: Fritzing want’s the svg tiny subset and Inkscape wants to be CSS compliant which Fritizing doesn’t fully support. Neither is wrong, their goals are just different. Again my python script is partly designed to fix that. It takes the output from Inkscape and modifies the parts of CSS that Fritzing doesn’t support in to equivalent xml (I hope) for Fritzing (current inlining style commands and removing the px from font-size commands). Ideally the script would move in to the Fritzing load routines to occur automatically on load, but that is a future. I’d like to see the script remain external to Fritzing (just called from load) so the script can change to track Inkscape changes without having to do a new release of Fritzing but we will see.

Hopefully that will become true, although I suspect breadboard is mostly still going to need an svg editor for many types of parts, but for it to happen we need to get people developing. There is light at the end of that tunnel though, the development environment is now working again and I (and I hope others) are working on fixing some of the bugs. I have a fix for the segfault and hang caused by a corrupted part submitted as a pull request and am working of figuring out how to get parts editor to delete the files it creates in the mine parts bin when it makes a part (this is considerably more exciting to do than the first fix). If we can come up to speed on the code base we may be able to start working on parts editor. There is a todo list in the source that describes some of what they thought should be done next.

Peter

I think the guy wasn’t interested in finding out what happened - or he would’ve supplied the .fzz -, he just wanted someone to blame. The drill.txt showed 3.1, 3.8, alternating holes, so if the PCB came back with 3.8, continious it wasn’t FZ’s fault.

The part checking script is good, but it still leaves the problem of miss labeled parts, i.e. a 3.5mm screw terminal that is actually a 3.81mm.

BB view is very useful, and my suggestion incorporates that. I may not use it as much as you, but it’s still there! I am a results-oriented person, and I tend to favor the simplest and easiest path to arriving at desired results. To this end; by suggestion was to simplify the parts process into a simple modular “group” of elements to serve the same purposes as the current parts and editing, without locking into a zillion parts that only serve one function. Here is a quick example of what I mean:

Let’s say we want to incorporate an IRF540, and there is no part. Easy. In schem-view, drag out some pins, and “group” (function) the pins and attributes (Goup Name: IRF540, Part Class: Q, Pin Numbers: 1,2,3, Image: TO-220, etc.) It looks like this in schematic view:
Schem-group

And connects like this in PCB view:
PCB-group

And appears like this in bread-board view:
BB-group
A handful of generic images including standard transistor types, adapter boards (non-specific like they are now, which all look the same but are repeated for each different part), resistors, and so on. Instant parts, without megs on megs of individual and difficult-to-edit parts, and always without the exact one you need. I’m sure there is a more logical or sexier way to represent them, but it’s a quick example of concept. Is this too simple? What am I overlooking? Thanks for your input.

1 Like

I know what you mean, and you can do something similar by locating vias off the PCB and group moving them in, it’s just that all EDAs use a complete footprint for a part so that method seams like a patch for the more common way.

When I started I had trouble with the complexity of svg drawing - it’s nothing like raster GIMP - so I used every method to skirt around actually learning how to draw in INK - I imported pdf drawings -, but once I learnt to draw parts, which isn’t that hard, I find it a snap to just do the correct footprint and import it into a new part.

I made a tutorial video series that teaches you both FZ part making and INK drawing all in one hit, and that 90min will save you 10’s of hours fumbling around.

KiCad has more features, but the clunky way you have to use it is like going back to the stone age - it’s a lot of separate programs under one wrapper that don’t talk to each other -. You select parts for the SCH, layout the circuit, export the parts from SCH, import into PCB, pick footprints for the parts - SCH and PCB drawing are not joined -, and lay them out again. And I think if you change something in PCB you have to also do it in SCH, because the views aren’t connected. I suppose you get used to it - you have to learn a lot of short-cuts -, and it has some cool stuff, but simple things like a junction you have to grab like a part, where’s FZ you right-click or pull a trace. When I started 2 years ago I trialled FZ, Eagle, and KC after watch hours of tutorials - it’s the only way to learn them quick - and I liked FZ, maybe you’ll like something else.

I think what you are suggesting is already present in the mystery part. Where it falls down is when you need a custom footprint. I expect as @steelgoose said earlier the correct answer is to finish the parts editor (which is currently not finished). To do that we need to get people willing to put time in to development which currently isn’t happening (or at least not happening enough).

Peter

Thanks for listening, and I wanted to assure you this is not hypothetical. What I described above is actually what I do with Fritzing every day, as my process improvement workaround. My frustration is not having the simple “group” function in order to manipulate the blocks easily for moving, flipping, etc. and assigning an image. With these abilities, grouping becomes a very powerful and easy-interface tool.

I understand Fritzing was not intended to be an EDA, and in that vein, should not necessarily be tied to traditional EDA methods and their limitations. I don’t want to move-on from Fritzing. These minimal functions would empower it so I would not have need to, and I feel helpless as I have no coding ability to help in attaining it. Thanks all, for what you do for Fritzing.

I think this is likely the problem, the group function isn’t simple internally. The code is set up to deal with parts as svg files (not groups of svg files as your group function would need) so you would need something capable of combining several svg files in to one i.e. the missing svg editor in parts editor. I’m having an exciting time trying to figure out enough of how the code works to fix some of the bugs I know about (at the moment related to saving and deleting parts) where the code already knows how to do what I need somewhere else but not in the place that I want it. It is difficult to follow the flow of code to isolate how it eventually deletes the files which is a relatively simple task. Manipulating svgs is going to be much more difficult (although again, the code currently does it). So basically I wouldn’t hold my breath. Unless we can attract some of the original developers back to provide at least guidance and suggestions of how things should be done, improvements (even as simple as bug fixing) are going to take a lot of time.

Peter

Out of curiosity, how far from a Release Candidate or another Beta was ver 0.93b?

Assuming “was” above should be “is”, it is hard to say. The new gerber code (which is the biggest change) has been backed off as not working. The development environment is now building correctly (it didn’t used to). It has been said if we get a reasonable stable build, that they are agreeable to doing a new release but without the gerber code I don’t currently see enough fixes to make a release worthwhile. I’m working on fixing some of the file type bugs in case there is a new release , but its going slowly. So I’d guess it isn’t going to be soon but I don’t really know. Getting a stable buildable head is a good start though.

Peter

I don’t know if this belongs here but if you’re talking about future features I believe the parts bin needs a radical rethink.

It must have worked as a POC with a very short component list but I’m finding it very hard to navigate now and surely it will get worse if ranges of ICs are added.

Sure, we are discussing future directions and volume isn’t so far a problem :slight_smile: getting people willing to do the work is though . While I agree both parts bin and search need work (search is even worse than parts bin in my view) it is well down my list after learning the source to fix bugs and add new features, doing more work on the parts check script and fixing up existing parts. That said, of the two parts bin is easier because non core parts are user changeable (search is possibly a code change or possibly better tags in individual parts either of which are more complex). You can move things around in the parts bins and create new bins for your self with the current code with no code changes needed. If you (or any one else reading) would like to help, that would be an easy place to start. Move stuff around in the bins and add new bins to better arrange the bins and post what does and doesn’t work for you (including what code changes would improve the situation but realizing implementing is likely to take a long time). For core parts, once you have a better arrangement (which you can demonstrate by copying the part in to the mine parts bin then moving it where you want) that can be done by submitting a change to the parts repro on github which is also much easier and more timely than a code change.

Peter

Have you got (a reference to) information on getting the development environment setup?

I have been looking around and trying to get a VM setup. The information I am currently seeing seems to say that 0.9.3.b was built and tested using Ubuntu 12.04 LTS. However, when I spin that distro up in VirtualBox, I can not get the QT SDK to work. It installs, but then at run time errors out on the version of GLIBC. Qt wants (apparently) version 2.16 or 2.17. The distro (fully updated) has 2.15.

My usual distro is Fedora. It can install Frtizing directly from the repositories, but only version 0.9.2. Manual installs of 0.9.3 have not worked there, and I have not figured out how to build Fritzing on Fedora. Figured to start from a working build environment, then try moving it across, once I had a better idea of how the build process works. For starters, I do not have qmake directly available on Fedora.

Half way, I can explain how to get it up on Ubuntu 16.04lts Desktop.
So far I’m being unsuccessful on Windows due to problems getting libssh2 to compile to get libgit2 to run. As much documentation as I’m aware of is in https://github.com/fritzing/fritzing-app/wiki although some of it is slightly outdated. Here is what worked for me to get my development environment up on Ubuntu 16.04:

  1. Install Ubuntu 16.04 from their install dvd (just installed and boots on my system without problems).

  2. log in to the installed 16.04 system as a normal user (vanepp in my case) and install in the home directory.

  3. Get Fritzing-app, Fritzing-parts Qt, and the prerequisites boost and libgit2 by

    download boost_1_66_0.tar.gz from the boost site

http://www.boost.org/users/download/

download libgit2-0.26.0.tar.gz from the libgit2 site

(the latest version now works on the head code in both cases as
does the latest Qt version unlike the document above says)

git clone https://github.com/fritzing/fritzing-app

git clone https://github.com/fritzing/fritzing-parts

download and install Qt 5.10 from the Qt site

  1. build libgit2

vanepp@GX1:~$ tar -xvf libgit2-0.26.0.tar.gz

cd libgit2-0.26.0

mkdir build && cd build

cmake …

cmake --build .

and it is in

~/libgit2-0.26.0/build

cd …/…/

make a symlink so Fritzing will find libgit2-0.26.0 in libgit2 where it
is expecting it.

ln -s libgit2-0.26.0 libgit2

sudo ln -s /home/vanepp/libgit2-0.26.0/build/libgit2.so.0.26.0 /usr/lib/x86_64-linux-gnu/libgit2.so.26

so the Fritzing binary can find it using the system library path (this
indicates we have a wrong or incomplete library path somewhere but this is an easy fix for now …)

  1. Install boost in to fritzing-app/src/lib/boost_1_66_0

(fritzing will find and use the older boost library in the system but I want the linux and Windows environments to be the same and Windows doesn’t have boost so I installed the latest here too)

cd

(to get back to the home directory if you weren’t already there)

cd fritzing-app/src/lib

tar -xvf …/…/…/ubuntu_distribution_files/boost_1_66_0.tar.gz
(substitute the path to where ever your copy of boost is!)

cd boost_1_66_0

./bootstrap.sh

./b2

and after a fair while boost will build in

fritzing-app/src/lib/boost_1_66_0

where fritzing is expecting it.

  1. Start qtcreator

the icon on the desktop.

In the Qtcreator window click Open Project in the main window

enter fritzing-app and click on phoenix.pro

and the configure project window should open.

on the left side under build and run click on

Desktop Qt5.10.0 GCC 64bit

click on configure project

which should configure the project

and produce:

Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz
Project MESSAGE: allways true on win32. leads to build problems
Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz
Project MESSAGE: allways true on win32. leads to build problems
Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz
Project MESSAGE: allways true on win32. leads to build problems
Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz

in the general messages window.

Note doing anything else clears the configure screen and it is unclear if it does the configure or not.

on the left side tool bar click on projects

then under build and run click on

Desktop Qt5.10.0 GCC 64bit

then on Run

add the following to command line arguments (which should be currently blank)

(substituting your correct paths to the various things)

-f “/home/vanepp/fritzing-app/” -parts “/home/vanepp/fritzing-parts/” -db “/home/vanepp/fritzing-parts/parts.db”

in my case (likely different in yours)

click the run arrow (bottom left green arrow above the debug arrow)

in the Compile output window at the bottom of the Qtcreator screen you should see

Info: creating stash file /home/vanepp/build-phoenix-Desktop_Qt_5_10_0_GCC_64bit-Debug/.qmake.stash
Info: creating cache file /home/vanepp/build-phoenix-Desktop_Qt_5_10_0_GCC_64bit-Debug/.qmake.cache
Project MESSAGE: found libgit2 include path at /home/vanepp/fritzing-app/…/libgit2/include
Project MESSAGE: found libgit2 library in /home/vanepp/fritzing-app/…/libgit2/build
Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz -L/home/vanepp/fritzing-app/…/libgit2/build -lgit2
Project MESSAGE: found libgit2 include path at /home/vanepp/fritzing-app/…/libgit2/include
Project MESSAGE: found libgit2 library in /home/vanepp/fritzing-app/…/libgit2/build
Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz -L/home/vanepp/fritzing-app/…/libgit2/build -lgit2
Project MESSAGE: found libgit2 include path at /home/vanepp/fritzing-app/…/libgit2/include
Project MESSAGE: found libgit2 library in /home/vanepp/fritzing-app/…/libgit2/build
Project MESSAGE: using Boost from src/lib/boost_1_66_0
Project MESSAGE: libs -lz -L/home/vanepp/fritzing-app/…/libgit2/build -lgit2
13:09:55: The process “/home/vanepp/Qt/5.10.0/gcc_64/bin/qmake” exited normally.
13:09:55: Starting: “/usr/bin/make” qmake_all
make: Nothing to be done for ‘qmake_all’.
13:09:56: The process “/usr/bin/make” exited normally.
13:09:56: Starting: “/usr/bin/make”
/usr/bin/make -f Makefile.Debug

which indicates it found and used the built libraries

Now switch to the application output window and when compilation completes
you should see:

Starting /home/vanepp/build-phoenix-Desktop_Qt_5_10_0_GCC_64bit-Debug/Fritzing…
“translation en_CA loaded 1 from /home/vanepp/fritzing-app//translations”
“got transaction”
"no connector is found for bus nodeMember connector32 in "
"no connector is found for bus nodeMember connector60 in "
"no connector is found for bus nodeMember connector33 in "
"no connector is found for bus nodeMember connector59 in "
"no connector is found for bus nodeMember connector30 in "
"no connector is found for bus nodeMember connector55 in "
"no connector is found for bus nodeMember connector56 in "
"no connector is found for bus nodeMember connector45 in "
"no connector is found for bus nodeMember connector57 in "
"no connector is found for bus nodeMember connector29 in "
"no connector is found for bus nodeMember connector58 in "
"no connector is found for bus nodeMember connector14 in "
"no connector is found for bus nodeMember connector28 in "
"no connector is found for bus nodeMember connector32 in "
"no connector is found for bus nodeMember connector60 in "
"no connector is found for bus nodeMember connector33 in "
"no connector is found for bus nodeMember connector59 in "
"no connector is found for bus nodeMember connector30 in "
"no connector is found for bus nodeMember connector55 in "
"no connector is found for bus nodeMember connector56 in "
"no connector is found for bus nodeMember connector45 in "
"no connector is found for bus nodeMember connector57 in "
"no connector is found for bus nodeMember connector29 in "
"no connector is found for bus nodeMember connector58 in "
"no connector is found for bus nodeMember connector14 in "
"no connector is found for bus nodeMember connector28 in "
“referenceModel::loadAll completed”
/home/vanepp/build-phoenix-Desktop_Qt_5_10_0_GCC_64bit-Debug/Fritzing exited with code 0

as it hopefully creates the parts database.

and indeed:

vanepp@GX1:~$ ls fritzing-parts
bins CONTRIBUTING.md LICENSE.txt parts.db scripts user
contrib core obsolete README.md svg
vanepp@GX1:~$

indicates a parts.db has been created.

Now in the projects->run config change

-f “/home/vanepp/fritzing-app/” -parts “/home/vanepp/fritzing-parts/” -db “/home/vanepp/fritzing-parts/parts.db”

to

-f “/home/vanepp/fritzing-app/” -parts “/home/vanepp/fritzing-parts/”

for normal operation.

Then click the green run arrow again and Fritzing should start normally.

and we now have the user directories

vanepp@GX1:~$ ls .config
compiz-1 gnome-session mimeapps.list QtProject upstart
dconf gtk-3.0 nautilus QtProject.conf user-dirs.dirs
evolution ibus pulse unity user-dirs.locale
Fritzing libaccounts-glib Qt update-notifier
vanepp@GX1:~$ ls Documents
Fritzing
vanepp@GX1:~$

When (or perhaps if, as I’ve been at it a week now with little progress) I figure out how to get Windows running I’ll post a similar listing for Windows.

Peter

1 Like

Looks like you dumped your notes/log for doing the builds.

I was using the wiki as the base for my explorations. As you say, seems out of date. Versions being referenced do not currently work together.

Perhaps much of that should get into the wiki as well. At least as an addendum.

That should give me plenty to get a working base environment. Then I can start working forward.

That is exactly my intent once (or perhaps if :slight_smile: ) I get Windows working. It will likely be here because I don’t think I have access to the dev wiki. I didn’t really think you needed all that detail but the more people I can get interested in trying to develop the better. The versions listed in the wiki do work still, I started on Qt5.6 and libgit2.0.24.4 I think as that was the latest version that would compile without errors. Someone with commit access a few months ago made some changes so that now the latest versions of libgit2 and Qt work (probably at the same time the gerber change was backed out as not functioning correctly).

Peter

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.

EDIT
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).

Peter