=================================================================================
fixes#9208
Essentially:
- The regular mechanism to save toolbar state when changing from one WB to another
is not designed to support changes within one WB (e.g. from edit mode and back).
- At creation time, toolbars can be initialised with default visible or default hidden
state. Additionally, there is third configuration "Unavailable", which refers to a
toolbar that is hidden, and the control to enable it is also hidden by default.
- The ToolBarManager is extended to enable to set the State of one or more toolbars.
- The State refers to changes to be effected on one or more toolbars by client code:
* ForceHidden allows to hide a toolbar and also hide its control (a toolbar not available
in a mode).
* ForceAvailable allows to make a toolbar available by making its control visible, the
toolbar itself is visible or not depending on user settings.
* RestoreDefault allows to bring the control visibility to the default of the toolbar, the
toolbar itself is visible or not depending on user settings.
* SaveState allows to store the current visibility state of a toolbar. It enables client
code to save the state when appropriate. It provides the only option for default "Unavailable"
toolbars, which are fully managed by client code. It provides additional flexibility to save
other toolbar visibility on request.
For the Sketcher this means:
- That edit mode toolbars are not shown outside edit mode.
- That edit mode toolbars and non-edit mode toolbars can be configured independently.
- that edit mode toolbars' state is saved when leaving edit mode if and only if, the
workbench that is selected when leaving edit mode is the Sketcher WB.
- it won't save the state if the user manually selected another WB and then left edit
mode (why? see limitation above).
Limitation:
- When switching to another WB while in edit mode, the other WB is activated before the
current WB (sketcher WB) is deactivated. This means that at sketcher level, the sketcher
has no chance to save states or do other tidy up actions before the tools of the other WB
are activated.
- This, however, is understood as not relevant enough as to warrant changing the mechanisms
in place.
Coverity complains about USE_AFTER_FREE here, and it was difficult to reason about the code. To help address this, use different variables for the different parameter groups.
+ replace three boolean parameters with a single string parameter
+ refactor DlgGeneralImp::saveSettings/loadSettings
+ handle visibility of corner widgets
Support longest key sequence match with user defined delay (configurable
through 'Customize -> Keyboard -> Key sequence delay').
Support user defined priority to resolve shortcut conflict through
'Customize -> Keyboard')
Add 'All' category in 'Customize -> Keyboard' to list all command and
showing their shortcuts
Unify macro command shortcut setting (BaseApp/Preferences/Shortcut).
* On lines where the variable type is obvious from inspection, avoid repeating the type using auto.
* When possible use a ranged for loop instead of begin() and end() iterators
* [Part] feature to make persistent section cut views
* one aim is to have a feature to make real cuts, not hollow ones like with clipping
* the second one is to have a persistent view, so an object in the tree that can be further exported, meshed etc.
For a detailed description with examples see https://forum.freecadweb.org/viewtopic.php?f=17&t=52441
When the shortcut/accelerator key is changed, the tooltip should be
recalculated using the same code that calculated the original. Also
ensure this happens when the accelerator preferences are loaded.
Fixes#4664.
