Inconsistencies in PartDesign BaseFeature

[NomAnor]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

When a PartDesign::Body is created from a Part::Feature a PartDesign::FeatureBase is automatically created to reference the Part::Feature. Its "Base Feature" property is setup to allow global links:

FreeCAD/src/Mod/PartDesign/App/FeatureBase.cpp

Lines 39 to 43 in e4eb859

	FeatureBase::FeatureBase()
	{
	BaseFeature.setScope(App::LinkScope::Global);
	BaseFeature.setStatus(App::Property::Hidden, false);
	}

Additionally the PartDesign::Body "Base Feature" property is synced with the PartDesign::FeatureBase property:

FreeCAD/src/Mod/PartDesign/App/FeatureBase.cpp

Lines 87 to 95 in e4eb859

	void FeatureBase::onChanged(const App::Property* prop) {
	// the BaseFeature property should track the Body BaseFeature and vice-versa
	if (prop == &BaseFeature) {
	trySetBaseFeatureOfBody();
	}
	Part::Feature::onChanged(prop);
	}

but the PartDesign::Body only allows local links (as default, inherited from Part::BodyBase).

Full version info

OS: Arch Linux (XFCE/xfce)
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.36695 (Git)
Build type: Debug
Branch: main
Hash: 6c0865a7b974cd8100585a42a9b2d21643be871f
Python 3.11.8, Qt 5.15.13, Coin 4.0.2, Vtk 9.3.0, OCC 7.3.0
Locale: German/Germany (de_DE)
Installed mods: 
  * Manipulator 1.5.7
  * ThreadProfile 1.84.0
  * DynamicData 2.60.0
  * lattice2 1.0.0
  * 3D_Printing_Tools
  * freecad.gears 1.0.0
  * Assembly3 0.11.3
  * QuickMeasure 2022.10.28
  * fasteners 0.4.21

Subproject(s) affected?

PartDesign

Anything else?

As explained in #13762, I was trying to create a base body and then create multiple bodies from it to add some PartDesign features and use them a bodies in parts. I use App::Part containers as parts which then contain one or more bodies (not necessary PartDesign::Body).

Essentially I want to end up with this:

Two problems arise from this:

1. The Part cube is automatically added to the App::Part of the newly created body

2. Rearanging the tree manually will give the warning

   PartDesign::Body: Link(s) to object(s) 'Box' go out of the allowed scope 'Body'. Instead, the linked object(s) reside within 'N/A'.

   about the link scope, coming from the Body, not the BaseFeature because of the different scopes of the "Base Feature" properties.

It seems that base features were intended to link to global objects. Should the Body "Base Feature" property be changed accordingly?

Code of Conduct

• I agree to follow this project's Code of Conduct

[maxwxyz]

why not use shape binders and make a new option to them to be like real geometry?

[NomAnor]

I'm not sure if I like this option from a users perspective. ShapeBinders are currently used as reference objects in a PartDesign::Body (same as Sketches and Datums). This would mean some shape binders will become PartDesign::Features in some circumstances which would be confusing.

The PartDesign::FeatureBase is already there, it just needs to be more generic in what objects it allows to reference. The restriction only seems to be in the UI code. I removed the if and it seems to work fine.

If the local link scope of the bodies "Base Feature" is necessary for other reasons, maybe there is a way to still allow to use the FeatureBase to have global scope without warnings? Why are the "Base Feature" properties synced?

[FlachyJoe]

why not use shape binders and make a new option to them to be like real geometry?

A ShapeBinder can already be solidified by a boolean fuse (with nothing else).

[maxwxyz]

I know, to get rid of that extra step the ShapeBinder could have an extra attribute makeRealGeometry