The unfinished state of the Part Design Workbench (WB) is one of the major impediments to the release of FreeCAD’s current development version, 0.17. Fundamental changes were made to the way the workbench behaves as part of a long-term project called PartDesign NEXT, and much more powerful tools are now available for use. However, many of those tools have not been fully implemented into the user interface, and for some the workflow involving their use is buggy or confusing. Although some core functionality work is left, a great deal of the remaining work just needs time spent polishing. Thus, the refinement of the Part Design WB makes for a sensibly-sized project for one student developer over a summer.
The purpose of the Part Design WB is to assist users in creating robust, parametric parts. These parts should also be ready for use and analysis in downstream workbenches like the FEM WB, the Assembly WB, or even a future Kinematics/Dynamics WB.
A few of the goals I’ve outlined are:
1. The most important word in the “definition” of the Part Design WB is assist. Confusing and buggy workflows must be eliminated, if time allows, or thoroughly documented on the project’s issue tracker, otherwise. Leveraging the community is key here. I may not be able to make all the bugs I encounter go away, but I can make them easier to fix. This is especially important considering the FreeCAD project’s dependence on upstream code. In particular, the OpenCASCADE geometry kernel is central to many of the Part Design WB’s tools.
2. One of the key ingredients to a useful Part Design WB involves keeping track of “where” the user is at in the modeling process. For example, if a valid & constrained sketch has just been created, it is ready to become the basis of a feature like a pad, pocket, groove, etc., and the user interface should present appropriate options to the user. Things like appearance and visibility of objects in the 3D view and tree view also need to be managed by this system. A great deal of work has been done in this regard by the project developer DeepSOIC in his Part-o-Magic module and so I should work with him if possible to test and integrate this functionality into FreeCAD’s core & the Part Design WB.
3. The Part Design WB itself must also be robust for a good user experience, and the way to ensure correct behavior of code in a distributed development environment involves unit testing. Currently, there are three unit tests in the Part Design WB, so there is a huge amount of improvement to be done. I hesitate to put quantity over quality here, but I would expect there to be at least ten times as many unit tests by the time I’m done—at a minimum there should be more than ten tests.
The HEAD of the FreeCAD’s master branch is a fast moving target at around 15 pull requests per week on average, and thus writing a weekly timeline in advance does not seem prudent. A rough outline of my time management strategy over the course of the summer is as follows:
Community Bonding Period (May 4 – May 29)
This time will be chiefly spent studying the existing Part Design code, and I will likely also be studying DeepSOIC’s Part-o-Magic code. I will be spending a great deal of time on the bug tracker, monitoring incoming Part Design bugs, and testing out the workbench’s functionality. I will record deficiencies and create feature issues to organize the work on addressing the workbench’s shortcomings.
Work Period I (May 30 – June 30)
“If it’s your job to eat a frog, it’s best to do it first thing in the morning. And if it’s your job to eat two frogs, it’s best to eat the biggest one first.” - Mark Twain
It’s impossible to know today what the biggest “frog” will on May 30th. The two biggest that I know of know involve the “Boolean Operation” command being unintuitive enough to merit a forum thread, and the workflow management mentioned in goal #2. Workflow management certainly seems a larger topic at the moment, but it is actively being worked on by DeepSOIC and thus, by May 30th, it may end up being several moderately-sized “frogs”, instead.
Work Period II (July 1 – July 28)
This work period will likely involve a combination of general workflow improvements and the addition of unit tests to ensure that my newly added features don’t break upon subsequent development.
Work Period III (July 29 – August 29)
Major feature work should be concluded around halfway through this work period, and smaller, nice-to-have features can be worked on in the latter days of the project. Adding further unit tests would also be worthwhile. Depending on how Work Period I & II go, it may be better to spend some time improving documentation and engaging with the community to try to elicit and document bugs for future work.