Free Software Activities in October 2018


Welcome to another monthly summary of my free software work. Currently I'm focusing on improving the state of packaging for FreeCAD and its ecosystem of dependencies and related packages in Debian Science. Additionally, I recently revived the FreeCAD Community Extras PPA as a way of staging these packages out to users for testing. If you are a FreeCAD user, developer, or simply a user of one of these packages, I would greatly appreciate your feedback and testing to identify bugs while my packages wait to make it into the Debian archive.

However, in the long-term, I plan to move away from spending so much time on Debian packaging and returning to FreeCAD core development, and a special not-so-secret related project: PostCAD, providing OpenCASCADE geometry & topology bindings plus CAD data and filetype format support for PostgreSQL, a la PostGIS. The goal is to build this out as a rich backend which FreeCAD can talk to about neat CAD stuff. It's a heaping of work, though, so I don't expect to have a public release until mid or late 2019.

I would like to find others who are interested in contributing to FreeCAD ecosystem packaging for mentorship. That way, my efforts are maintained by the community and the quality and availability of packages won't wane with my attention on them. Since FreeCAD participates in Google Summer of Code, this would be a great opportunity for interested university students to learn Debian packaging and improve the state of science & engineering software on Debian.

Anyway, on to my summary!

Debian News

This month, I officially became a Debian Maintainer. This is a basic level of formal membership in the Debian project, and it comes with limited upload rights to the archive. I can only upload packages for which I am marked as a maintainer, for example FreeCAD.

I took advantage of this to upload some improvements for FreeCAD which I had been sitting on. After a few tweaks, the package was ready for an upgraded upload from Experimental to Unstable, which begins the process of candidacy for Testing, the release pocket for the upcoming Debian 10.

Debian FreeCAD Gets Qt 5


Most important about this upload, though was that FreeCAD is finally being built with Qt 5 support. While Qt 5 had been working for quite a while, we were waiting on a dependency to be uploaded to Debian, PySide 2, which finally was uploaded this summer. Because this is a big switch to flip, any testing and reporting of bugs for this Debian package would be appreciated!

FreeCAD Package Structure Reorganization

One of the other major packaging changes for FreeCAD 0.17 is that the package is no longer a single, monolithic freecad package. We now have:

  • a freecad metapackage, which installs the other packages
  • common files and resources (e.g. images) in freecad-common
  • freecad-runtime contains Python 2/3 compatible runtime files
  • the executable built against Python 2, freecad-python2
  • and the library files used by the executable, libfreecad-python2-0.17

There are several advantages to this approach. The first is that since freecad-common and freecad-runtime are just pictures, Python scripts, and the like, we can save space in the archive by only needing one copy of the package, instead of one for each supported architecture. For freecad-python2 and libfreecad-python2-0.17, one can see the advantage in the name: since these are Python 2 specific, we will soon be able to provide their Python 3 counterparts.

Ideally, by the time of the Debian 10 release, the FreeCAD 0.17 package will provide both Python 2 and 3 supported versions, and which one you want to use can be switched between using the alternatives system, which I will explain later in this post.

FreeCAD Python 3 Imminent

Like Qt 5, FreeCAD has supported Python 3 for quite some time. (Workbenches and 3rd party code are another story.) However, in Debian, a Python 3-enabled FreeCAD package is blocked by the pending upload of pivy 0.6. I helped coordinate the upstream release of this package but due to issues with its dependency Coin3D the upload is stalled until those issues are resolved.

Community Extras PPA - Early Packge Previews

Now that we have the Community Extras PPA, it serves as a convenient location for me to upload packages as soon as I have one completed and ready for testing. Here are my uploads this month.

Gmsh 4


Gmsh has released a major version upgrade, which includes removing the experimental Java API and introducing Julia bindings, although this package doesn't do anything with them. The current version in the Debian archives is 3.0.6.

This package is only available on Bionic (Ubuntu 18.04) due to its dependencies. I hadn't tried on Cosmic (Ubuntu 18.10) since I worked on this in the beginning of October and it wasn't released yet.

Calculix 2.14


