Discussion on Dressups and Tool Controllers

[JoshM]

I agree. That's a problem. Want to add a bug?

Sure will.
-j

[schnebeck]

Talking about dress-up ops:
me as a user wonders why can I not use some Dress-Up operations in a nested way e.g. Helix ramp contour + Lead in/out?
For me some combinations of path Dress-Up OPs could be quite useful that are by now not allowed. So when there are some modification necessary for improving Dress-Up, maybe its possible to use these Ops in an object-oriented way. An OP could inherit the TC from the sub-object. The sub-object could be an already nested structure, which got the TC inherit from a base object (a basic Path operation).

Bye

Thorsten

[bill]

it would be wrong to add a TC to the dressup

Yes, I agree with this because: a Path:Dress-Up is just that, a path modification, and not a tool-change.

But for the sake of data-structures, most probably should look like any other operation making its interoperability with activities such as Sim well defined/standardized.

If some user(like me) needs to chase the profile with a chamfer, then copy/clone the profile operation, set an offset, and utilize another tool selection.
This is why Ive always wanted to be able to clone an operation, preserving all op detail; then just change the tool selection.

Additionally, I think this topic should be its own thread and needs to be moved since this borders on thread hijacking!

[sliptonic]

it would be wrong to add a TC to the dressup

If some user(like me) needs to chase the profile with a chamfer, then copy/clone the profile operation, set an offset, and utilize another tool selection.
This is why Ive always wanted to be able to clone an operation, preserving all op detail; then just change the tool selection.

Additionally, I think this topic should be its own thread and needs to be moved since this borders on thread hijacking!

I agree about thread-jacking but I'm not a forum admin. As for the cloning, don't we already have this?

snapshot-3.png (142.92 KiB) Viewed 1069 times

[chrisb]

I can split it, but I have to get it right the first time, because I am afraid will not be able to merge things later. So where should I split it:
either here: https://forum.freecadweb.org/viewtopic. ... 30#p217733
or here: https://forum.freecadweb.org/viewtopic. ... 40#p217869

[sliptonic]

I can split it, but I have to get it right the first time, because I am afraid will not be able to merge things later. So where should I split it:
either here: https://forum.freecadweb.org/viewtopic. ... 30#p217733
or here: https://forum.freecadweb.org/viewtopic. ... 40#p217869

I think at 217733.

[chrisb]

Splitting is done.

[herbk]

Hi Sliptonic,

As for the cloning, don't we already have this?

Yes we have, - but it dosn't work on a operation with a dressup. Also array dosn't work on a operation with dressup.
Last tested with AppImage

OS: "openSUSE Leap 42.3"
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.13340 (Git) AppImage
Build type: None
Branch: master
Hash: 29864ff82173e501e220e754ccfe845b53990908
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: German/Germany (de_DE)

[jmr]

Hey!
Another thing to add is that all Dressups should get the Active property of the parent operation. Do You agree?
for RampEntry, when the Active of the parent is toggled I get the red exclamation and it does not recompute, then I get the old ramp entry code without the pocket... or like that, while Dogbone disappears correctly. This toggle Active thing is very useful when testing parts of code and then moving on to next operation, or when one operation failed.
Could it also be toggled together with visibility?

[roivai]

Yes we have, - but it dosn't work on a operation with a dressup. Also array dosn't work on a püeration with dressup.
Last tested with AppImage

I fixed this one - made PathArray to accept Dressups. The commit is here:
https://github.com/pekkaroi/FreeCAD/com ... 0c1f4d2da1

Before pull request - I'd like to have comment from sliptonic or mlampert about the usage of

Code: Select all

isinstance(obj.Proxy, PathScripts.PathOp.ObjectOp)
and
obj.isDerivedFrom("Path::Feature")

It is not very clear to me what is defined as PathOp.ObjectOp and what is derived from Path::Feature. That condition I ended up with to enable the PathArray is not very sensible IMO:

Code: Select all

 return isinstance(obj.Proxy, PathScripts.PathOp.ObjectOp) or (obj.isDerivedFrom("Path::Feature") and "Dressup" in obj.Name)

Should this be inculded in 0.17?