Getting Started - Sketcher improvement as a first task?

[LeFix]

Hey all,
first of all I'm a total newbie regarding freecad and its community. However I'm a somewhat experienced cad user (creo, solidworks) and hobby programmer (mainly c++) and I'm currently working as mechanical engineer.

I'd like to improve my programming skills while remaining close to my profession, so freecad seems perfect.

So far I built it from source (didn't look into the code yet) and created some simple parametric objects.

While using the sketcher it felt inconvenient to have three different actions (with three distinct buttons) to define a distance between two points/the length of a line segment. (horizontal, vertical, "diagonal")
At least in solidworks it's combined into one button, and after selecting the desired sketch entity its type (horizontal, vertical, "diagonal") isn't set directly but a preview is shown which changes depending on the mouse position. When moving the mouse around the entity 360deg it'll preview each type twice. When clicking the mouse the current/previewed type is selected and instantiated.

I quickly searched in the list of pull requests on gitlab, on tracker.freecadweb.org and in this forum and didn't find an already existing issue/forum thread

Since the sketcher is a basic function, I thought it would be a good starting point to familiarize myself with the FreeCad source and create a (from my point of view) more convenient workflow.

Any feedback is appreciated (specific to my idea or anything else which might be interesting for me as a first task/starting point)

Cheers Felix

[chrisb]

Hi, welcome to the forum, and thanks starting with a helping hand right away!

This has already been discussed somewhere in the forum. Abdullah may know more.

ping

[openBrain]

I'm with a mobile now but if needed I can point to the files where the magics happen.
Anyway be aware that this is probably a massive effort that you're diving in, as I'm not even sure that current implementation supports relative position computation between last click and current pointer location. Not to discourage, and probably I'd be interested in helping as I can, but do not plan this if you foresee to have only a couple hours to do it.
To get a simpler discovery of FreeCAD code, I would strongly suggest to use an appropriate IDE that will ease code navigation. My preference goes to Kdevelop, but there are others.

[LeFix]

@openBrain
That would be great.
I didn't expect it to be an easy task, especially since it's quite gui related where I lack a bit of experience.

I'd go with Qtcreator which is the IDE I lately used on linux derivatives, but I'll have a look at kdevelop, since I didn't think a lot about the choice earlier.

@chrisb is this the way to go to mention another user (by quoting an explicit ping message of the user)?

[openBrain]

@chrisb is this the way to go to mention another user (by quoting an explicit ping message of the user)?

Yep. No other choice as PhPBB is a pretty old piece of software.

[GeneFC]

Any feedback is appreciated (specific to my idea or anything else which might be interesting for me as a first task/starting point)

As chrisb said, a new developer is very welcome!

However, rather than rebuilding common UI elements known and practiced by many thousands of FreeCAD users it might be more productive to take on one of the unfinished functional enhancements or one of the remaining bugs.

I believe Abdullah has a long list of projects to tackle.

If you could fully tame sketch-flipping or b-spline awkwardness you would become a hero.

Gene

[openBrain]

However, rather than rebuilding common UI elements known and practiced by many thousands of FreeCAD users it might be more productive to take on one of the unfinished functional enhancements or one of the remaining bugs.

I think it's important that when one diving into FreeCAD codebase, he/she does it while doing something that he/she finds fun & useful to him/her. Then it may be possible that contributor starts to actively tackle things that he/she has no particular interest in when code understanding has reached a certain level.

As you talked about 'rebuilding', I take occasion that new things should IMO be introduced as much as possible as extras before thinking to replace totally the old working ones. In this example, I would advise to introduce the tool as a new one that automatically determines horizontal/vertical/parallel distance based on mouse position while keeping the old good ones active. Then the new tool can be thoroughly tested and falling back on old ones is still possible. Only when the new tool is mature and vetted as being able to replace the old ones, the latter can be removed.

If you could fully tame sketch-flipping or b-spline awkwardness you would become a hero.

Those ones probably touch solver more than sketcher and can be a pitfall for new contributor.

[LeFix]

You're writing down my thoughts...
I'm afraid my motivation for "work" in my spare time heavily depends on the fun factor and own interests

Anyone might introduce me to some task/problem as long as they consider the points which openBrain mentioned.

[LeFix]

I'm trying to understand the existing code and tend to refactor parts of it while doing so.

Ideally refactoring and feature changes are not combined in commits (and PRs?).
I wonder at which point a "small refactoring" is worth its own/early PR. When they are small they can be approved faster, but each one comes with some overhead I assume.

For example I changed quite few lines to reduce the redundancy (https://github.com/FreeCAD/FreeCAD/comp ... s?expand=1)
0penBrain has a recent pull requests editing the same file and there probably will be ugly merge conflicts when merged late.

So should I open a pull request with this one commit, add more refactoring and do it later or "hijack" an existing sketcher refactoring pull request and merge my commit on somebody's branch so they get approved alltogether?

[openBrain]

There's no clear rules, but IMO the most important thing for a PR is that it is complete and consistent (so a PR merging leads to a compilable code). Then ideally it should try to be limited to a single "feature" or eventually a small size of consistent ones.
PR should generally be of only one type among 'Refactoring', 'Bug fixing', 'Feature improvement' or 'New feature'.
Commits should be 'atoms' of PR and organize so it's easy to follow changing process. It's important to me that when a PR is updated for improvement (eg. following review), changes are properly squash/fixup rather than just stacking changes.
Git isn't so bad at merging, so as long as same part of code isn't touched twice, having same file on PR should go fine.

Making quite small PR is good as they are easily reviewed.

Finally at the end, I tend to believe that any contribution is valuable, so probably just do as you feel it good, and eventually somebody will tell you if you can do better (in the context of FreeCAD).