This is awesome! Thanks for sharing.

Can you take a quick look and give us a thumbs up so we can do this? I certainly have no issue with it - although underscores are ugly ;) Anyway, if this is worth doing why not bring _all_ icons into compliance? IIRC I copied those arrow icons from TechDraw, 'cause I needed something like that and ...

what I had in mind was comparing the tangents of the two paths at the intersection point, and maybe making the threshold angle 45° or even 60°. Don't think it needs to be adjustable. The only concern is the runtime inpact calculating all those tangents.

filed an issue for it for tracking: issue #4500

Russ4262 wrote: ↑Sat Nov 21, 2020 1:01 am

mlampert wrote: ↑Fri Nov 20, 2020 11:52 pm ... My 2 cents, ...

Are those Canadian cents or United States cents? I'm just asking so I have a better idea of how to value the comment.

Canadian - might not be worth as much but it looks better

Hi Russell, I would probably hold off on refactoring at this point. From what I hear the plan is to get 0.19 out this year which means we should leave the ops as they are and focus on bug fixes. The toolbits sliptonic is working on should probably be the last major change, at least to Path core ops....

I have a task panel where I can deterministically generate a segfault by changing the focus from one a QLineEdit widget to a GUI::QuantitySpinBox. The only "non-standard" thing is that the quantity spin boxes are created programmatically with FreeCADGui.UiLoader.createWidget('Gui::Quantity...

A few weeks ago sliptonic added the v-carve op, which should allow you to create the negative. Creating the positive is not possible straight out of the box. You could probably establish it by creating two models, one for v-carving the inlay positive and one for milling away the flat areas. The gap ...

I am to blame for the mess created within the code by the rotational features. As such, I will help fix it. Blame? I think we're all in awe and quite excited about what you have accomplished! sliptonic's point about maintainability is very valid though - the code size of each op has gotten to the p...

I think the root of the problem is that we chose to use the ToolBit name as the name for ToolController (blame me for that poor choice) - now that both are in the tree they clash. We should give the ToolController a different label, maybe "TC-<ToolBitName>". What adds to the confusion is t...