CalculiX in Debian is currently several versions behind (2.11) so I got a request to package this. However, CalculiX actually spans several packages, but calculix-ccx, the solver, is the only one used by FreeCAD, so unlike the other packages, this one is not quite ready for Debian until the other ones are done as well, since they are separate source packages.

This package is available on Bionic and Xenial (Ubuntu 16.04).

Translated FreeCAD-Doc Packages

One of the big areas for improvement in FreeCAD is the state of its documentation, and I'm glad to announce that one big improvement is on its way. I have been working on a standalone freecad-doc package, since it was removed from the Debian archive for being derived from pre-compiled binary files. This package involves using a local synced copy of the FreeCAD Wiki text and images, and using the script that was used to generate the aforementioned binary files.

The main improvement my package offers is support for the two most complete translations of the FreeCAD wiki, French and Italian. This is accomplished by making freecad-doc a metapackage which depends on any one of freecad-doc-en, -it, or -fr being installed. Then, the relevant files in freecad-doc upon which freecad will call are in fact managed symlinks to the appropriate translations. The symlinks are managed by the DebianAlternatives system (see update-alternatives(1).)

In order to switch between translations if more than one is installed, you can run sudo update-alternatives --config freecad-doc. This will control the in-program help for FreeCAD, so when you click the "What's this?" button, the resultant help page will be the translated version.

Additionally, compiled PDFs of the FreeCAD help are provided for all three languages.

One result of the nature of this package is that it is quite large: each freecad-doc translated package weighs in about 300 MB so the combined size is about 1.2 GB, per Ubuntu distribution.

As a result, this package is only available on Bionic and Xenial.

PyCOLLADA 0.6, now with Python 3!


Another package which is fairly out of date in Debian (version 0.4 present), I decided to update it since pycollada is a dependency of FreeCAD and I am intrigued by the possibilities of the COLLADA (COLLAborative Design Activity) format. This allows for interchange with interactive 3D applications like Blender.

The big news with this package is that Python 3 support is now available, so I updated the source packaging to provide both Python 2 and 3 packages.

Again due to dependencies, it's only available on Cosmic and Bionic.


My work on Debian Science and FreeCAD is supported by my patrons at Thank you all very much!

If you appreciate my work as described in this post, any level of support is greatly appreciated, including moral support!

Social Media

You can follow me on Twitter at @thekurtwk. I'm also currently working on a Twitch streaming setup, which I hope to have ready by the end of the year! I'll be trying out some live programming, engineering, and Linux gaming. You can find me at

Free Software Activities in September 2018

Hello all, unfortunately my update comes late again this month, although I have good reason! I just finished landing a job as a scientific software developer. From the looks of it, I'll mostly be working on things from a systems engineering perspective, but it'll be in the context of the scientific Python ecosystem as well as involving Qt. This is nice in that while I will have less free time to spend on FreeCAD, it will almost certainly be of increasingly higher quality.

Another interesting benefit of the job is that it will allow me to move back to Austin, which has the very well-equipped hackerspace ATX Hackerspace. I look forward to joining and having a chance to finally experiment with FreeCAD's CNC integrations, and to have a great space to hack on hardware and software.

