GSOC 2020 has been Green Lit! (GSOC is over, thanks to everyone involved!)

[Kunda1]

Google officially announced that there will be a Google Summer of Code 2020 edition!
Sean from BRL-CAD is already preparing a joined application like previous years, so it seems we're in for a new round!

aaaaaaaaand... lets start the GSOC 2020 thread, shall we?

Reference threads:

• GSOC 2019
• GSOC 2018
• GSOC 2017
• GSOC 2016

Wiki pages:

• GSOC 2020
• GSOC 2019
• GSOC 2018
• GSOC 2017
• GSOC wiki category page

Edit: We're doing GSoC 2020!

Edit2: (source)

Congrats to all of you @kryptokommunist, @Suraj Dadral and @Sudhanshu! We found your three proposals interesting and solid. I'm glad google gave us the green light! For the rest of you,I'll summarize the three projects here:

A better IPython and Jupyter Notebook Integration for FreeCAD
By @kryptokommunist, mentored by @yorik, @kkremitzki and @ickby
Thread: https://forum.freecadweb.org/viewtopic.php?f=8&t=46039

Extended functionality of Rebar Addon
By @Suraj Dadral, mentored by @bernd and @amrit3701
Thread: https://forum.freecadweb.org/viewtopic.php?f=8&t=44580

FEM Examples Extension in FreeCAD
By @Sudhanshu, mentored by @bernd, @HoWill and @kkremitzki
Thread: https://forum.freecadweb.org/viewtopic.php?f=18&t=44705

BTW, the whole BRL-CAD umbrella got 8 approved projects, 3 for FreeCAD, 2 for BRL-CAD, 2 for OpenSCAD, 1 for libreCAD.

To the three of you, please use the specific thread to discuss your project with us. In FreeCAD, we try to use this forum for GSOC projects as much as possible, because it allows the whole community to interact with you, not only the mentors. Try to post as much as possible there, do not refrain yourself from adding a lot of screenshots, etc. I guarantee you that it can be really rewarding, to see everybody follow your progresses and encourage you. You won't regret it Plus, at the end of the project, it furnishes an awesome logbook.

This thread serves mainly as a general announcement channel, we'll be reminding everybody here (students and mentors) of deadlines, things to do, etc. So please keep always an eye here!

Now, up to June 1st, is what google calls the community bonding period, which basically serves to know each others and help you guys get into FreeCAD and the community. This is usually pretty easy Make sure you guys can deal with everything you'll need. I believe only @kryptokommunist will need to compile FreeCAD himself, as his project might involve C++. The two others are full Python projects, right? In any case, I'd ask all of you to make sure you have cloned the FreeCAD source code, have a git account somewhere, and know how to deal with git.

Good luck everybody, don't hesitate to get back to any of us if you meet any problem!

[bejant]

Low hanging fruit?

[ezzieyguywuf]

Here are some random ideas. I'm assuming this is a "safe place" where I can throw out different ideas and see what (if anything) sticks...

