This unifies the way the include directories are handled in the
CMakeLists.txt files.
Paths are now normally relative to the root of the source- or build dir.
They may still be relative for paths withing a plugin subdirectory but
should no longer be relative to paths outside of the current source- or
build-directory.
The previous approach had resultet in many different styles which are
hard to wrap ones head around if new to the build system.
It sometimes defined includes twice
By using relative paths, it was not possible to copy paste the paths
between different files.
The file qgsexpressions.h has grown to one monolithic piece over the
years. This makes it hard to maintain and slows down compilation because
even small changes at one end will result in recompiling big parts of
the source tree. It also requires the compiler to keep track of all
these implementation details for said big parts of the source tree.
This splits this implementation into smaller pieces. There are soe API
changes connected to this, but since these can be considered
implementation details, on which not many plugins rely, this shouldn't
have a big impact on the ecosystem outside the source tree.
Implementations of virtual methods will never be inlined, there's no
reason to keep them in headers. It just makes code less readable and
potentially slows down compilation.
main window statusbar
QStatusBar gives almost no control over display and placement
of child widgets. It's not possible to subclass and reimplement
either, due to how QMainWindow works internally, and also due to
the special handling for the size grip and other platform specific
handling in QStatusBar.
Instead, we embed a single QgsStatusBar covering the whole real
status bar. All child widgets and temporary messages instead
are pushed to the QgsStatusBar instead - giving us as much control
as we desire over how these widgets are placed and their behavior.
As a result the locator widget has been moved to its logical placement
on the left of the status bar.
All plugins must ensure that they use the status bar interface
available via iface.statusBarIface() instead of directly interacting
with the status bar (e.g. iface.mainWindow().statusBar()...)