Now, finally, to summarize what I've worked on in the month of September.

  • I created a thread on the FreeCAD forums to announce the revival of the FreeCAD Community Extras PPA. This will be used to host packages of interest to the FreeCAD community, and things that need testing for possible future inclusion in FreeCAD. In retrospect, I should have used this PPA to get testers for the packages I was working on during my last Google Summer of Code.
  • To this FreeCAD Community Extras PPA, I uploaded packages for:
    • OpenCAMLIB, a C++ library with Python bindings for creating 3D toolpaths for CNC machines such as mills and lathes.
    • OpenVoronoi, another C++/Python library for 2D Voronoi diagrams for point and line-segment sites.
    • Laughlin Research's standalone SMESH, the Salome meshing framework.
    • Netgen's latest release, 6.2.1807, a 3D tetrahedral mesh generator.
    • IfcOpenShell, an open source Python IFC library and geometry engine.
    • IfcPlusPlus, an open source C++ class model, reader, and writer for IFC files with simple Qt/OpenSceneGraph viewer application.
  • I have long been interested in having CAD database support, and I spent quite a bit of September working with my friend on research and initial work for this. From what we've found, we can feasibly have a PostgreSQL extension similar to PostGIS, but for CAD: PostCAD. This would mainly involve a marriage between OpenCASCADE, the C++ geometry and topology kernel of FreeCAD, and libpqxx, the official C++ client library for PostgreSQL. The potential for such an extension would be huge, with all the power and features of PostgreSQL with an understanding of CAD data and geometry. For example, FreeCAD could interface with this database, and have the database take care of things like editing locks for models, permissions for readingn and writing of models, and so forth. Furthermore, by creating a database-level abstraction for CAD, that opens the way for web abstractions for CAD, similar to GeoDjango's GIS extensions for Django. That work could one day pave the way for a web interface for FreeCAD.

As always, if you appreciate the work I do with FreeCAD, the Debian Science Team, and Open Engineering on Linux, any level of support would be appreciated on my Patreon! Currently this money helps offset server costs for some of the experimental FreeCAD community stuff. I would like to continue to use it to offset my costs for FreeCAD development and equipment. If I can reach my current goal of $100/month, I'd like to use it to purchase a Pinebook, a $99 ARM64 laptop which I could use for FreeCAD & Debian ARM development. I'd really like FreeCAD to be usable (and not painfully slow) on ARM since its low-cost nature means it is highly available for educational institutions. Maybe one day I'll even be able to afford milling/CNC equipment so I can see just how far FreeCAD integration can take us!

Free Software Activities in August 2018

Hello all! After reading some of the nice activity logs published by members of the Debian Project at, I've decided to publish my own version. This will mostly be my work on FreeCAD and Debian, but will also include other points of note from my many interests. I'll also include relevant activities for my supporters on Patreon

As covered in my previous post, most of the first half of August was spent finishing my Google Summer of Code project for FreeCAD, which largely turned into "packaging for the Debian Science Team" since FreeCAD's dependency chain and options for integration are so vast. However, the nature of the work is highly parallel. For example, when packaging, most issues occur either almost immediately into the build, or after the build has finished. This means that after an initial bit of packaging work that allows a build to actually proceed, one then has to launch the build and wait anywhere from a few minutes to a few hours to see the next issue arise. So, as a result, I worked on many packages in parallel. A negative consequence of this was that I somewhat overloaded my plate in terms of things I can handle, so in actuality this meant I would work on a handful of packages on several machines at once, and then once those issues were largely resolved I would move onto another handful, rather than really juggling them all at once.

After finishing GSoC, I first turned my attention to two of the packages I had worked on in parallel, python-fluids and python-ulmo.


I made a new upload for this package to correct several issues. Here's an excerpt from the changelog:

* [1215102] Make python-fluids-doc Multi-Arch: foreign
* [eb610fd] Correct Vcs-* fields
* [62570cd] Updated to Standards-Version 4.2.0, no change required
* [29e96a7] Correct debian/watch
* [3e90d05] Add missing scipy dependency
* [cd776a2] Add lintian override for

The package still fails some reproducibility tests on i386 and could use a standards version bump, but other than that, this package is almost completely clean now! It's quite satisfying cleaning up these packages.


I made an upload for this package as well:

* [7150daa] Correct Vcs-* fields
* [027b50b] Mark python-ulmo-doc as Multi-Arch: foreign
* [d72b6f6] Add patch to fix FutureWarning

The package was failing its autopkgtests because Python was emitting a FutureWarning onto stderr. This package is actually fully reproducible, and only needs a standards version bump to be fully clean.


On August 22nd, Gmsh 4.0.0 was released! The Java API was removed and a Julia one added. This is a nice release because in Debian bug #904946 it was found that the Gmsh package, after being updated to be built against OCCT instead of OCE, actually no longer worked when used in FreeCAD, giving the error:

Error   : Gmsh requires OpenCASCADE to import shape

