A discussion of future direction


#21

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.


#22

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


Build instructions for Linux and Windows
#23

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.


#24

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


#25

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


#26

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!


#27

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


#28

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.


#29

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


#30

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.


#31

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