[*][url=https://www.freecadweb.org/wiki/Category:Google_Summer_of_Code]GSOC wiki category page[/url]
[/list]
Edit: We’re doing GSoC 2020!
Edit2: (source) [quote=yorik post_id=395329 time=1588672600 user_id=68]
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:
[size=150]A better IPython and Jupyter Notebook Integration for FreeCAD[/size]
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!
[/quote]
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.
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
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)?
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
A proper measurement tool that is available from all tools and a few more options than current (Part) one (diameter distence between 2 holes etc)
Maybe a few features / feature additions for PartDesign
Talking of PartDesign there are still some things open:
Improve pattern functions in size and speed to be on par with their Array counterparts
Unify the selection mechanism where multiple features have to be selected, e.g. with Path workbench. The feature selection mechanism for the pattern features is one of the most cumbersome I’ve ever seen. (See sliptonic’s video about things repelling users from FreeCAD).
Add boolean Common (alone it is probably too easy for a whole project)
Investigation if the single solid rule can be loosened
A feature that would allow to take a object (in a body), give it a plane or some lines/curves and directions, that would slice the object and automatically put each resulting part in new bodies
code Arch example casa artigas in Python. Make a unit test from it. We would keep this cool example than forever and it would be cool to see an complex arch example coded. ATM it is years outdated. This could be done by a newbe too.
There have been a number of attempts at Assembly. I don’t know much about them, but would a GSOC on Assembly be a good idea?
The reason I ask it that lack of Assembly is often quoted by FreeCAD Naysayers.
Would it be too much work for a GSOC?
Implementation still has too much to be determined?
Availability of mentors?
Maybe we should also think about better integration with other open source projects? (coincidentally ones that are also GSOC participants)
Create a better workflow between the available applications out there that will make open source ecosystem more unified and an attractive alternative.
3304: “Integrate Inkscape in to FreeCAD” (and GIMP)
3305: QGIS integration in to FreeCAD
Plus, at the end of the project, it furnishes an awesome logbook.
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.