My hope was that by updating to the new Gmsh version, this problem would resolve itself. However, I ran into a few problems and had to postpone finishing up.


On August 19th, Debian bug #906619 was reported against Netgen, which was an occasion to look at the state of the package. I noticed that upstream had released version 6.2.1807 (versus the current .1804) but it was not tagged in the Netgen repository, only as a submodule of the Ngsolve repository.

On August 31st, I packaged the new version and resolved the bug in science-team/netgen PR #9.


Although technically not August, on September 3rd I pushed the nearly finished package for a standalone salome-smesh on Salsa which is fully functional except for an issue with the CMake config file. I submitted a pull request to support multi-arch for the package but forgot to update the path in the CMake config file, so the variables therein have to be manually set, or the file edited.


On August 24th, Cantera 2.4.0 was released:

Cantera is an open-source suite of tools for problems involving chemical kinetics, thermodynamics, and transport processes.

Previously there had been an issue with the build, where the packages would be made successfully, but attempting to import cantera in Python would error out, presumably due to the way an included copy of libfmt was handled during the build. However, the issue is no longer present, so I now have a working Cantera 2.4.0 package! The only shortcoming is that I don't have working docs build yet, so this package didn't make it in time for August.


Previously I had submitted a pull request for OpenFOAM 6 to the Debian Science Team, but spontaneously the package began to fail, presumably due to some change in a dependency. I spent some time troubleshooting this issue but haven't found a resolution yet. Here's a snippet of the build failure:

Allwmake src/Pstream
wmake dummy
wmakeLnIncludeAll: running wmakeLnInclude on dependent libraries:
    wmakeLnInclude: linking include files to /build/openfoam-6.20180805+dfsg1/src/OpenFOAM/lnInclude
    wmakeLnInclude: linking include files to /build/openfoam-6.20180805+dfsg1/src/OSspecific/POSIX/lnInclude
make[2]: Entering directory '/build/openfoam-6.20180805+dfsg1/src/Pstream/dummy'
wmakeLnInclude: linking include files to ./lnInclude
make[2]: Leaving directory '/build/openfoam-6.20180805+dfsg1/src/Pstream/dummy'
make[2]: Entering directory '/build/openfoam-6.20180805+dfsg1/src/Pstream/dummy'
Making dependency list for source file UOPwrite.C
realloc(): invalid next size
make[2]: *** Deleting file '/build/openfoam-6.20180805+dfsg1/platforms/linux64GccDPInt32Opt/src/Pstream/dummy/UOPwrite.C.dep'
Making dependency list for source file UIPread.C
realloc(): invalid next size
make[2]: *** Deleting file '/build/openfoam-6.20180805+dfsg1/platforms/linux64GccDPInt32Opt/src/Pstream/dummy/UIPread.C.dep'
Making dependency list for source file UPstream.C
realloc(): invalid next size
make[2]: *** Deleting file '/build/openfoam-6.20180805+dfsg1/platforms/linux64GccDPInt32Opt/src/Pstream/dummy/UPstream.C.dep'

I'll have to continue investigating this one.


I reported Debian bug #906020 about missing Python 3 CMake config files, which was fixed Aug 28th. I began investigating how this would Pivy builds, but got sidetracked by a problem with the med-fichier package.


I ran into some build issues trying to update the package now that my Debian Unstable workstation is running Qt 5.11:

error: invalid use of incomplete type ‘class QAction’
     QAction* action = new QAction(tr("Remove"), this);

There are several instances of this throughout the codebase that can basically be fixed with by adding some #include s.


There was a bit of discussion about utilization of Project Chrono, an open source multi-physics simulation engine, in FreeCAD. One problem with pursuing this is that it isn't packaged at all for Debian, which is rather surprising! It seems like high-quality software. I began looking at packaging it and it actually doesn't seem that bad. One of the main issues is actually the naming: it's really long! There's also a bit of worry about naming collisions I'll have to look into. As of now, I have a working package except for the Python bindings. Enabling them results in this failure in the build process:

