[In progress] Sketcher Roadmap

[abdullah]

Hi!

I have been asked several times last year for a roadmap.

While we have always worked by selecting a feature that we want to implement and just doing it, as more developers focus on the sketcher I think it makes sense to have a global idea of where we are moving to. This does not change the fact that anyone should work where he or she likes.

This is intended as a kind of live post.

WP => Work Package
FFS => For Further Study

Refactors

WP 1 - Sketcher Commands and DrawSketchHandler

Problem:
Sketcher commands duplicate a massive amount of code. This makes them very difficult to maintain and extend (e.g. contextual constraining) in that it only leads to even more duplicated code.

Scope:
Inter commands => Code duplication includes code duplication between totally different commands (for example getting the selection and doing checks). I think we need a base class for the sketcher with all this common code, so that derived classes (the actual commands) just reuse this code. This is not only "constraint commands", but also "geometry" and "tools" commands. I do not know if it is feasible/convenient for this case, but some pattern like NVI could be studied [FFS].

Intra commands but Inter modes => For constraints, we have two modes (select+hit the button and button+hit the elements), with contextual constraining, we might need to have three. We cannot repeat and repeat code. It becomes cumbersome to maintain. Geometry/constraint/selection processing needs to be separated from UI usage. Modes should be implemented in a generic way, with specific implementations. Adding a mode should, ideally not require changing the generic code, just adding some code to handle the "getting in the middle between the UI and the processing".

Responsibility separation => At least the following responsibilities should be separated: a) recomputing/solving functionality, b) UI interaction (DrawSketchHandler), c) Interactions with the viewProvider.

The last coin refactor already included a small refactor to separate VP from DrawSketchHandler by defining a very specific interface (attorney). I think that classes deriving from DrawSketchHandler (each command interacting with the UE has one of those), should not have direct access to the VP (no pointer accessible to them would be ideal). Every such class should rely on (generic) functionality offered by DrawSketchHandler to interact with the VP. This should also promote code reuse.

Commands should also centralise access to the ViewProvider in a base class to promote code reuse. This central place should take over the responsibility to access the VP for all commands.

Planned features
- Geometry Layers
- Offset curves
- Text in sketcher
- Contextual constraining

Any developer is invited to implement whatever he or she likes, including items from the list above. The list is just an indication of what I would like to have. If you want, you can ask for a feature you will implement or are implementing to be added to the list, we can also put your name next to it so that the rest knows you are working on it.

This post is just an idea. It might not be the best way. It is just a first approach.

I will still have low availability in February 2022. In the time I have, I will do bug fixing with the highest priority, then PRs.

[paddle]

I've seen indeed that there is quite some code copy paste in the CommandConstraints.cpp, specially since you have activated and applyConstraint which makes the constraints in a separate way.

Regarding 'Constrain Contextually', I indeed had to write specific versions of each constrain function. Which adds to code multiplicity so thats not ideal and while doing it I thought it could be refactored but didn't want to touch what was existing and just do my thing.

Then, the "space" solution could be a user preference to hide the toolbar unless the area is hovered (or for the brave, not to show the toolbar at all). Rather than fight a battle for every tiny space saved by a single button, forgo the war and save a whole toolbar.

I didn't touch the tool bar but I was thinking about simplifying it with a preference setting (to have the possibility to choose current tool layout vs new tool layout)
For the new tool layout I was thinking of putting the constraints that are replaced by 'Constrain Contextually' in a comp under it (coincident, pointOnObject, distance/X/Y, angle, lock, radius). This way the buttons would be out of the way but still accessible in case they are needed in specific cases.

Another feature that I made is ToolSettings, it's really convenient to speed things up too. Though it's already done so I don't know if you want to put it in the roadmap?

Offset curves and text would be awesome additions. But I have no clue how to do them. For offset I have an idea how to handle it for basic geometries. But for bspline/externalgeo/hyperbola...?

On my personal roadmap I also have in mind to work on sketcher geometries modifications. Which includes :
- Group dragging : A solver bug at first try to fix
- ctrl-C/X/V for Copy/Cut/paste : Done but could be improved with group dragging when it's working properly. Also as OpenBrain mentioned it should be implemented in general Command file rather than in ViewProviderSketcher keypress function.
- Geometry scaling
- Geometry rotation
- Circular copy : To be able to make circular patterns, ie copy/rotate a geometry every angle x.
- Improve rectangular array.

