[sketcher] How do CloseShape and ConnectLines features work?

[Roy_043]

The current implementation just connects start to end points. I would consider it an improvement if points that are closest are connected instead. And that is probably doable.

[chrisb]

We should look at the complete use case: This function can be used for basic elements, i.e. lines and arcs, with auto constraints off. These don't fall completely arbitrary from the sky, but are usually created one by one roughly following some shape. If such elements are connected it should be quite good.
However, I would rather recommend to use the polyline tool instead to create connected lines and arcs right away.

[abdullah]

Some tools take off. Some others look like a good idea, but they finish up not being of that much use. I think this tool belongs to the latter group. I do not use it...

[uwestoehr]

Some tools take off. Some others look like a good idea, but they finish up not being of that much use. I think this tool belongs to the latter group. I do not use it...

Oh, that was no criticism from my side. I only misunderstood what it is capable of.
I will improve its documentation with the limitations the next days.

Roy's proposal to change it so that always the nearest vertices will be connected, could make the tool more useful. However, I guess also with this it is not that useful in practice because there one deals usually from the beginning with constraints. Therefore I am not sure the work to change the tool is worth it.

[abdullah]

Some tools take off. Some others look like a good idea, but they finish up not being of that much use. I think this tool belongs to the latter group. I do not use it...

Oh, that was no criticism from my side. I only misunderstood what it is capable of.
I will improve its documentation with the limitations the next days.

Roy's proposal to change it so that always the nearest vertices will be connected, could make the tool more useful. However, I guess also with this it is not that useful in practice because there one deals usually from the beginning with constraints. Therefore I am not sure the work to change the tool is worth it.

We are ok Uwe. I did not take as criticism. Objectively speaking it has no place in my toolbox. I am still to see one use case where it would be the preferred choice.

I do not know what I had in mind when I coded that. Maybe it related to constraining imports from DXF or similar. Now autoconstraining routines are far more powerful...

[chrisb]

Maybe it related to constraining imports from DXF or similar.

That's indeed a sensible use case; however, the validation tool may be preferred because it is closer to the nearest neighbour solution.

[abdullah]

Maybe it related to constraining imports from DXF or similar.

That's indeed a sensible use case; however, the validation tool may be preferred because it is closer to the nearest neighbour solution.

I never thought of using the validation tool.

Autoconstraining routines do not have a UI currently, but connection to nearest neighbour can be done without leaving edit mode:

Code: Select all

>>> ActiveSketch.detectMissingPointOnPointConstraints()
>>> ActiveSketch.makeMissingPointOnPointCoincident()
>>> ActiveSketch.solve()

In fact, if I remember correctly, the validation tool uses the autoconstraining analysis and constraining functions internally.

For the DXF case, autoconstraining functions have additional advantages, as they find other types of constraints, such as vertical and horizontals.

Code: Select all

>>> ActiveSketch.detectMissingVerticalHorizontalConstraints()
>>> ActiveSketch.makeMissingVerticalHorizontal()
>>> ActiveSketch.solve()

If the drawing is not too big also equality constraints (it takes forever if there are many equality constraints with the current implementation). See:
https://forum.freecadweb.org/viewtopic. ... 58#p244358

So, all in all, one would use the validation tool for a visual UI tool with the closest neighbour in mind, or possibly autoconstraining routines if more than that is necessary... leaving no use case for this. If I knew with certainty that it breaks no user script, I would tend to think that it is best to remove it altogether...

[chrisb]

So, all in all, one would use the validation tool for a visual UI tool with the closest neighbour in mind, or possibly autoconstraining routines if more than that is necessary... leaving no use case for this. If I knew with certainty that it breaks no user script, I would tend to think that it is best to remove it altogether...

I admire this proposal. It is very hard to remove things that have been thoroughly implemented and work as designed. But for the sake of clarity I support your proposal.

[uwestoehr]

I admire this proposal. It is very hard to remove things that have been thoroughly implemented and work as designed. But for the sake of clarity I support your proposal.

Me too. Even considering the removal of something one once invested a lot of time is not easy. I also agree that the removal is maybe the best to far.

[abdullah]

I admire this proposal. It is very hard to remove things that have been thoroughly implemented and work as designed. But for the sake of clarity I support your proposal.

I am generally in favour of removing unnecessary features, because code needs to be maintained and there is no point in maintaining unnecessary code.

The problem starts when one removes code on which, for example, a user macro or wb relies. The macro or wb will stop working.

So generally speaking, the decision is between running the risk of breaking user code and living surrounded by code cadavers.

In this specific case, I doubt anything is broken. If something is broken, there is a successful substitute with autoconstraining code. However, I need to have time to do it and now I am still refactoring Sketcher code... feel free to remind me if I forget.