A discussion of future direction

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

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.

Peter

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.

Peter