[ 53%] Building CXX object src/demos/irrlicht/CMakeFiles/demo_IRR_soilbin.dir/demo_IRR_soilbin.cpp.o
cd /build/project-chrono-3.0.0/obj-x86_64-linux-gnu/src/demos/irrlicht && /usr/lib/ccache/c++  -DBP_USE_FIXEDPOINT_INT_32 -I/build/project-chrono-3.0.0/src -I/build/project-chrono-3.0.0/obj-x86_64-linux-gnu -I/build/project-chrono-3.0.0/src/chrono -I/build/project-chrono-3.0.0/src/chrono/collision/bullet -I/build/project-chrono-3.0.0/src/chrono/collision/gimpact -I/build/project-chrono-3.0.0/src/chrono/collision/convexdecomposition/HACD -I/usr/include/irrlicht  -g -O2 -fdebug-prefix-map=/build/project-chrono-3.0.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -fopenmp  -march=native -msse4.2 -mfpmath=sse  -march=native -mavx2  -march=native -mfma  -std=c++14 -pthread -fopenmp  -march=native -msse4.2 -mfpmath=sse  -march=native -mavx2  -march=native -mfma    -std=c++14 -pthread -fopenmp  -march=native -msse4.2 -mfpmath=sse  -march=native -mavx2  -march=native -mfma  -o CMakeFiles/demo_IRR_soilbin.dir/demo_IRR_soilbin.cpp.o -c /build/project-chrono-3.0.0/src/demos/irrlicht/demo_IRR_soilbin.cpp
/build/project-chrono-3.0.0/obj-x86_64-linux-gnu/swig/ChModuleCorePYTHON_wrap.cxx: In member function 'virtual void chrono::ChLogPython::Output(const char*, size_t)':
/build/project-chrono-3.0.0/obj-x86_64-linux-gnu/swig/ChModuleCorePYTHON_wrap.cxx:7610:23: error: format not a string literal and no format arguments [-Werror=format-security]


There was a problem with this package's doc depends, which I fixed at the end of August. However, it's still awaiting sponsorship to be uploaded into the Debian archives.


The med-fichier package in Debian currently is built with autotools but somewhat supports CMake builds, which would be nice to switch to as it would provide CMake configuration files in libmedc-dev. I worked on updating the package, but currently building docs is broken, and for some reason, the Fortran library is being statically linked.

Planet FreeCAD

The planet-venus package in Debian is available for running your own RSS feed aggregation service. I wanted to set up a to provide exactly that. However, the current version of the package is broken, and it only works in Debian 7, a.k.a. old-old-stable.

I spent some time researching the state of the package, but it's fairly rough, and most importantly, upstream is far from active. I'd like to run the RSS service but fixing the package seems like a tall order.

We previously had two servers available to run some of the web services for the FreeCAD project, but sadly they rebooted but never came back online.

I'm now paying for a VPS in Frankfurt using the money from my Patreon. Unfortunately, it's a bit resource-strained from the FreeIPA server hogging things.

If you like my work as described above and would like to support me continuing to improve the state of open engineering on Linux, please contribute to my Patreon!

Google Summer of Code 2018 with FreeCAD

Hello all! This post is my final work product for GSoC 2018 for the FreeCAD project. The main center for communication for FreeCAD is the forums, but we also coordinated things through the #freecad channel on Freenode. The main thread for my project was here.

To summarize my project: FreeCAD is a complex application with an extensive dependency tree. The packaging situation has always trailed the tip of development, which means users don't get to see the best FreeCAD has to offer, and people trying to help new users have to deal with sometimes years-old bugs. The goal was to improve the general ecosystem of the FreeCAD stack, and to cut down on technical debt to make things easier moving forward. After some consideration it was decided to focus on Debian packaging since that would be the most 'ecologically good'.

I began with a rough knowledge of Debian packaging, but now feel competent enough to want to take over the maintenance of Debian packaging for FreeCAD and several other packages within the Debian Science Team, which will improve the free software engineering experience in Debian as well as its derivatives such as Ubuntu and Linux Mint. In fact, I plan on trying to offically become a Debian Maintainer and then Debian Developer. On the 4th of July during the middle of the project I drove to Houston for a GPG keysigning, so the wheels are already in motion.

