GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
Kunda1
Posts: 5945
Joined: Thu Jan 05, 2017 9:03 pm

GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby Kunda1 » Mon Sep 16, 2019 12:51 pm

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

Reference threads: Wiki pages:
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
User avatar
bejant
Posts: 5953
Joined: Thu Jul 11, 2013 3:06 pm

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby bejant » Mon Sep 16, 2019 4:17 pm

Low hanging fruit?
ezzieyguywuf
Posts: 636
Joined: Tue May 19, 2015 1:11 am

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby ezzieyguywuf » Mon Sep 16, 2019 5:24 pm

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
Posts: 19703
Joined: Tue Mar 17, 2015 9:14 am

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby chrisb » Tue Sep 17, 2019 3:30 am

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.
User avatar
Kunda1
Posts: 5945
Joined: Thu Jan 05, 2017 9:03 pm

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby Kunda1 » Tue Sep 17, 2019 10:16 am

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
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features
ezzieyguywuf
Posts: 636
Joined: Tue May 19, 2015 1:11 am

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby ezzieyguywuf » Mon Sep 23, 2019 10:25 pm

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)
User avatar
sgrogan
Posts: 5475
Joined: Wed Oct 22, 2014 5:02 pm

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby sgrogan » Mon Sep 23, 2019 10:42 pm

ezzieyguywuf wrote:
Mon Sep 23, 2019 10:25 pm
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
Posts: 636
Joined: Tue May 19, 2015 1:11 am

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby ezzieyguywuf » Tue Sep 24, 2019 12:03 am

sgrogan wrote:
Mon Sep 23, 2019 10:42 pm
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
Posts: 19703
Joined: Tue Mar 17, 2015 9:14 am

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby chrisb » Wed Sep 25, 2019 8:01 am

Another idea: Include all or parts of part-o-magic and lattice into FreeCAD master. See https://forum.freecadweb.org/viewtopic. ... 60#p336560.
looo
Posts: 2965
Joined: Mon Nov 11, 2013 5:29 pm

Re: GSOC 2020 (Voice your opinion and ideas about what to propose for the next gsoc)

Postby looo » Wed Sep 25, 2019 2:08 pm

- 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, ...)
please help with my conda-packaging efforts: https://liberapay.com/looooo/