freecad / fpa-grant-proposals Goto Github PK

Proposal description

Continue to address bugs and missing code as discovered in TNP migration. Develop new code as required to address portions of subshapebinder and sketcher that vary from both the code base at the time of the original TNP branch and from the current Linkstage3 branch. When no bugs are present, refactor code in Part and PartDesign based on discoveries during the toponaming project.

Deliverables

Expand TNP mitigation to cover discovered cases.
Address bugs generated by TNP changes

Timeline

I can start immediately. I will spend 20-40 hours per week on this project.

Risks and mitigation

This is a series of small PRs against existing code, and in the event I cannot complete some, the bugs will still be pending for other developers to address. None of this work should create new major issues; hopefully it will close a lot of bugs before the 1.0 release.

Compensation

I would like $5000 based on an hourly rate of $50. Payment after the 100 hours of work are complete would be preferred; I will report on PR's completed / bugs fixed and time taken.

About you

Bradley McLean ( bgbsww as an online handle )

I've been working intensively on the Toponaming project for the last six months; I have many accepted PRs, related to both Toponaming and other FreeCAD bugs.

Proposal description

The essence of the proposal is to 1) improve the quality for the C++ API Documentation and 2) to make the C++ API Documentation complete. My proposal is to focus on namespace App since I am already fairly familiar with it and it is arguably the most important part of FreeCAD. This project can run in conjunction with the GSoC project that focuses on improving the API documentation in general.

The proposed changes are standardizing doxy comments with @brief, a detailed explanation, and @param and @return for every public and protected function.

This will benefit the FreeCAD project because:

• good documentation may attract more developers to improve FreeCAD,
• it can help maintainers to judge PRs better, and
• it sets a standard for PRs, allowing FreeCAD's documentation to improve over time.

Deliverables

• Defining a standard for documentation: documented on the wiki and other relevant places.
• Apply the standard to namespace App on the existing documentation: PRs for well-defined sets of files.
• Add missing documentation in namespace App: PRs for well-defined sets of files

Timeline

• Define a documentation standard in collaboration with the community / GSoC project: Start in May, finish end of May
• Apply the standard to files in namespace App: Start in June, finish end December

Risks and mitigation

I would like to carry out this work as an independent contractor.

The risk entails the estimation of work since only namespace App contains about 50k lines of code. Since some parts are already well documented while others are not documented at all, it is difficult to estimate the amount of work.

Compensation

I would like to carry out this work with for a total of 8000 EUR.

About you

My name is Pieter Hijma (pieterhijma on the forum and pieterhijma on GitHub). I'm an independent contractor (https://pieterhijma.net) and as a co-founder of the Open Toolchain Foundation, I would love to contribute to improve FreeCAD as it is an important part of open toolchains.

This project finds it motivation from my work on variable sets as improved API documentation would have helped my work. In general, I have a strong interest in documentation, often using literate programming as a way to document code, and I have also worked on automating assembly instructions for Open Source Hardware. With a Computer Science PhD, I am in a good position to document this important part of FreeCAD. I've already made a small (but high quality) contribution to FreeCAD's documentation in this PR.

Proposal description

Complete the toponaming code transfer project by moving remaining c++ code supporting the python layer, identifying and moving any code missed during earlier phases, and supporting the debugging process.

Deliverables