This post will summarize my work throughout the summer chronologically, mostly linking to emails in the Debian Science mailing list, pull requests on Debian's Gitlab instance or Github, and to some repositories.

More detailed information can be found at

Coding Period 0, Community Bonding Period (April 23 - May 14)

Coding Period 1 (May 14 - June 15)

  • Most of the first coding period was spent working on FreeCAD 0.17 packaging, as well as packaging Netgen 6.2.1804 and updating Gmsh to use OCCT, which I packaged prior to GSoC. I didn't finish them quite in time for submission within the first coding period. I also spent time working on packaging PySide 2, which is a dependency for FreeCAD's transition to Qt 5 & Python 3, but backed away after finding it was being worked on by others.
  • May 17: Netgen PR (Remove unnecessary backup files):
    • Preparation work for packaging Netgen, which is used as a mesher by FreeCAD.
  • May 25: Discussion of Netgen 6.2.1804 work:
    • This was just me announcing that I was working on this so as to help not duplicate work.

Coding Period 2 (June 15 - July 13)

Coding Period 3 (July 13 - Aug 14)

Now that GSoC is done I am excited to continue working within the Debian Science Team. Besides an upcoming FreeCAD 0.18 release, I have several packages I plan to make improvements to and to package for Debian, and ultimately to integrate into future FreeCAD workbenches as part of my plan to make it the ultimate 3D engineering toolbox!

Therefore, I must say thanks to the FreeCAD and Debian communities for working with me, and to my GSoC mentors and GSoC itself for providing me this wonderful opportunity. May it continue providing valuable opportunities for others for many years to come.

Looking Back on 2017

2017 has been an incredible year for me with lots of opportunities, but many challenges as well. In the spring, I got a (lab) teaching opportunity for a 50-student Measurement & Control of Biological Systems course, culminating in 17 teams making maze-solving autonomous robots. There's a higher level of mastery to be attained by teaching others, and in that regard, it was an incredible experience. Teaching, however, is well outside my comfort zone, and in that regard it had some difficulties.

In the summer, I was able to work on a Google Summer of Code project/pseudo-internship. Working in a mix of Python and C++ was again an interesting challenge since I'm much more familiar with the former than the latter, and even my experience with other languages lies on the Python side of the interpreted/compiled, dynamic/static typing divide. Still, it was an invaluable experience since C++ rules the domain of finite element analysis and computational fluid dynamics, which I want to explore further. Particularly, FreeCAD is the perfect vehicle for engineering computer modeling, so I have high hopes for my future with the project.

At the end of the summer, I passed the exam for the Linux Foundation Certified System Administrator. This was an opportunity provided by a scholarship given in part because of my work using Python to analyze the efficiency of backyard irrigation systems in the Yucatán back in early 2016, so it was great to finally see the culmination of that work. As a little celebration project, I decided to begin running my own Linux mail server, which has been a great success. There were a few hiccups with blacklists on Yahoo and Outlook, but I was ultimately able to get it working with all the major email providers.

I also embarked on a project I've been wanting to do for a long time: running my own Linux router. I found a great series of tutorials on setting up such a router using Ubuntu and the Pine64 board, and have had excellent results since.

I have also been spending time here and there researching a really promising project, FreeIPA. It's a sort of competitor to Active Directory in the identity management space, mostly made up of a combination of an LDAP, Kerberos, and certificate server. I'm running a sort of pseudo-small business in my home network using my FreeIPA server as a centralized authentication, authorization, and identity server, and it's been a great experience so far; I hope to apply it in reality with the FreeCAD project one day. Look out for future posts on the topic.

In the fall, I began my final year at Texas A&M. My capstone project and team was assigned. Our project involves analyzing the flood resiliency of the Houston area and proposing an ecological engineering design to improve that resiliency and mitigate the effects of future extreme flood events such as was seen during Hurricane Harvey. We are using an open-source toolchain involving PostGIS, Python, and QGIS, and the project is really quite exciting since our analysis could be applied to other coastal cities and regions facing extreme weather events in the future.

