===============================================
Removal of ViewProviderGridExtension properties:
-GridStyle
-GridSnap
Improvement of ViewProviderGridExtension API:
- color via App::Color
Toolbar grid command:
- Conversion of Snapping to edit parameter
- Snap gets a class enum to support future Snapping functionalities as edit parameter
Sketcher Settings:
- Removal of snap preference
Behaviour:
- ShowGrid, GridAuto, GridSize preferences do not change any existing VP. They apply to any newly created sketch.
- Do not limit grid to hardcoded values
Snap to grid:
- Code updated to use closestpoint functionality provided by the extension,
Several other fixes
==================================
- Move all grid specific code out of ViewProviderSketch and EditModeCoinManager.
- The code in made into a new extension in Part - ViewProviderGridExtension
- ViewProviderSketch starts deriving from this new extension
- ViewProviderSketch configures the extension according to its Grid preferences
- Grid code refactored to remove hardcoded sketcher preference parameters.
- ViewProviderGridExtension handles property name/type changes within its competence.
==========================================================
Currently changes of name or type of properties in a property container are handled by:
void PropertyContainer::handleChangedPropertyName(Base::XMLReader &reader, const char * TypeName, const char *PropName)
void PropertyContainer::changedPropertyType(Base::XMLReader &reader, const char * TypeName, Property * prop)
There is no mechanism for handling property changes by extensions. Sometimes the solution is to explicitly call the extension
from the container. However, this is a breach of the SRP, as the container should not be in a position to decide whether the
extension needs or not handle property changes. The handling code of the container changes for two different reasons, for
adapting the container to a property change of its own, and for adapting that of a property of the extension.
Illustrating it with an example, following inheritance, it goes like this:
PropertyContainer => ExtensionContainer => TransactionalObject => ViewProvider
App::Extension => ViewProviderExtension
The extension is currently not notified by the ExtensionContainer that a property needs handling. So a change in a property of
a ViewProviderExtension needs code at the ViewProvider it was added to.
This commit provides a mechanism in ExtensionContainer to call the extensions so that they can handle property changes. This
functions:
virtual bool extensionHandleChangedPropertyName(Base::XMLReader &reader, const char * TypeName, const char *PropName);
virtual bool extensionHandleChangedPropertyType(Base::XMLReader &reader, const char * TypeName, Property * prop);
Containers should always call the base class for any unhandled property change. If a sub-class container of ExtensionContainer
handles property changes itself, but not the ones of the extensions, this call to the base class ultimately ensures that if the
property was not handled by the container hierarchy, any extension is given an opportunity to handle it.
Some examples:
* A container handles the extension property change or its own:
void ContainerSubClass::handleChangedPropertyType(...)
{
if (prop == &PropertyOfExt) {
}
else if (prop == &PropertyOfCont) {
}
else {
ContainerBaseClass::handleChangedPropertyType(...);
}
}
* A container and the extension handle their own:
void ContainerSubClass::handleChangedPropertyType(...)
{
if (prop == &PropertyOfCont) {
}
else {
// This will call ExtensionContainer::handleChangedPropertyType
ContainerBaseClass::handleChangedPropertyType(...);
}
}
bool ExtensionSubClass::extensionHandleChangedPropertyType(...)
{
if (prop == &PropertyOfCont) {
return true;
}
return false;
}
==============================
Fix unresolved issues:
https://github.com/FreeCAD/FreeCAD/pull/7754/files#r1025493443https://github.com/FreeCAD/FreeCAD/pull/7754/files#r1019077589https://github.com/FreeCAD/FreeCAD/pull/7754/files#r1025502204
Summary:
- EventFilter unnecessary in light of new implemented signal aboutToshow. The data of the drop-down action is updated only when necessary (when it is going to be shown).
- Structure of individual commands under drop-down simplified to a single action, rendering the need for groupcommands obsolete, while keeping all the grid related controls and
the logic for controlling the grid in a single action class.
- Reduce the complexity and overload of isActive to the bare minimum (determining if it is active and updating the icon to the right icon if so).
Refactor:
- Better name for utils functions, as when a DSH is active, the edit mode VPSketch is a data member of DSH, sketchgui (so this function is not really necessary when the DSH is active).
==============================================
ActionGroup may integrate a drop down menu (internally a QMenu).
QMenu has signals aboutToShow and aboutToHide, which are called just before showing/hiding the menu.
This commit extends ActionGroup by providing corresponding signals.
An ActionGroup can be added to more than one toolbar and thus creates more than one menu. So, it can theoretically
happen that you have opened a menu and click on another menu. For this reason, the menu is passed as argument:
void aboutToHideMenu(QMenu*);
void aboutToShowMenu(QMenu*);
- it was frequently requested and people now even published videos since I documented this hidden feature in the Wiki.
However, for a user it is a nightmare without a UI and users who like a bright background need to change the button color to keep the buttons visible.
Support for creation of Rotation from matrices which is a combination of non uniform scale and a rotation
Fixes according to review
Scale -1 is Uniform, Not NoScaling
Fix hasScale() when negative scale
- define materials so that they are recognized by material handling as existing card
- use "electrodynamics" as equation because this is the common name for the physics of these examples
- fix typos
