"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 adds dragging support for toolbars placed in custom toolbar areas.
It is achived by creating our own custom ToolBar class that handles
logic of providing custom gripper. This is required because Qt hides
gripper when toolbar is not direct child of the main window which cannot
be overriden. Custom class should allow us to create more capable
toolbars in the future so it should be great addition on its own.
Co-Authored-By: Kacper Donat <kacper@kadet.net>
In order to support targeting ToolBarAreaWidgets via the QSS we need to
make it a proper QObject using Q_OBJECT macro, which must be placed in
header files.
This refactors implementation of toolbars in menu / status bar a bit. It
introduces enum with all possible areas like it is in Qt that can be
later used to decide what to do based on toolbar placement.
* Gui: support toolbar drag and drop to status bar and menu bar
ClosesFreeCAD/FreeCAD#12979
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Gui: improve toolbar handling in status and menu bar
* Gui: fix workbench tab bar orientation in status or menu bar
* Gui: remove workbench toolbar position settings
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
================================================================
https://github.com/FreeCAD/FreeCAD/issues/9208#issuecomment-1567469254
Issue:
- Unavailable toolbars default to not visible (as they are unavailable)
- However, when made available, they remain not visible. There may be
cases when this is indeed the wanted behaviour, but they are not the
ones we are facing.
- In the latter, the user expects the toolbars to show (and the
configuration file to be saved with all toolbars showing.
Solution:
- Change the default behaviour of Unavailable toolbars when forcing
them to be available, so that they are visible when made available.
- If then the case arises that we have toolbars where we would prefer
then to be left not visible when making them available (so they are
listed in the toolbar context menu to make them visible, but not
visible per default), then we would need to create another toolbar
policy class "UnavailableHidden".
- I chose not to add it directly (although it is straightforward) in
fear that we will never need it, and it would make the code more
complex to understand and thus maintain.
=================================================================================
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.
If the user e.g. activates the Clipboard toolbar then it should not be hidden any more if the user switches to another workbench.
The way it is now the user has to make this toolbar visible over and over again when changing the workbench. This also has the negative effect that
the workbench selector changes its position
Related #6097
Qt ignores shortcut of actions in invisible toolbar, but not for actions
in a hidden menu action of menu bar, which is likely a Qt bug. The
desired behavior should be that of toolbar actions, so that actions
belong to different workbenches can have the same shortcut without
conflict.
This commit works around this inconsistency by ensuring only the active
actions are added in menu bar. In addition, all active actions will be
added to a zero sized child widget of the main window, which ensures the
shortcuts of these actions being active regardless whether the action is
in toolbar or menu bar, visible or not.
In particular this hides edit-mode sketcher toolbars when in non-edit-mode.
And hides non-edit-mode toolbar when in edit-mode.
It also hides the structure toolbar when in edit-mode (as it is completely deactivated)
* 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
When arranged vertically, the bar that allows the dragging of toolbars
can cause problems with the toolbar appearance. This adds a hidden
preference that controls whether the toolbars are movable.