Altogether, it's been a great year, but I foresee 2018 being even better. If you're reading this, I want to wish you a happy new year with hope for the same!

GSoC Week 12: Final Work Product

Well, it's time to finally wrap up the summer!

It's been a really great and rewarding opportunity, so I first want to thank everyone at Google and beyond who helped put GSoC together, as well as my mentor Stefan Tröger for providing feedback and guidance.

I was able to work with code that ranged almost the entire stack of FreeCAD dependencies: from low-level OpenCASCADE code involving quaternions & transformations, geometry & topology; to the scene graph library Coin3D we have to thank for our pretty screenshots; the connection between C++ and Python code, which I have a feeling will be useful later in my engineering career; and all the way up to the Qt GUI in both C++ as well as its Python interface PySide.

As a result, I feel very prepared to continue working with the FreeCAD project and look forward to doing so. I really think it's a great program and hope to use it for many years in the future.

So again, my thanks!

The main goal of the project was to get test coverage of the Part Design Workbench, and to explore it to find showstopping bugs. The only remaining one involves a crash in ShapeBinder, discussed at

I fixed quite a few bugs and I think the general experience with the workbench is better. Test coverage is there for all the tools, and I'd say the workbench is ready for the public, so now the major work is to release FreeCAD 0.17, the biggest FreeCAD release ever, with its new Part Design (no longer "NEXT") Workbench.

My other goal of improvements to Boolean Operation was made unnecessary by someone else's PR in May.

The last goal, improvements to the Attachment Editor, ended up being a little too big for this GSoC, and could even possibly serve as a good GSoC project for next summer, although whoever does it had better be fairly artistic at making explanatory yet small icons.

In my opinion, I'd say the summer was a success.

Altogether, my code contribution can be summarized with 7 PRs and one experimental branch:



Experimental Attachment Editor/PartDesign Datum Tools branch:

Here's my summary posts, summarized:

  1. /blog/gsoc-week-1-recap/
  2. /blog/gsoc-week-2-recap/
  3. /blog/gsoc-week-3-recap/
  4. /blog/gsoc-week-4-recap/
  5. /blog/gsoc-week-5-recap/
  6. /blog/gsoc-week-6-recap/
  7. /blog/gsoc-week-7-recap/
  8. /blog/gsoc-week-8-recap/
  9. /blog/gsoc-week-9-recap/
  10. /blog/gsoc-week-10-recap/
  11. /blog/gsoc-week-11-recap/

GSoC Week 11 Recap

Unfortunately, it looks like solid, usable improvements to the Attachment Editor are unlikely to be ready for a PR by the end of my GSoC, although I will publish my experimental branch which uses Python for the datum tools and uses the Python-based Attachment Editor I mentioned previously.

However, as a consolation I did finalize some additional tests for PartDesign Hole, so my goal of functional coverage of the PartDesign tools succeeded.

Also, I think with this foray into GUI code, I've hit nearly the full stack of libraries used in FreeCAD this summer. It feels pretty nice, because I feel prepared to tackle whatever problem I want to in the FreeCAD project.

GSoC Week 10 Recap

The final portion of GSoC for me will be dedicated to working on improvements to the Attachment Editor, and this post will essentially be my design for what those improvements will look like. The Attachment Editor is available in the Part Workbench through Python. One can for example create a simple Part Cube, select it, then click Part -> Attachment. It also is used when creating datum geometry in Part Design, or when creating a primitive.

Here are a few screenshots:

command palette

Figure 1. The Python-based Attachment Editor in the Part workbench.

command palette

Figure 2. Creating a Datum Plane.

Creating datum geometry is a key part of the Part Design process, so it's helpful for it to be very easy and intuitive. The current Attachment Mode information especially can be quite overwhelming to a beginner, however. Especially considering how improvements to the Attachment Editor could be reused in a future Assembly Workbench, it was decided to look into improving these tools.

The first, most obvious improvement here would be inactivating the "Extra placement" section when inactive. This could possibly be accomplished by making a separate collapsible section which automatically hides when there is no attachment.

