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.
FreeCAD