1. Transfer python interface.
   • All of the code in the toponaming branch in src/Mod/Part/App/*Py.cpp files will be moved into main, in manageable pull requests, with tests as appropriate.
2. Enable toponaming fixes in main branch
   • Develop a high level, user visible way to enable and disable the toponaming change and work with the committers on when and how to enable it.
3. Characterize performance
   • Develop consensus on a test suite of documents, and publish performance results as guidance for future optimization work.
4. Test compatibility
   • Develop consensus on a test suite of documents, and verify that they operate correctly.
5. Provide bug fixes / clean cruft
   • Work with the FreeCAD community to address bug reports related to the toponaming changes. If/when there are no active bug reports, work to eliminate or prepare for elimination code that has been obsoleted, and/or propose non-substantive changes that improve code readability.

Timeline

Note: a minimum amount of planning is required due to the nature of this project; it is pretty much done.

1. Code transfer, test writing, and pull requests
   • 80 hours
2. Enabling toponaming
   • 8 hours
3. Performance testing
   • 20 hours
4. Compatibility testing
   • 20 hours
5. Bugfixing
   • Impossible to quantify, but limited to 40 hours.

Risks and mitigation

The large risk here is that a complete set of code is not migrated and working correctly. Mitigating this risk is the existence of a working LinkStage3 version of FreeCAD, so as long as the work is done in an incremental fashion, it can be picked up by someone else at any point. Suggestions and related work can also be incorporated along the way.

Compensation

I would like $5000 US, in 4 installments. One for code transfer completion, one after performance testing, one after compatibility testing, and final when the code is enabled in mainstream FreeCAD builds.

About you

Bradley McLean ( bgbsww as an online handle )

I've been working intensively on the Toponaming project for the last three months; I have many accepted PRs, related to both Toponaming and other FreeCAD bugs, so my interaction with the project should be quite visible.

Proposal description

This project is about making Sketcher more manageable to maintain and extend. Owing to the vast types of curves, and cases within cases that are generated, almost every method and command extends to multiple hundred lines, with some files going beyond 10,000 lines. Even with attempts to handle these cases, problems still arise, as can be seen in the list of Sketcher issues on the repository. Given how much this WB is used, any corner case left behind is eventually bound to surface, and with every added feature and curve type, the number of these corner cases is only going to increase.

Thus, I propose to take a step back before adding any further changes, and refactor the codebase for better readability and maintainability.

Deliverables

• Simplifying methods: Most of the methods in Sketcher are gigantic with multiple cases for various supported geometries. Often, these cases are repetitions or slight modifications of previous cases. These can be moved to separate helper methods for reuse, or at least divided into pieces for each case, making an easier reading.
  • The largest files include src/Mod/Sketcher/App/Sketch.cpp, src/Mod/Sketcher/App/SketchObject.cpp, src/Mod/Sketcher/App/planegcs/GCS.cpp, and src/Mod/Sketcher/Gui/CommandConstraints.cpp, and as a heuristic, these would be first targeted.
  • Cognitive complexity of these (and possibly other) files may be used as a metric. In CommandConstraints.cpp alone, there are 18 cases where the currently accepted threshold of 25 is breached, with one method activated goes as far as 138.
• Testing: Sketcher currently lacks in terms of testing. This makes it susceptible to regressions, especially with the amount of changes being added to it. Before any major refactoring, sufficient tests will be added.
• Documentation: This would include both
  • a complete documentation of methods, especially if they are user facing, and/or have corner cases that need to be clearly stated.
  • a set of "best practices" to follow while performing such refactoring elsewhere.

Timeline

Work can start as soon as funding is approved, and can be divided as follows:

• Month 1: Learn more about refactoring and plan next actions.
• Month 2-4: Add tests, change code, repeat.

I would be dedicating about 10 hours per week for this project on an average.

Risks and mitigation

Given the nature of the task, I cannot for sure say how much work is involved here. It may just involve dividing the files and methods into manageable chunks, or may go as far as rewriting them in their entirety. That is why I am proposing this as a time-commitment grant.

A risk on the personal front is that I may join a full-time job in the middle of this effort, if the right opportunity presents itself. In that case, I would like to continue this project in my free time as much as possible (with compensation negotiated accordingly), or at least wrap it up beforehand if I am restricted from doing so.

Compensation

I would like a compensation of at least 5,000 USD, paid in installments of 1,250 USD per month, or the remainder of the amount if the project is completed soon enough.

About you

My name is Ajinkya Dahale. I go by jnxd on the FreeCAD forum and AjinkyaDahale on Github. I am an independent software developer based in India, and a contributor to FreeCAD since 2016.

Experience relevant to the proposed grant: Most of my contributions to FreeCAD have been in Sketcher, particularly in adding B-spline support. This has provided me the opportunity to delve into various parts of Sketcher, including the planegcs solver, and both the command line and GUI interfaces.

I have always aimed to keep my changes readable and compact enough (or have been pushed to do so by the maintainers). This is demonstrated best in this PR to support splitting more curves, where I had to generalize a lot of the code to support double the number of types of curves without doubling the size of the split method. That being said, solely refactoring will be fairly new to me, and I would be "learning on the job".

Proposal description

1. To enhance the FreeCAD API documentation, several key improvements are proposed. Firstly, organizing the documentation involves creating a hierarchical structure for modules, facilitating easier navigation and comprehension. This includes segregating Python and C++ functionalities and providing comprehensive overview pages for each module, outlining all classes, functions, and significant features.

2. Secondly, enhancing docstrings is crucial. Ensuring uniformity and thoroughness across docstrings is essential. Focusing on providing vital details such as parameters, return types, exceptions, and practical usage examples will significantly improve readability and understanding.

3. Thirdly, updating the Doxygen configuration can enhance the documentation's visual appeal and usability. Enabling features like UML diagrams offers a graphical representation of relationships, while customizing the output using layout files and CSS improves overall readability and aesthetics.

4. Fourthly, automating documentation generation streamlines the process and ensures the latest documentation is readily available.

5. Lastly, regular maintenance and feedback mechanisms are crucial. Conducting periodic audits ensures documentation accuracy and completeness, while implementing a feedback mechanism allows users to provide valuable input for continual improvement. Regular updates reflecting codebase changes ensure that documentation remains current and relevant, fostering a robust and user-friendly resource for the FreeCAD community.

Deliverables

1. Initial Assessment Deliverables:

• Review report on current documentation structure.
• Summary of key pain points based on user and contributor feedback.
• Comparative analysis of documentation structures from successful projects.

2. Structuring Documentation Deliverables:

• Documented hierarchical module organization plan.
• Visual differentiation strategy for Python and C++ functionalities.
• Module overview pages outlining classes, functions, and key features.

3. Improving Readability Deliverables:

• Style guide document for consistent docstring formatting.
• Examples of well-documented classes and functions.
• Implementation plan for enforcing style guide through code reviews and automation.

4. Content Enhancement Deliverables:

• Detailed descriptions for each module, class, and function.
• Cross-referenced documentation utilizing Doxygen capabilities.
• Technical Improvements Deliverables:

5. Updated Doxygen configuration file (Doxyfile).

• Customization plan for improving readability with CSS and custom tags.

6. Feedback mechanism integrated into documentation site.

• Contributor guide document with instructions for effective documentation.

Timeline

This projects should take around 20-22 weeks starting from June to October.

Week 1-2:

Resolve all Missing and empty API documentation issues.
Analyze existing Doxygen docstrings and code structure.
Evaluate Doxygen configuration settings for potential optimizations.

Week 3-4:

Develop templates for standardized Doxygen docstrings.

Week 5-6:

Analyze codebase to identify areas for better documentation organization.
Implement structural modifications ensuring backward compatibility.

Week 7-8:

Evaluate existing tools/scripts for documentation enhancement.
Develop and integrate custom tools/scripts into the workflow.

Week 9-10:

Customize new scripts as needed.

Week 11-12:

Customize Doxyfile configuration for optimized FreeCAD documentation output.
Define custom snippets/macros for improved readability.

Week 13-14:

Test effectiveness of Doxygen configuration changes.

Week 15-16:

Plan unit testing for updated docstrings and code modifications.

Week 17-18:

Conduct unit testing for accuracy of updates.
Perform integration testing for seamless documentation/code integration.

Week 19-20:

Gather feedback from beta testers/user groups on documentation usability.

Week 20-21:

Conduct final testing to address outstanding issues.
Review and finalize documentation for more enhancements

Risks and mitigation

There are no foreseeable risks for this project. However, it's worth noting that until the end of July, I'll also be engaged in a GSOC project. Nevertheless, this won't pose any hindrance, as my summer break extends until August.

Compensation

I Would Like Compensation of 4000 USD , i.e around 800 USD Per Month as it will take around 5 Months to get this completed.

About you

Name: Anurag Singh
Email: [email protected]
GitHub Profile: Ovalelephant35

I have contributed to FreeCAD and have meticulously planned for the same while applying for GSOC. For further reference regarding all my PRs and contributions, please refer to this link. Additionally, you can find detailed plans and implementation strategies in the attached document FreeCAD_Oval (1).docx.

The plan aims to ensure that every function has a @brief summary, providing a concise description of its purpose. It includes detailed explanations for each function to offer context and usage guidelines. Moreover, the plan involves utilizing @param and @return tags comprehensively to describe function parameters and return values, among other enhancements. Below is an example of the proposed improved documentation structure:

Module Overview (Example)
Module: Part
Description: This module provides functionalities to create and manipulate geometric shapes.
Classes:

Part::Feature: Represents a feature in the part.
Part::Shape: Represents a geometric shape.
Functions:
createShape(parameters): Creates a new shape with the given parameters.
exportShape(fileName): Exports the shape to the specified file.
Thank you for your attention and consideration!

Proposal description

CAD/BIM programs generally have a good library of components ready for application in the development of architectural and engineering projects.

FreeCAD already has a library, but it is necessary to increase the supply of components, both in their number and in their further development, mainly in a greater degree of parameterization.

The availability of this resource is always a significant requirement when choosing the application to use in project development, both by professionals and companies. This may increase interest in using FreeCAD.

Since the FreeCAD component library is public, everyone using this platform would benefit from access to these resources.

Deliverables

The idea is to develop and supply a few dozen pieces of furniture and parametric components (for architectural and engineering projects) for immediate use in FreeCAD.

This will enable better development and detailing of projects in these areas, aiming to improve compliance with BIM criteria.

Timeline

I can start as soon as my grant proposal is accepted.

I can spend 4 hours days a week for the next 5 months working on this project.

Risks and mitigation

As a mitigating measure, I present the possibility of compensating for any missing hours.

Compensation

This work would have a value of U$5,000 (R$25,000.00).
The value of the hour worked would be around U$45.00 (R$225.00), paid in five monthly installments of U$1,000.00.

About you

Name:
Francisco de Assis Rosa

Forum / Community username(s):
F_Rosa

Experience relevant to the proposed grant:
I have already collaborated with the creation of a component library: https://github.com/Francisco-Rosa/FreeCAD-library.

Have you already contributed to FreeCAD? Please elaborate:
In addition to the library mentioned, I developed and maintains Movie Workbench: https://github.com/Francisco-Rosa/FreeCAD-Movie; and several posts on the FC Forum, highlighting:
Topography with point cloud:
https://forum.freecad.org/viewtopic.php?f=8&t=58925
Urbanization:
https://forum.freecad.org/viewtopic.php?t=59084
Rendering:
https://forum.freecad.org/viewtopic.php?t=82656
BIM:
https://forum.freecad.org/viewtopic.php?t=60050
And
https://forum.freecad.org/viewtopic.php?t=59192
Animations:
https://forum.freecad.org/viewtopic.php?t=74432
2D Drawing:
https://forum.freecad.org/viewtopic.php?p=581760#p581760
Creation of doors and windows:
https://forum.freecad.org/viewtopic.php?f=24&t=18475&p=144393#p144393
Foundations, AC installations, compatibility and libraries:
https://forum.freecad.org/viewtopic.php?t=19025
Parametric glass skin:
https://forum.freecad.org/viewtopic.php?p=140609#p140609

Have you ever worked on similar software before? Please elaborate:
In addition to the FreeCAD, that I currently use, I have worked with several commercial and open source programs, such as:
• BIM (ArchiCAD and Revit);
• 3D CAD (ArchiCAD, Artlantis, Blender, Form Z and Microstation);
• 2D CAD (AutoCAD, DaftSight and LibreCAD).

Have you ever solved similar tasks before? Please elaborate:
As already mentioned, I created several components for FreeCAD: https://github.com/Francisco-Rosa/FreeCAD-library.

Proposal description

The essence of the proposal is generalizing exposing properties as some have suggested (for example here and here). By changing FreeCAD's execution model slightly, it may be possible to remove the reliance on temporary hidden files as is the case for SubShapeBinders, something that makes FreeCAD models brittle (in my humble opinion). It will provide a Part::Variant document object that does not rely on hidden temporary files, making use of FreeCAD's tweaked execution model.

The proposed changes are adding an "Exposed" flag to properties similar to "Copy on Change", separating computing a shape from setting a shape in the execute phase of FreeCAD's execution model, and introducing a Part::Variant that makes use of this functionality.

This will provide FreeCAD users with something that I call an Application Geometry Interface (see #12120) something that is to the best of my knowledge not possible in other CAD programs (other than coded CAD solutions). Instead of relying on temporary hidden files, this proposed solution would be fully supported by the FreeCAD core (not only aligning with objective Streamlined Workflow, but also with objective Prevent shooting yourself in the foot). This conversation explains the shortcomings of Spreadsheet configuration tables well and in my humble opinion the same is true for variants based on SubShapeBinders.

Deliverables

• PR Generalize execution model: In this PR we investigate changing the execution model to separate setting a shape and computing a shape. I have already started a discussion for this (#12868).
• PR Expose properties: In this PR we investigate to what extent we can "call" computing shapes with properties that are exposed.
• PR Part::Variant: In this PR we investigate to what extent we can create variants in a similar way to SubShapeBinders without the requirement to have temporary documents.
• PR Tests or discussion: Extensive tests for the implemented behavior or a report in the PR or issue discussing problems.

These are low level changes that make temporary hidden documents and copying of object structure obsolete, providing a more fundamental solution to variants and configurations. For users, it means that they can expose properties to achieve a similarly intuitive interface to document objects in general as the Part primitives such as Cube and Cylinder provide (having a property such as radius that changes the shape).

Timeline

• Generalize execution model: Start in May, finish end of May
• Expose properties: Start in June, finish end of June
• Part::Variant: Start in July, finish end of August
• Tests or discussion: Start in September, finish end of September

Risks and mitigation

I would like to carry out this work as an independent contractor.

The above sketched project has inherent risk because of a change to the execution model, albeit a small change. However, this change will be threaded throughout FreeCAD, so potentially many document objects are touched. I will put effort into making the changes as backward compatible as possible. However, because the potential of this functionality is so high, I think it is at least worth of investigating the proposed changes. Since this is quite a fundamental change, it is difficult to promise that the PRs will be ready to be merged after each stage, but without a doubt, it will provide us with a better understanding of the problems at hand to support the above functionality. Because of this inherent risk, the last stage is called Tests or discussion that allows us to get a better understanding in case unforeseen issues arise that prevent generalizing exposed properties.

Two challenges stand out at this moment:

• dependency management, and (slightly related)
• cyclic dependencies

It is at this time not clear how to properly manage dependencies. That is, if an exposed property is changed, it should trigger a recompute of the object. This is most likely doable, but at this stage it is unclear to me how to trigger the right recompute and how to prevent large expensive recomputes.

Exposing properties will depend on properties of parent document objects. Currently, this is not allowed in FreeCAD because of cyclic dependencies, so it is necessary to find a solution for the proposed behavior, possible by making informed decisions on where to allow a cyclic dependency.

Compensation

I would like to carry out this work with for a total of 8000 EUR.

About you

My name is Pieter Hijma (pieterhijma on the forum and pieterhijma on GitHub). I'm an independent contractor (https://pieterhijma.net) and as a co-founder of the Open Toolchain Foundation, I would love to contribute to improve FreeCAD as it is an important part of open toolchains. This functionality is inspired by my personal issues regarding modularity as a FreeCAD user. For example, my post on my Fab Academy program already mentions using different categories for parameters.

I have been working on Variable Sets as an independent contractor for Ondsel. This work can be regarded as an extension of that work, but with a more fundamental solution that was out of the scope of the Ondsel contract. In that sense, I have experience contributing to FreeCAD and experience relevant to this proposed work.

I haven't worked on similar software before but I have solved similar tasks that are more architectural of nature before. An example is the Cashmere project ([1], [2]) that needed a clean interface between two existing systems.

Proposal description

The essence of the proposal is to research how to achieve true variant parts in FreeCAD in order to achieve improved support for parameterization. This research will target both FreeCAD users and FreeCAD developers as audience and it will be focused on 1) explaining users the current problems of variant parts in FreeCAD and the potential of the functionality that this research proposes as a solution, 2) and keeping a potential solution manageable in terms of complexity if the FreeCAD core needs to be changed.

This proposal builds on the current work on VarSets and the problems that emerged with an early implementation in #12532, an earlier iteration of this proposal in #3, and the discussion with @yorikvanhavre and @shaise (see summaries of the discussions in both links).

This project will attempt to improve on copy-on-change links and configuration tables in order to address the various issues that this functionality has for parameterization, such as reliance on temporary hidden files as is the case for SubShapeBinders, and hidden references, functionality that poses a risk to make FreeCAD models brittle. This conversation explains the shortcomings of Spreadsheet configuration tables well and in my humble opinion the same is true for variants based on SubShapeBinders.

The ultimate goal is to provide FreeCAD users with what I call an Application Geometry Interface (see #12120) something that is to the best of my knowledge not possible in other CAD programs (other than coded CAD solutions). Adding this functionality would align with objective Streamlined Workflow, but also with objective Prevent shooting yourself in the foot).

Deliverables

The research will be presented in three different ways:

• forum posts for users,
• forum posts for developers, and
• PRs that are targeted at developers.

The research is conducted by developing code and this code is presented in various PRs possibly with alternative implementations. The forum discussions for developers and users allows the community to make decisions in preferred implementation direction, or – for example – to understand the trade-off in added functionality in relation to the added complexity in the FreeCAD core.

• Forum posts for users:
  • Explain current options for variants and their problems, making use of videos.
  • Explain the potential of variant parts by means of videos.
• Forum posts for developers: Provide context on the issues and PRs, and provide the community with options in implementation direction.

Expected PRs on three different topics, there may be PRs that have the same functionality but different implementations:

• PRs for referring to child properties: In this set of PRs we investigate how a parent document object can refer to properties of child document objects while attempting to maintain the DAG for recomputation and preventing dependency cycles.
• PRs for omputing shapes for variants: In these PRs we investigate how to compute shapes for variants from a base part without relying on hidden copies of a base part or hidden temporary files. This forms the basis for the next set of PRs.
• PRs for variant parts: With these PRs we investigate to what extent we can create variants in a similar way to SubShapeBinders without the requirement to have temporary documents given the solution from the previous PR.

Since this is a complicated topic with potentially low level changes to FreeCAD's core, the forum posts will serve as a way for the community to discuss

1. what functionality the community would like,
2. the tradeoff between changes in FreeCAD's core and the functionality the solution provides and,
3. implementation variants and direction.

Timeline

• Forum posts explaining the problem and potential: Start in September, finish end September
• Refer to child properties: Start in Oktober, finish end of Oktober
• Compute shapes for variants: Start in November, finish end of November
• Variant parts: Start in December, finish end of December

Risks and mitigation

I would like to carry out this work as an independent contractor.

A risk of this project is that this is a challenging topic as is apparent in the lengthy discussions in #3. After discussion with @yorikvanhavre and @shaise, it is clear to me that we need to find a way to involve the community and this modified proposal tries to improve on that. This project should really be regarded as a research project that may result in the conclusion that there is no better solution than what FreeCAD currently has or that the required changes are too large or complex for FreeCAD's core. However, because the potential of the anticipated functionality is so high, I think it is more than worth of investigating the proposed functionality. Without a doubt, it will provide us with a better understanding of the challenges at hand to support the above functionality.

To mitigate the risks, this work can be considered to have two stages where stage 1 is independent from stage 2 and useful on its own:

1. referring two child properties and
2. variant parts.

A solution for stage 1 is useful on its own and it will touch the issue of cyclic dependencies. Currently, it is not allowed in FreeCAD to refer to child properties because of cyclic dependencies, so it is necessary to find a solution for the proposed behavior, possible by making informed decisions on where to allow a cyclic dependency. Any knowledge that we gain in this area, allows us to find solutions for other problems regarding cyclic dependencies.

Although stage 1 can be regarded as independent of stage 2, the latter depends on stage 1 and requires solutions for dependency management because if a property of a variant part is changed, we need to recompute based on the source document object. At this time not clear how to properly manage dependencies.

Compensation

I would like to carry out this work with for a total of 8000 EUR.

About you

My name is Pieter Hijma (pieterhijma on the forum and pieterhijma on GitHub). I'm an independent contractor (https://pieterhijma.net) and as a co-founder of the Open Toolchain Foundation, I would love to contribute to improve FreeCAD as it is an important part of open toolchains. This functionality is inspired by my personal issues regarding modularity as a FreeCAD user. For example, my post on my Fab Academy program already mentions using different categories for parameters.

I have been working on Variable Sets as an independent contractor for Ondsel. This work can be regarded as an extension of that work, but with a more fundamental solution that was out of the scope of the Ondsel contract. In that sense, I have experience contributing to FreeCAD and experience relevant to this proposed work.

I haven't worked on similar software before but I have solved similar tasks that are more architectural of nature before. An example is the Cashmere project ([1], [2]) that needed a clean interface between two existing systems.