- Unify coding style/create coding guide/improve class hierarchy. For example: why does App::ComplexGeoData exist? From what I can tell (and don't quote me on this, I'm going off memory as I'm travelling right now), it seems like only Part::Shape inherits it, and it only adds a few methods to the interface described by App::GeoData. Wouldn't it be better to simply add these methods to App::GeoData, and then in the future (if needed) create a separate App:ComplexGeoData class as necessary? it seems to me (and this is conjecture) that due to the length of time Over which FreeCAD has been developed, that it started out with some sort of singular "grand Master plan" (hence the depth of certain class hierarchies such as App::ComplexGeoData) but that over time this vision has either been diluted or altogether shifted. Therefore, the intent of this GSoC project would be to understand the original design intent of the existing codebase, update that design as appropriate using modern c++ and modern programming techniques, and finally provide a design guide for future deceloppers to reference so that they can "stay within the lines" (as it were)

- Create abstractions for all external dependencies (maybe this is dumb) : the idea is that new deceloppers should not have to worry so much about "how does con work", "what is opencascade", etc... instead they cna instead focus on "what do I want to do to improve freecad" and then utilize (say) FreeCAD::Render::Points, FreeCAD::Kernel::BoolAdd, etc... to accomplish their goals. (again, this might be dumb, especially for a mature and well known api such as qt)

- Update /create/improve documentation in order to provide a de facto reference for current and future developers. For example - the qt references and the Android references are fantastic benchmarks. The entire public API is documented, with tutorials embedded in the documentation as necessary, such that a motivated devleopper can get everything they need to be productive straight from "the source"

- flatten the oop inheritance tree - as described in this blog (in all honesty I skimmed :again, I'm travelling), I think that parts of the legacy FreeCAD code base fell into this trap off "oop for oop's sake". Please don't take this as criticism, nearly constructive critique, as I am a big fan of the work (which is why I devote so much of my time to this project.) That being said, it seems that if we were to "clean up" some of this oop hierarchy it would make understanding the code base a bit easier, and would also hopefully draw in more developers. This may be related to by first suggestion.

- Make FreeCAD truly modular. This is already mostly there with the Mod subdirectory, not to mention the plug in system. What I'm suggesting is to strip down the base FreeCAD into just the Start workbench, and maybe Part. Everything else will be a plugin, that is developed and maintained as a separate project (or group or projects). Why do this? Because it breaks up the development efforts into logical units. Just take a look at the sub forums that already exist for the different avenues of FreeCAD development. This full, true, modularization would simplify the maintenance and improvement of the base system, while providing more flexibility for the developers and maintainers of the various niche features that FreeCAD provides. (again maybe this is dumb...)

We'll, that's all the ideas I can bear to submit with my thumbs on my phone. Again, I hope not out of place throwing these random ideas out. Hopefully it can generate some healthy discussion.

[chrisb]

There are interesting topics in Path workbench, which have the advantage of being closed enogh to be handled as a GSOC project.
- Integration of different tool shapes beyond (flat) endmills
- Integration of material in the calculation of speed and feed.
- Extension of 3D-Pocket to work without an artificial "support"
- Tags definitions for a whole Job, not only for an operation.

[Kunda1]

Sort of off topic,
I wonder if we could get the OCC folks to participate?
Maybe we can persuade them to submit a proposal regarding multithreading, that would be a game changer

[ezzieyguywuf]

Here's another idea: update code base to utilize pybind11 across the board, ultimately eliminating the USE_PYBIND11 cmake option. This would provide a more consistent approach to our python integration, which would allow us to write a comprehensive code standard/guide (at least for this aspect of the code base)

[sgrogan]

Here's another idea: update code base to utilize pybind11 across the board, ultimately eliminating the USE_PYBIND11 cmake option. This would provide a more consistent approach to our python integration, which would allow us to write a comprehensive code standard/guide (at least for this aspect of the code base)

FreeCAD is ready. It's a header only library so I'm a fan. Dependencies that still use boost-python (ocl for example) need to be considered. Maybe FLATMESH can also be a default (I think the eigen3 version is the issue)?

[ezzieyguywuf]

FreeCAD is ready. It's a header only library so I'm a fan. Dependencies that still use boost-python (ocl for example) need to be considered. Maybe FLATMESH can also be a default (I think the eigen3 version is the issue)?

I am also a fan. If it does not get picked up for GSOC I'd be interested in pursuing this as a project, however I've mostly got my hands full at the moment

[chrisb]

Another idea: Include all or parts of part-o-magic and lattice into FreeCAD master. See https://forum.freecadweb.org/viewtopic. ... 60#p336560.

[looo]

- adding a gear-calculator to the gear-workbench which allows to create gear assemblies from different inputs
- adding new geartypes to the gear workbench
- cleaning, maintaining, adding CAD related conda-forge recipes (pyocct, libredwg, ...)