kindred/create
1
1
Fork 0
Code Issues 53 Pull Requests Actions Packages Projects 9 Releases 2 Wiki Activity

Toponaming: Refactor refine to its own FeatureRefine class

Browse Source
This commit is contained in:
bgbsww
2024-07-30 08:34:34 -04:00
parent 9de78e27f4
commit ae46ea5e7b
15 changed files with 185 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
src/Mod/PartDesign/App/FeatureBoolean.cpp
View File

@@ -53,10 +53,6 @@ Boolean::Boolean()
ADD_PROPERTY(Type,((long)0));
Type.setEnums(TypeEnums);
ADD_PROPERTY_TYPE(Refine,(0),"Part Design",(App::PropertyType)(App::Prop_None),"Refine shape (clean up redundant edges) after adding/subtracting");
Base::Reference<ParameterGrp> hGrp = App::GetApplication().GetUserParameter()
.GetGroup("BaseApp")->GetGroup("Preferences")->GetGroup("Mod/PartDesign");
this->Refine.setValue(hGrp->GetBool("RefineModel", true));
ADD_PROPERTY_TYPE(UsePlacement,(0),"Part Design",(App::PropertyType)(App::Prop_None),"Apply the placement of the second ( tool ) object");
this->UsePlacement.setValue(false);
@@ -188,25 +184,4 @@ void Boolean::handleChangedPropertyName(Base::XMLReader &reader, const char * Ty
}
}
// FIXME: This method ( and the Refine property it depends on ) is redundant with the exact same
// thing in FeatureAddSub, but cannot reasonably be moved up an inheritance level to Feature as
// there are inheritors like FeatureBox for which a refine Property does not make sense. A
// solution like moving Refine and refineShapeIfActive to a new FeatureRefine class that sits
// between Feature and FeatureBoolean / FeatureAddSub is a possibility, or maybe [ew!] hiding the
// property in Feature and only enabling it in the places it is relevant.
TopoShape Boolean::refineShapeIfActive(const TopoShape& oldShape) const
{
if (this->Refine.getValue()) {
try {
return oldShape.makeElementRefine();
}
catch (Standard_Failure&) {
return oldShape;
}
}
return oldShape;
}
}