The second, and tougher improvement, involves reworking the current the four attachment selections and the attachment mode. Reference names probably don't need to be more than 3/4ths the width of the page. The methods for selecting references via an activation button, and deleting via clearing out the text are not user-friendly.

The four-reference list here would ideally be replaced with an icon-based grid, which starts out empty. Each selection's icon would be based on its type, e.g. Vertex, Edge, Face, Curve, etc., where available, and a generic icon for unrecognized types. The selection's name could be displayed in a shortened form, e.g. "MyLongShapeNameIs...". This approach could be extended for future Assembly use by adding a scrollbar on the icons, allowing for several rows of attachment references, 4 at a time.

This tool could be very user-friendly, as invalid reference icons can be highlighted red, and when the attachment is complete, the reference set's icons can be highlighted green. Ghosted icons can be displayed as needed for a selected Attachment Mode.

A similar approach for Attachment Mode could be used. Using a 4-icon row with a scrollbar, attachment modes can be explained with a short label and an icon, where feasible; hopefully the large size will allow for expressive icons. When a mode is moused over or selected, the remaining references required can be displayed in the reference selection area.

Altogether, (i) splitting out the placement and toggling when it has no effect (i.e. there is no attachment) and (ii) reworking Reference Selection and Attachment Mode dialogs to use unified icon list GUI code, as well as (iii) making the icon set to explain the attachment concepts to users, comprise the components of this "Attachment Editor Improvement" project.

GSoC Week 9 Recap

I celebrated my birthday in south Texas last week! I was about 3 miles from the future SpaceX launch facility opening in 2018. It'll be great to possibly see launches to Mars from there in the next few years.

I mostly spent this week working on the bugs I mentioned last week. I wanted to try to make a dent in the outstanding bugs I've found. Unfortunately, my lack of C++ background (compared to Python) really hampered this; it's a little bit like trying to run before you walk. In the end, I only fixed the Revolution bug(s). In the case where a revolution is attempted on the same plane as the sketch, resulting in e.g. a flat disc, the issue was that the code was checking the angle between the sketch's normal and the revolution plane's normal, looking for a 0° angle. However, it was failing to fail in the case of a 180° angle.

I also added a simple convenience check for all tools in Part Design: if you open a document with only one body and try to click a PDN tool's button, the single body will be auto-activated instead of popping up a warning. If there are no bodies or more than one, the warning still occurs.

GSoC Week 8 Recap

Total tool coverage lasted less than a week! It's a good thing though, because that means a new tool landed in master: PartDesign Hole.

Part Design Hole tool

This is a really great tool for the Part Design WB not only because holes (and their corresponding fasteners) are ubiquitous in part design generally, but also because the tool does a good job of capturing that information into a FreeCAD object that can be later be hooked into for both the Assembly and TechDraw workbenches. For example, the options I've selected in the following screenshot could be used to complete a technical drawing for this part in FreeCAD, and that information exchange could be done in an automated and customizable way.

Part Design Hole tool

This information could also be used by the Path WB to generate control code for open-source, automated manufacturing processes and machines, so it's really great to have such a full-featured tool added.

I spent some time trying to find bugs in the tool, but didn't really find any. The only gotcha I noticed is related to the orientation of sketches which serve as the basis for holes. There is no Reverse option for the Hole feature itself, so for example, if you have a sketch on the "bottom" of an object but not attached to it, you may need to set the Map Reversed option for the sketch itself to true.

Some tests will be forthcoming for Hole, but besides that, I also spent some time looking at few outstanding bugs in C++-land.


  • (mentioned in week 5) ShapeBinder crash when base object not initially selected due to null pointer dereference
  • (mentioned in week 3) Revolution has unhandled error for some bad revolution axis choices, does bad revolution without error for others
  • (new) Pipe fails when its path is a loop. For example, a Pipe with a circle as a base and a larger, orthogonal circle passing through the base should become a torus. Currently, it fails with the wonderfully verbose error message 'TopoDS::Shell'.