Port attachment to be an extension

[ickby]

Hello,

I've portet the Attachment code to be an extension. Now there is no AttachableObject anymore, but every GeoFeature derived type that needs to be attachable gets the Part::AttachExtension.
The reason for this change was flexibility: The attachment code is very general, but the requirement of using the AttachableObject was limiting. For example the PartDesign primitives, the main reason for the change: It was impossible to make them attachable, as they needed to be a PartDesign feature which are not derived from AttachableObject. This needed the crude workaround of the coordinate system datum, which was complicated and unintuitive. Now the PartDesign::Primitive featuers simply use the extension.

This change also required to make the c++ version of the attachment editor a bit more general. I hence moved it to Part workbench and made it to work with every document object that has the extension.

@deepsoic: As this is your code I like to ask if those changes are ok with you? I could imagine you have some code out there in Modules that uses the AttachableObject?

https://github.com/ickby/FreeCAD_sf_mas ... onAttacher

Regards,
Stefan

[DeepSOIC]

Hi!
I haven't looked into the code, but I'm certain this can't be bad.
I have a small usage of AttachableObjectPython in Lattice2, I will port that as needed... eventually

[ickby]

ok, so the code has been merged. Now we can do all kind of funky stuff, like attachable bodies

@yorik: To make sketches Attachable Part2DObject has been derived from Attachable Object in the past. A side effect of this was that in Draft objects became attachable, they all have those properties now. With the introduced change we would be able to redo this, e.g. make draft objects not atachable while sketches stay attachable. Is this of interest for you? I never seen a use case for attachable draft objects, so maybe those properties are just confusing. Thats up to you. Currently I have left everything as it was.

[triplus]

A side effect of this was that in Draft objects became attachable, they all have those properties now.

Fantastic news!

[ickby]

A side effect of this was that in Draft objects became attachable, they all have those properties now.

Fantastic news!

To clarify, this side effect happend already with the introduction of attachments and is present in 0.16. stable. The question is if this should be reverted now that it is possible

[triplus]

I see. Well in general attaching any geometry is in my opinion desirable. Why not in the end if it can be.

[NormandC]

With the introduced change we would be able to redo this, e.g. make draft objects not atachable while sketches stay attachable. Is this of interest for you? I never seen a use case for attachable draft objects

If you mean by attachable that Draft objects could be used for PartDesign operations, I used this feature in the past mainly with Draft ShapeString which allowed me to put text on top of a plate and pocket it.

[triplus]

In Part there is an Attachment command and you can use it to for example attach Draft Circle on a Part Box:

DraftAttachment.png (8.09 KiB) Viewed 2454 times

I selected the Box face and selected the InertialCS map mode. PartDesign WB therefore isn't needed for such task. This is what i am guessing @ickby suggested to be removed. Or maybe only the map mode property for Draft Objects. And it would still be possible to use the Attachment command and just not the map mode property any more. It's a bit complex to use ATM due to all the options available but nonetheless powerful feature to have in my opinion.

[ickby]

Nice examples. If it is used of course it can stay. I'm just not a fan of cluttering the property editor with millions of proeprties noone really uses, thats why I'm asking.

[triplus]

Now we can do all kind of funky stuff, like attachable bodies

I am guessing this isn't yet exposed to the GUI? And is this capability in any way assembly related?