Also

bing

Is working on distance between circles. Initially he was targeting specifically distances between 2 co-centric circles, but he seems to also do general distances between circles, and perhaps circle to line too.
Can't wait to integrate that in ConstrainContextually btw

[cadcam]

[Posting moved from Announcement forum - although some to the topics/concepts discussed in the previous postings seem to extend beyond
'Part Design module developement']

The sketcher is probably the most important part of FreeCAD, but how it is used is so varied due to a vast range design tasks
and individuals different thought/design processes. Ideally the system should be automatically taylored to a users
situation but this is impossible. Abdullah et al. have produced some amazing core funcionality that rivals, and in some areas may
exceed, some of what have been considered 'best in class' commercial solvers. Along with this, the UI has continued to improved
enormously and with the recent work of Paddle and other looks to continue apace. In a couple of recent posts, (OP in this thread) Abdullah has
made some very considered/knowledgable in put about the probably need to do a major refactor of the existing code andto ensure additional functionality/usability is at least consistent.

In another thread (https://forum.freecadweb.org/viewtopic.php?f=8&t=65667) I suggested possibly setting up an area where
changes (to functionality/UI) in FC could be put up as precompiled releases for those many users who may not have the ability/time
to recompile each iteration. The concept seemed to gain some traction but currently nothing, as far as I know, has progressed.

I was wondering given the number of users who have significant FC/sketcher use experience to share if Paddle's new ideas would be an ideal testbed for
increasing feedback from the community prior to merging, especially as there may be a delay before Abdullah may have time to fully look at the PR.

Moving forward to the possible refactoring I am sure there are many plain users (i.e. non-developers/compilers) who would
be very willing to trial developments/give feedback early, using their own specic if design proceedures/methods, which could possibly
help to capture unexpected changes/difficulties.

Offering this ability might help to engage those thousands of FC users who don't feel like poking their heads above the parapet,
with code/documentation etc, but would really like to contribute to the project.

So as a trial I wonder if Paddle, or possibly someone else working with him, might consider putting up&maintain, Windows and Linux binaries
of a test version of his significant array of changes to Sketcher. It would probably also require a seperate? forum thread or github area
with a notice indicating the purpose (e.g. just feedback on specific/listed changes).

I notice Paddle has been developing on Windows so producing .exe may be 'relatively' easy and if made available may incentivise
some of the less willing to experiment users to get involved.

If the test proves useful/popular, the concept might be extended to hopefully release some of
the core testing/checking from developers, if fundamental refactoring is undertaken.

Just my quick thoughts and obviously requires buy-in from the developers, and especially from Paddle if his work is to be used
as a trial.


Best Wishes

[paddle]

It's a good idea, I have been thinking about sharing build version of my branches for test.
But the feature has been maturing rapidly in the first place.
Also I'm not very knowledgeable on how to share build. I have a built debug version which is in the same folders so it looks troublesome, I'm not sure how to.

[cadcam]

@Paddle - I think everyone understands the fast development
you are doing and the associated difficulties. However, many
would welcome the opportunity to give some feedback even if the
total functionality is a few updates behind.
The only problem may be addition work to for yourself, occasionally having
to indicate that an issue has already been addressed, However, I think most
poster will be careful to check previous posts in the thread.

Regards

[Shalmeneser]

Would it be possible at this occasion to allievate the severity of selection then tool mode.
* if you select lines, some with horizontal constraint, some without it, the sketcher will refuse your horizontal constraint.
* if you box-select lines and constraint-icons, the sketcher will refuse your horizontal constraint.

[adrianinsaval]

what happened with the sketcher chamfer stuff? Was that you paddle? Is it abandoned?

[paddle]

what happened with the sketcher chamfer stuff? Was that you paddle? Is it abandoned?

Yes it was, it was pending review by Abdullah but then he got busy.

Although I just integrated Fillet/chamfer into my constrain contextually branch. See its forum topic for more details. I'll probably make another video to show the advancements.

I'll also add arc slot tool to add toolsettings support as well.