"Professional CMake" book suggest the following:
"Targets should build successfully with or without compiler support for precompiled headers. It
should be considered an optimization, not a requirement. In particular, do not explicitly include a
precompile header (e.g. stdafx.h) in the source code, let CMake force-include an automatically
generated precompile header on the compiler command line instead. This is more portable across
the major compilers and is likely to be easier to maintain. It will also avoid warnings being
generated from certain code checking tools like iwyu (include what you use)."
Therefore, removed the "#include <PreCompiled.h>" from sources, also
there is no need for the "#ifdef _PreComp_" anymore
This unifies deletion behavior for all PartDesign features ensuring that
sketches that were used to create these features show after deletion and
that the tip is properly transfered.
Unparented popups can easily get lost in backround, but they still block top level event loop when run with ::exec() thus preventing interactions with main window. This mainly happens on wayland. Setting the parent ensures they are always kept on top and reasonably positioned.
This commit is generated using regex based find and replace:
```
s/[\w:]+_cast\s*<([^>]+)\*>\s*\(\s*getObject\(\s*\)\)/getObject<$1>/
s/[\w:]+_cast\s*<([^>]+)\*>\s*\(\s*([^)]*)\s*->\s*getObject\(\s*\)\)/$2->getObject<$1>()/
```
To regenerate if needed.
===============================================
Before this implementation, specific status via former mergeOverlayIcon() was greyed out
with the visibility.
With this commit, the developer has two options:
a) override mergeGreyableOverlayIcons, in which case the overlay will
be greyed out when the item is greyed out as per former mergeOverlayIcon()
b) override mergeColorfulOverlayIcons, in which case the overlay will
be superimposed after the icon is greyed out as it is the case for stardard
error and recompute flags.
=========================================================
fixes#3084fixes#3061 (at least what it is understood in the analysis as being a bug, the visualization left).
Basically when deleting a feature, if it is the base feature (feature with which it will merge or cutout), the dependent objects'
base feature is made to be the base feature of the object being deleted. This code pre-existed at body level, but was not being called (see below).
Additionally, if the visible object is not the one being deleted, we leave that one visible. If the visible object is the one
being deleted, we make the previous object visible.
Deletion from the tree of a feature is handled by Document.removeObject, which has no clue about what a body is. Therefore, Bodies, although an
'activable' container, know nothing about what happens at Document level with the features they contain.
The Deletion command StdCmdDelete::activated, however does notify the viewprovider corresponding to the feature (not body) of the imminent deletion
(before actually doing it). Consequently, the only way of notifying a body of the imminent deletion of one of its features so as to do the clean up
required (moving basefeature references, tip management) is from the viewprovider of the feature being deleted.
