Discussion for merger of Pocket and 3D Pocket

[Russ4262]

Good day.
Was working on the wiki and it occurred once again that we have independently coded Pocket and 3D Pocket operations. Understandably their origins are different, and as far as I know, their code is a bit different. A while back a merger of the pre-existing Contour, Profile Faces, and Profile Edges operations was successful. So, now the question of merging the two pocket operations comes to mind. Are the two not stable and used regularly with success? The Pocket op contains the extensions feature, lacking in 3D Pocket. Looking at the GUI side, the inputs are almost identical. I have not surveyed the actual properties required for each.

Pros? Cons? Reasons therefore?

Running list per posts in this thread:
Pocket

• Allows extensions to edges because bottom of pocket is horizontal.
• Has `Use outline` feature
• Allows for selection of faces or edges.

3D Pocket

• Requires selection of bottom face(s) of pocket.
• Allows for pocketing of hole with non-horizontal bottom.

Thanks for your insights. Not suggesting a timeline here.
Russell

[herbk]

Hi Russel,
if i remember right, Pocket supports pockets without bottom, 3D Pocket don't support it. In my mind it's good to have this behavior of Pocket...

[GeneFC]

Simplifying the user choices in the main Path menu is a good idea.

I think that keeping a fair degree of user control in the actual task panel is important. One of the key reasons the Contour and Profile merger was successful is that the user can still choose the type of operation. I have found cases where one selection did not work well, and another did. Sometimes edges work better, sometimes faces, sometimes overall outline.

Gene

[Russ4262]

Hi Russel,
if i remember right, Pocket supports pockets without bottom, 3D Pocket don't support it. ...

Morning Sir.
Thanks for pointing that feature out. I don´t know why that feature could not remain in the merged version. I can think of a 3D test to add to the code, based on experience with other ops I have touched, that could identify whether a pocket is open on the bottom and apply the correct pocketing code.

Thanks @Herbk, I will update the OP to reflect this difference.

Simplifying the user choices in the main Path menu is a good idea.

I think that keeping a fair degree of user control in the actual task panel is important. ...

Okay. Do you have any specifics to the current Pocket or 3D Pocket operations to identify here. Looking at their GUI interfaces, the two are almost identical except for the `Extensions` feature in Pocket. Also I think Pocket has two additional boolean checkboxes at the bottom of the Operation tab, `Use outline` and one other. (I am not in front of a FreeCAD machine at the moment.)

In order to determine if a merger is a good idea, we need to determine the uniqueness of each operation in its current state and determine if those unique features can be easily maintained and easily accessible if the two ops are merged.

Thanks @GeneFC.

Russell

[sliptonic]

If we're talking about merging UI, I don't think it's necessary but I'm listening.

However, If we're talking about merging code-bases then, right now, I'm 100% against it.

The existing operations code is already a tangle and we're seeing very few contributions from new developers.

Adding 4th axis rotations onto existing operations added great functionality but made the whole thing much more difficult to maintain. We probably should have created entirely new 4th axis operations with cleaner code. That's on me for not having a better vision of how to organize the code-base.

The UI is far from perfect but I don't think user confusion is our big issue. Developer confusion is much more likely to slow down future development. We need to concentrate on making Path code fast, robust, and maintainable.

[freman]

I'd agree with Sliptonic. The code of the two approaches, 2.5D and 3D tools is so different, I don't see merging as a good idea. It would be shoe-horning two different bodies of code together rather artificially and would probably need a bunch of ifdeffing which would just make both less readable and maintainable.

While UI clutter is to be avoided if possible , I think the user end functionality of these tools is also different enough that a clear distinction is helpful.