I'm still finding typos in the source code. I propose that you keep this PR open prior ro relaese and then merge so that if I find other typos in the meantime they will be part this release.
Found via `codespell -q 3 --skip="*.po,*.ts,./.git,./src/3rdParty,./src/CXX,./src/zipios++,./src/Mod/Assembly/App/opendcm" -I ~/Projects/fc-word-whitelist.txt`
Whitelist consists of:
```
aline
alledges
als
ang
behaviour
bloaded
calculater
cancelled
cancelling
cas
centimetre
childs
colour
colours
doubleclick
dum
eiter
elemente
freez
iff
indicies
initialisation
initialise
initialised
initialises
kilometre
lod
mantatory
methode
metres
millimetre
modell
nd
normaly
nto
oder
ot
pres
que
recurrance
rougly
seperator
serie
strack
substraction
te
thru
vertexes
whitespaces
```
=============================================================
The values for the primitives are set after the connections to the slots "onchange" are connected.
This causes a river of onChanges at feature level which set the properties and modify the feature (to the same values).
Moving the connections at the end of the function just solves this issue.
=========================================================
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.
